Role-Based Access Control (RBAC) Authorization In Claims-Aware Applications and Services
Back to [[Windows Azure Active Directory Solutions For Developers]]
Scenario
In this scenario application requires to implement authorization based on role membership called Role-Based Access Control or RBAC. The application would enforce access to resources or action by checking user's role membership.
- The application uses claims-based authentication
- Claims carry information that needs to be interpreted as role to enforce access based on it
- Role check is made using IPrincipal.IsInRole() method
Solution Approach 1 - Using ACS Rule Engine For Claims Transformation
Using this approach ACS' rule engine is responsible for generating a role claim, http://schemas.microsoft.com/ws/2008/06/identity/claims/role, based on the information in the token. For example, if the token was issued by Google you can configure a rule to generate a role claim with GoogleUser value. This claim will be used by application when calling on IsInRole("GoogleUser") method. For detailed step-by-step procedure read How To: Implement Role Based Access Control (RBAC) in a Claims-Aware ASP.NET Application Using WIF and ACS
- Use ACS' rule engine to transform arbitrary information available in the token into role claim type, http://schemas.microsoft.com/ws/2008/06/identity/claims/role
- WIF parses the incoming token at the application and makes the role claim readily available for performing access checks.
- Perform access checks using IPrincipal.IsInRole() method in code or using attributes decorating relevant methods or classes. This approach is no different from the one that was available since .Net first version.
Solution Approach 2 - Using WIF ClaimsAuthenticationManager For Claims Transformation
Using this approach the role claims, http://schemas.microsoft.com/ws/2008/06/identity/claims/role, generated/transformed at the application using WIF's ClaimsAuthenticationManager. ClaimsAuthenticationManager serves as an extensibility point where you can write your code that changes the contents of the incoming token which is issued by any valid STS - ACS, AD FS or other. When implementing ClaimsAuthenticationManager you write code that inspects the incoming token and add role claims to it based on the token contents or any other information such as DB queries or web services calls. For detailed step-by-step procedure read How To: Implement Role Based Access Control (RBAC) in a Claims-Aware ASP.NET Application Using WIF and ACS.
- Issued token hits the application and validated and parsed by WIF
- ClaimsAuthenticationManager is configured in web.config and it invokes your custom code.
- In your implementation of ClaimsAuthenticationManager you change the contents of the token generating role claims
- In your application perform access checks using IPrincipal.IsInRole() method in code or using attributes decorating relevant methods or classes. This approach is no different from the one that was available since .Net first version.
Solution Approach 3 - Using WIF Configuration For Claims Mapping
Using this approach the role claim, http://schemas.microsoft.com/ws/2008/06/identity/claims/role, is generated at the application by configuring WIF related configuration sections in web.config. In this approach there is a simple mapping between incoming claims and role claims. This is done using samlSecurityTokenRequirement node in the configuration file. For the details on this approach read Security Token Handler Configuration under samlSecurityTokenRequirement.
- Use WIF samlSecurityTokenRequirement configuration section in web.config to map one claim to a role claim
- In your application perform access checks using IPrincipal.IsInRole() method in code or using attributes decorating relevant methods or classes. This approach is no different from the one that was available since .Net first version.
Solution Approach 4 - Implementing Custom ASP.NET RoleManager
In this approach you implement custom RoleManager that adds roles to the Principal object based on the claims in the incoming token. For more details read Authorization With RoleManager For Claims Aware (WIF) ASP.NET Web Applications.
- Configure the application for federated authentication using WIF
- Implement custom RoleManager that adds Roles to the Principal object.
- Configure the RoleManager in web.config as you would normally do it. RoleManager started to ship with ASP.NET 2.0.
Analysis
Implementing RBAC in claims aware applications may be very useful in cases when migrating from one authentication method such as Forms Based authentication or Windows Integrated authentication to Claims-Based authentication. Often there is a need to preserve the authorization functionality in legacy applications that implements usually RBAC approach. Having at hand variety of approaches can reduce the re-work when migrating existing applications to claims-based authentication but preserving their role based access authorization. Worth noting the following key attributes of each method when deciding which path to go.
- ACS Rule Engine transformation happens at ACS, not at the application.
- Claims transformation using ClaimsAuthenticationManager happens at the app and requires WIF. The transformation can be implemented on any arbitrary data
- Claims mapping using samlSecurityTokenRequirement happens at the app. The mapping can be implemented based only on the claims available in the incoming token.
How-To's
- How To: Implement Role Based Access Control (RBAC) in a Claims-Aware ASP.NET Application Using WIF and ACS
- How To: Implement Token Transformation Logic Using Rules.
Code Samples
- Code Sample: Using Claims In IsInRole in Windows Identity Foundation SDK