The beta 2 “Geneva” framework contains the concept of a claims authorization manager, represented by the ClaimsAuthorizationManager base class. This class contains a single method
public virtual bool CheckAccess(AuthorizationContext context)
that computes the authorization decision for the access represented by context. This object, of AuthorizationContext type, contains the following properties
- Subject, of IClaimsPrincipal type, represents the subject performing the access.
- Resource, of Collection<Claim> type, represents the accessed resource.
- Action, of Collection<Claim> type, represents the action to be performed on the resource.
The CheckAccess method is called in three distinct cases.
On a WCF scenario, the CheckAccess method is called by the Geneva’s service authorization manager, before the service’s method is called. In this case, the AuthorizationContext’s Resource and Action properties are given, respectively, by the To and the Action message headers.
On an ASP.NET scenario, the CheckAccess method is called by the Geneva’s pipeline authorization module, before the HTTP request is delivered to the HTTP handler. In this case, the AuthorizationContext’s Resource and Action properties are given, respectively, by the HTTP request’s URL and method.
The authorization decisions are also performed when the application explicitly demands it. The Geneva framework includes a new IPermission implementation: the ClaimsPrincipalPermission. This new class is similar to the PrincipalPermission, which is used to check if the current thread’s principal has the demanded identity characteristics (name and/or roles). However, there are two significant differences.
First, the ClaimsPrincipalPermission is based on the new claims model, namely it expects that the current principal is an instance of ClaimsPrincipal.
Second, the ClaimsPrincipalPermission does not receives the demanded claims. Instead, it only receives the (resource, action) pair that the principal permission is guarding. This solves one of the problems associated with the PrincipalPermission class: the need to explicitly pass the roles in the creation of PrincipalPermission objects, which typically meant the hard-coding of roles in the application code.
The resource and action information, added with the current principal, is used to build an authorization context that is passed to the CheckAccess method of the configured claims authorization manager.
This new permission also has an associated attribute, ClaimsPrincipalPermissionAttribute, for declarative demanding.
This week was released the beta 2 of the “Geneva” framework. This framework aims to provide an unified model for claims based identity management and access control. This includes a class model for representing claims-based identities, showed in the next diagram.
This class model, present in the Microsoft.IdentityModel.dll assembly, is similar to the one present in the code name “Zermatt” framework. One important difference is that issuers are not represented by IClaimsIdentity objects but by simple strings. The previous Zermatt’s model seems more complete, since it contains more information about an issuer. However, this added information implies that claim inference and authorization decision processes are typically more complex. The new model aims to reduce this complexity by translating the issuer’s claims set into a string, which will be used in the claim inferences and authorization decisions. This translation is the responsibility of IssuerNameRegistry objects.
- The System.IdentityModel.dll (SIM) model does not integrates with the IPrincipal/IIdentity principal model. The Microsoft.IdentityModel.dll (MIM) does.
- The SIM model does not includes explicit support for claims-based delegation. The MIM model includes the concepts of delegated identity and original issuer.
- In the SIM model, an issuer is represented by a claim set. In the MIM model, an issuer is represented by a string returned by an IssuerNameRegistry, as described above.