Beginning with this post, I will describe how this new claims model is integrated into WCF, using WCF’s extensibility points, and also what are some consequences of this integration.
Once again, keep in mind that these are empirical observations of the first beta release.
One way of using Zermatt’s claims model on a service, without needing to change WCF’s default behavior, is via the ClaimsPrincipal.Current static property. In WCF, the getter method will first check if the incoming message properties (available in the current operation context) contains a property whose name is typeof(IClaimsIdentity).FullName. If not, the getter method will create and return a ClaimsPrincipal instance based on the following procedure:
- Retrieves all the IAuthorizationPolicy objects from the current operation context.
- Creates a default AuthorizationContext with the claim sets produced by the evaluation of the above IAuthorizationPolicy set.
- Creates one ClaimsIdentity instance for each ClaimSet in the above AuthorizationContext. This ClaimsIdentity instance will contain one claim for each claim in the claim set whose with right equals Rights.PossessProperty (this means that claims with right = Rights.Identity will not be reflected in Zermatt’s claims model).
- Creates one ClaimsPrincipal referring the above ClaimsIdentity collection.
Before returning, the property’s getter method also adds the created ClaimsPrincipal instance to the incoming message properties, so that subsequent calls will simply return this ClaimsPrincipal cached instance.
In other words, the IClaimsPrincipal returned by ClaimsPrincipal.Current represents a view, using the “new” Zermatt’s claims model, of the “old” (System.IdentityModel) claims model.