-
Notifications
You must be signed in to change notification settings - Fork 6
Catbert Role Provider
Since .NET 2.0, ASP.NET has had the ability to plug in different providers for tasks such as Authentication (Membership), Authorization (Roles) and Profiles. We use a Role provider quite frequently since CAS/DistAuth takes care of authentication, and in order to reduce effort duplication the Catbert system was built to centralize role management.
UCDArch has two built in Role Provider implementations in the UCDArch.Web.Providers dll/namespace that use the Catbert system:
- CatbertRoleProvider: A SQL based role provider
- CatbertServiceRoleProvider: A WCF service based role provider
In most cases the SQL-based role provider is sufficient, but it requires that you have access to the underlying Catbert database. The CatbertServiceRoleProvider, on the other hand, can be used from anywhere (and any client) via a WCF service and transmits all data through transport and message level encryption.
In order to use the SQL-based role provider, first you need to add a connection string to the Catbert DB (and associated permissions)
<add name="Catbert" connectionString="Data Source=.\SQLExpress;Initial Catalog=CATBERT3;Integrated Security=True" providerName="System.Data.SqlClient"/>
Next, you need to define the actual role provider section in the web.config file
<roleManager enabled="true" defaultProvider="CatbertRoleProvider" cacheRolesInCookie="false">
<providers>
<add name="CatbertRoleProvider"
type="UCDArch.Web.Providers.CatbertRoleProvider"
applicationName="Catbert"
description="Catbert"
connectionString="MainDB" />
</providers>
</roleManager>
Note that there are two required attributes you must pass to the CatbertRoleProvider, the application name and the name of the connection string to use when connecting to Catbert.
The service role provider uses a WCF service secured over SSL and additionally message encrypted, allowing you to access role information from anywhere. First you need to request an access token, which will look like a Guid without dashes (example: 871e3230aa77491a843b2accfdedad93). Next, you should setup two appSettings, one for the Url of the webservice to use and another for the token
<appSettings>
<add key="RoleServiceUrl" value="https://[url]/Public/Role.svc" />
<add key="RoleToken" value="[token]" />
</appSettings>
Then all you have to do is add a role provider section, this time pointing to the CatbertServiceRoleProvider.
<roleManager enabled="true" defaultProvider="CatbertServiceRoleProvider" cacheRolesInCookie="false">
<providers>
<add name="CatbertServiceRoleProvider"
type="UCDArch.Web.Providers.CatbertServiceRoleProvider"
applicationName="SampleUCDArchApp"
serviceUrlKey="RoleServiceUrl"
authTokenKey="RoleToken" />
</providers>
</roleManager>
Note the three required attributes here: application name, the app setting key containing the service url, and the role token key.
Of course if you are familiar with any other role provider, these work in exactly the same manner. Usually you demand security on a controller or action by using the [Authorize]
attribute.
[Authorize(Roles="Admin")]
public ActionResult AdminOnlyAction() { ... }
You can also call into the System.Web.Security.Roles static class directly and use any of the read-only query methods. The following are a few examples:
var isUserInRole = Roles.IsUserInRole("role");
var usersInRole = Roles.GetUsersInRole("role");
var rolesInApp = Roles.GetAllRoles();
var currentUserRoles = Roles.GetRolesForUser();
When using certain MVC4 templates you may encounter a Configuration Error that states:
Parser Error Message: This method cannot be called during the application's pre-start initialization phase.
If this is the case, you need to add the following lines to your web.config under the appSettings section:
<add key="enableSimpleMembership" value="false" />
<add key="autoFormsAuthentication" value="false" />
In production environments you should remove the cacheRolesInCookie="false" attribute for a nice performance bump.