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.