Using Zermatt’s claims model on WCF: ClaimsPrincipal.Current

In the last post, I briefly presented Zermatt’s claims model. This model can be used in both WCF based services or ASP.NET based web applications.

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:

 

1. Retrieves all the IAuthorizationPolicy objects from the current operation context.
2. Creates a default AuthorizationContext with the claim sets produced by the evaluation of the above IAuthorizationPolicy set.
3. 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).
4. 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.

Note however that this IClaimsPrincipal must be explicitly requested and is not referenced by Thread.CurrentPrincipal neither by ServiceSecurityContext.PrimaryIdentity.

 

Comments?

Zermatt’s claims model

In the last couple of posts, I’ve written about the claims and security token concepts, and also about how WCF models them:

• What are claims?
• Claims and claims sets in WCF
• What are security tokens?
• Security tokens in WCF
• Authorization policies in WCF: from tokens to claim sets
• The ServiceAuthorizationManager class in WCF

In this post I will start writing about how these concepts are modeled in Zermatt:

The Microsoft Code Name “Zermatt” is a framework targeted for .Net developers to help them to build claims-aware applications to address today’s application security requirements using a simplified model that is open and extensible and can improve security

Disclaimer: my conclusions and remarks are based solely on public documentation and on observing the code of the beta release, so use them at your own risk.

A new claims model

Zermatt introduces a new class model for claims, implemented in the Microsoft.IdentityModel namespace and depicted in the following figure

 

 

 

This new model extends the classical .NET model, based on the IPrincipal and IIdentity interfaces, by creating two specialized interfaces: IClaimsPrincipal and IClaimsIdentity

 

IClaimsIdentity

The IClaimsIdentity interface, derived from the .NET framework’s IIdentity interface, represents a claims-based identity. It contains the Claims property, that references a collection of claims.
A claim is represented by the Claim class, namely by three properties:

• ClaimType (string) containing the claim’s type
• Value (string) with the claim’s value
• ValueType (string) with the claim’s value type

There are some differences in the representation of claims, when compared with the “older” System.IdentityModel model.

• In the new model, a claim value is always represented by a string. When this value is not a string but a more structured object, then this object must be serialized into a string. The ValueType property contains the type of the value represented by the string in Value. The ClaimValuesTypes class contains a set of constants with the most commonly used claim value types (strings).
  The ClaimTypes class contains a set of constants with some used claim types (strings).
• There is no equivalent to the Right property.
• A claim also has the following two properties, of IClaimsIdentity type:
  • The Subject property references the IClaimsIdentity partially defined by the claim.
  • The Issuer property references the identity of the claim issuer
• There is no claim set concept. Namely, in the “new” model, each claims points to its issuer, that is modeled as a IClaimsIdentity.

The NameClaimType property of IClaimsPricipal is used to define the value of the Name property (inherited from IIdentity): this value is the value of the claim whose type equals NameClaimType.
The RoleClaimsType property has a similar goal: it defines the types of claims that define roles. This is used by classes implementing the IClaimPrincipal interface.

Finally, the IClaimsIdentity also possesses a Delegate property, of type IClaimsIdentity. This property is used in delegation scenarios, and will be described in a future post.

 

IClaimsPrincipal
This new model also introduces the IClaimPrincipal as a specialization of the .NET framework’s IPrincipal interface. Namely, this new interface adds a Identities collection that references a set of IClaimIdentity.

Note that the base interface IPrincipal already had a Identity property. The new Identities property (plural) is need because a principal can be associated with several identities, e. g., on delegation scenarios.

The implementation of the IsInRole interface method should/can use the RoleClaimTypes property of the identities referenced by the Identities property.

ClaimsPrincipal

The Zermatt’s claims model also contains an implementation of IClaimsPrincipal, called ClaimsPrincipal, with a static Current property – the IClaimsPrincipal associated with the current context.