As WIF becoming an official part of .NET 4.5, more attentions have been paid to integrate it with other .NET technologies, like MVC or Azure. Many consider WIF as a Claim-based authentication standard, actually it also comes with a well-rounded Claim-based user authorization mechanism. In this post, I'll discuss the following topics to show how easy to apply Claim-based authentication to ASP.NET MVC, and how powerfully and flexible it can be compare to standard Role-based authentication:
- Claims Authorization Manager
- Apply to ASP.NET MVC
Claims Authorization Manager
WIF provides a claims authorization manager for
'an extensibility point from which you can authorize access to a
resource based on the claims presented in a token, before your RP
application is called (from msdn)'. I personally like it because the following reasons:
- It makes more factors available for consideration as to doing access control logic, like Resources, Operations, Principle Claims(including Roles), all of which enable more detailed access control than regular Role-based access control.
- When used with .NET Attributes, it provides a clean separation between the code to implement a feature and the code to implement access control. See sample code below.
To start, I usually list all the resources and any operation supported by my application, and define them as constants which can be used later by Attributes. To build custom ClaimAuthorizationManager, simply extend
Microsoft.IdentityModel.Claims.ClaimsAuthorizationManager, and override CheckAccess Method. It is there where you can implement your own access logic basing on resources, operations and claims.
public class MyClaimAuthorizationManager : ClaimsAuthorizationManager
{
public override bool CheckAccess(AuthorizationContext context)
{
var claimsId = context.Principal.Identity as IClaimsIdentity;
if(claimsId==null || !claimsId.IsAuthenticated)
{
return false;
}
var resource = context.Resource.First().Value;
var operation = context.Action.First().Value;
// Do your access control logic here
// ...
return false;
}
}
To use custom authorization manager, just define it in claimsAuthorizationManager section in web.config. Something like this:
<microsoft.identityModel>
<service>
<claimsAuthorizationManager type="MyNameSpace.MyClaimAuthorizationManager">
<policy resource="http://localhost/MyService.svc" action="GET">
<claim claimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth" minAge="21" />
</policy>
</claimsAuthorizationManager>
...
</service>
</ microsoft.identityModel>
Please note, configuring claim authorization manager policies is another way to define your access control logic. It's good to use in a way that it requires less code changes when access logic changed. But it's relatively rigid, so not my favorite.
Apply to ASP.NET MVC
Two things need to be handled before you can fully enjoy the claim-based access control for MVC. First, make sure your controller responsive to System.Security.SecurityException. This can be achieved by applying HandleError Attribute to controller, so MVC knows which view to go in the case of an access attempt is denied. Of course, the same attribute can be applied at Controller Action level for more fine-grained access-deny handling. Secondly, make sure your application supports custom Error handling. This can be achieved by setting customError mode to ‘On’ in
web.config.
<system.web>
<customErrors
mode="On"
defaultRedirect="Home/Logout"></customErrors>
…
</system.web>
Now you can apply ClaimsPrincipalPermission attribute to any Controller Actions you plan to do access control. Just make sure to provide correct resource(s) and operation as parameters, because they will be used by claim authorization manager to make access control decision.
[HandleError(ExceptionType = typeof(SecurityException), View = "Home/Login")]
public class MyController : Controller
{
[ClaimsPrincipalPermission(SecurityAction.Demand, Resource = MyResources.REPORTS_ACCESS, Operation = MyOperations.GET)]
public ActionResult ViewReport()
{
...
return View();
}
...
}
Similar authorization control can also be used for AJAX Web Services. In this case, simply apply ClaimsPrincipalPermission Attribute to Web Method. Make sure AJAX client to handle the security exception once an access attempt is denied.
