This article continues with the previous one for claim provisioning. A claim is a combination of a claim type, right, and a value. A claim set is a set of claims issued by an issuing authority.  A claim can be a DNS, email, hash, name, RSA, sid, SPN, system, thumbprint, Uri, and X500DistinguishedName type.  An evaluation context is a context in which an authorization policy is evaluated. It contains properties and claim sets and once the evaluation is complete, it results in an authorization context once authorization policies are evaluated. An authorization policy is a set of rules for mapping a set of input claims to a set of output claims and when evaluated, the resulting authorization context has a set of claims sets and zero or more properties. An identity claim in an authorization context makes a statement about the identity of the entity. A group of authorization policies can be compared to a machine that makes keys. When the policies are evaluated a set of claims is generated, it is like the shape of the key. This key is stored in the form of an authorization context and can be used to open some locks. The granting of access is the opening of a lock Identity model does not mandate how the claims should be authored but it requires that the set of required claims must be satisfied by those in the authorization context.

The identity model is based on claims organized in a collection of sets of claims within an authorization context created by chained authorization policies. When a web service implements this identity model such as in Windows Communication Framework (WCF), the service determines the authorization policies with a ServiceAuthorizationBehavior class evaluated by a ServiceAuthorizationManager and results in an AuthorizationContext class.

Systems can not only grant access but can also deny access based on the presence of claims. Such systems must review the authorization context for claims that result in the denial before viewing the claims that result in the access. For example, an identity claim with a name and age allowing access based on the name but denying access based on age must be evaluated by first visiting the age claim before visiting the name claim. Access can be granted solely based on name in this case.

Services must use service class identity instead of user principal name and they can impersonate the user. A logged-in user on Windows has a Kerberos ticket granted from authentication. A WCF service representing the user has the choice of impersonating between two methods. The first involves a windows token obtained from the Security Support Provider interface or Kerberos authentication and this can be cached in the service for future use. The second involves a windows token obtained from Kerberos extension collectively called Service-for-User or (S4U) 

Sometimes the entire service call does not need to be executed with an impersonation context. In this case, the windows identity of the caller is obtained inside the service method and the impersonation is performed imperatively. For example:

WindowsIdentity caller = ServiceSecurityContext.Current.WindowsIdentity;

 

using(caller.impersonate()) { 

 

// do something

 

}