Claiming an Identity in the Geneva Framework

In an earlier post I recommended danah boyd’s U.C. Berkeley Ph.D. thesis Taken Out of Context – American Teen Sociality in Networked Publics. Dry as the title is, the thesis is actually an interesting read for anyone interested in identity and identity management.

In chapter 4 of her thesis, boyd suggests that for teens identity is more than just providing a name it is the act of “writing oneself into being.” boyd opens the chapter with an extract of the About Me page on MySpace for “Allie a white 17-year old from Indiana:”

i’m allie. i’m not a very complex person.
i like music. i like reading. i love meeting new people.
i’m still trying to figure a lot of things out. about God. about life. about my future.
about people.
i don’t like who i am, but i’m working towards being someone better.
i’m really trying to follow Jesus with my all. sometimes i need help.

We know Allie’s formal identity, her name, but Allie also makes a number of claims about her identity – and these claims may or may not be be true. Readers of the About Me page are faced with a decision about whether or not to believe the claims. She might not like music, she might not like meeting people and her name might not even be Allie. However, I trust boyd and am willing to believe that there really is a white 17 year old from Indiana named Allie who made these claims.

Similar doubts arise when dealing with identity in computer systems. A user may or may not be who they claim to be so we insist on the user authenticating with a trusted authentication system. Historically, this is about as far as identity went – as exemplified by the .Net interface IIdentity in the System.Security.Principal namespace:

public interface IIdentity
{
    string AuthenticationType { get; }
    bool IsAuthenticated { get; }
    string Name { get; }
}

This interface is concerned solely with the name of the entity being identified along with how and whether that identity is authenticated. However, the user is provided with little information about the entity being identified – it is almost as if Allie had written only her name on her About Me page. The user of an entity exposed through an IIdentity interface still has to decide whether or not to trust the authentication.

Traditionally the next step up from identity has been to assign each identity to one or more groups or roles such as Administrator, Power User, User, etc. In .Net this is represented through the IPrincipal interface in the System.Security.Principal namespace:

public interface IPrincipal
{
    bool IsInRole(string role);
    IIdentity Identity { get; }
}

An IPrincipal wraps an IIdentity along with a method determining whether or not a specific role is associated with the entity being identified. A simple way to remember the difference between an IIdentity and an IPrincipal is that an IIdentity results from authentication whereas an IPrincipal results from authorization.

In creating her identity, Allie does not state she is in this role or that role. Instead, she asserts a set of claims about herself and it seems more natural to describe her identity as a set of claims rather than a set of roles. She claims to be named Allie, she claims to be 17, she claims to like reading, and so on. Indeed, it turns out to be convenient to describe her identity as a set of claims rather than as a mixture of name, roles and perhaps properties for those claims not easily shoehorned into a role.

There has recently been a lot of interest in using claims as the core of an identity metasystem allowing identities to be created in a simple and standardized way that is usable both inside and outside the enterprise. This claim-based identity subsumes simple name-based identities and roles into a unified system.

Microsoft is developing the Geneva Framework to be the SDK for its claim-based identity metasystem. The core class of claim-based identity in the Geneva Framework is Claim in the Microsoft.IdentityModel.Claims namespace:

public class Claim {
    // Constructors
    public Claim(String type, String value, String valueType, String issuer, String originalIssuer);
    public Claim(Claim claim, String issuer);
    public Claim(String type, String value, String valueType, String issuer);
    public Claim(String type, String value);
    public Claim(String type, String value, String valueType);

    // Properties
    public virtual String ClaimType { get; }
    public virtual String Issuer { get; }
    public virtual String this[String index] { get; set; }
    public virtual String OriginalIssuer { get; }
    public virtual IDictionary<String,String> Properties { get; }
    public virtual IClaimsIdentity Subject { get; }
    public virtual String Value { get; }
    public virtual String ValueType { get; }

    // Methods
    public Object Clone();
    public virtual void SetSubject(IClaimsIdentity subject);

    // Implemented Interfaces and Overridden Members
    public override String ToString();
}

A Claim has a type and value. The claim type is a String like http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name for which the corresponding value could be a String like Allie. The ValueType occuring as a property of the Claim class, as well as a constructor parameter, supports the concept of the value of they claim being of a non-String type such as a DateTime. For example, the claim of type http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant could have the value 2009-05-27T02:00:27.376Z of type DateTime. Various organizations, including Microsoft, have specified various claim types and individual enterprises are free to create custom claim types.

Claims are asserted by an issuer and the user of the claim, the relying party, must decide whether or not to trust the issuer and the claim. For example, I trust danah boyd when she asserts the claim that a girl named Allie wrote an About Me page on MySpace However, I might not trust any claim Allie asserts about herself on that page. Similarly, I may trust a claim asserted by an authenticated user but not trust a claim asserted by an unauthenticated user.

Instead of blowing away the existing IIdentity and IPrincipal classes and starting afresh in the Geneva Framework, Microsoft introduced the IClaimsIdentity and IclaimsPrincipal interfaces derived from them so that much of the existing IIdentity and IPrincipal framework remains valid.

The IClaimsIdentity interface in the Microsoft.IdentityModel.Claims namespace is declared:

public interface IClaimsIdentity : IIdentity, ICloneable {
    // Properties
    ClaimCollection Claims { get; }
    IClaimsIdentity Delegate { get; set; }
    String Label { get; set; }
    String NameClaimType { get; set; }
    String RoleClaimType { get; set; }
}

The IClaimsIdentity associates a collection of Claims with the entity identified by Name in the base IIdentity interface. The Delegate property allows one IClaimsIdentity to act on behalf of another in situations where an intermediate party is authorized to perform actions based on claims made by a remote entity. Label is a user-friendly name for an IClaimsIdentity entity. NameClaimType specifies which claim asserts the Name of the entity when it is constructed from a set of claims – for example: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name. Similarly, RoleClaimType specifies which claim asserts the role for the entity when it is constructed from a set of claims – for example: http://schemas.microsoft.com/ws/2008/06/identity/claims/role. It is not immediately obvious to me why the RoleClaimType is not declared in the IClaimsPrincipal interface since that would appear to fit more naturally in with the idea that IClaimsIdentity is for authentication and IClaimsPrincipal is for authorization.

The IClaimsPrincipal interface in the Microsoft.IdentityModel.Claims namespace is declared:

public interface IClaimsPrincipal : IPrincipal, ICloneable {
    // Properties
    ClaimsIdentityCollection Identities { get; }
}

A ClaimsIdentityCollection simply implements the following:

IList<IClaimsIdentity>, ICollection<IClaimsIdentity>, IEnumerable<IClaimsIdentity>, IEnumerable, ICloneable

Therefore an IClaimsPrincipal bears the same relationship to IClaimsIdentity that an IPrincipal has to IIdentity except that IClaimsPrincipal allows more than one IClaimsIdentity. IClaimsPrincipal exposes IsInRole() from the base IPrincipal interface and sets the IIdentity from the IPrincipal interface to the first IClaimsIdentity in the Identities collection.

This post has come a fair way from its initial discussion of Allie’s MySpace page but the idea behind claims-based identity is precisely that of Allie when she constructed an identity for herself by asserting a set of claims. She may not have realized she was asserting a set of claims but when developing computer-based systems it is essential we understand the abstractions we use. And it appears that constructing an identity out of a set of claims is powerful and useful abstraction. All that remains is deciding whether or not to trust the claims.

Technorati Tags: ,

About Neil Mackenzie

Cloud Solutions Architect. Microsoft
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s