Introduction to Claims based security in .NET4.5 with C# Part 2: the new inheritance model

The previous blog post introduced how Claims are handled in .NET4.5. This blog will will discuss the new inheritance model of the IPrincipal and IIdentity interfaces.

The new inheritance model

Before .NET4.5 the built-in GenericPrincipal and WindowsPrincipal objects directly implemented the IPrincipal interface. GenericIdentity and WindowsIdentity inturn implemented the IIdentity interface. With .NET4.5 we can see a new philosophy: Claims must be readily available in any new .NET projects that have .NET4.5 as the underlying framework. The new inheritance structure is as follows:

• ClaimsPrincipal implements IPrincipal
• GenericPrincipal and WindowsPrincipal directly derive from ClaimsPrincipal
• Therefore GenericPrincipal and WindowsPrincipal do not directly implement IPrincipal any more

Conclusion: even if you have never even heard of Claims and continue to use the ‘old’ GenericPrincipal and WindowsPrincipal objects you indirectly use ClaimsPrincipal even if it is not obvious at first. If you upgrade your .NET4 project to .NET4.5 then your authentication logic will not break and you will have access to the new features of ClaimsPrincipal through GenericPrincipal and WindowsPrincipal as well.

We see the same changes with IIdentity. Before .NET4.5 we had built-in implementations of IIdentity such as GenericIdentity, WindowsIdentity. Now we have one object, the ClaimsIdentity that directly implements IIdentity and the other two derive directly from ClaimsIdentity.

In other words: ClaimsPrincipal and ClaimsIdentity provide a common ground, a common base class for the objects that directly derive from it. If you have an intranet application with Windows Auth then all the specific properties available in WindowsIdentity and WindowsPrincipal, such as Impersonation or User token will be stored in the ClaimsCollection.

This also means that if you plan to build your own Identity and Principal objects then you should not implement IIdentity and IPrincipal but derive from ClaimsPrincipal and ClaimsIdentity instead. You will then have access to all the new features of Claims as well.

Claims inheritance demo

Fire up Visual Studio 2012 and create a new Console application with .NET4.5 as the underlying framework.

In the Main method add the following code to create a new WindowsIdentity:

WindowsIdentity windowsIdentity = WindowsIdentity.GetCurrent();

Set a breakpoint at this bit of code and run the application. Inspect ‘windowsIdentity’ in the Locals window and check its base class:

It’s easy to see that WindowsIdentity indeed derives from ClaimsIdentity. Scroll down the Locals window and you’ll see that WindowsIdentity has access to the Claims collection of its superclass:

The Claims collection has been populated mostly with the well-known WindowsIdentity Group SIDs.

Let’s have a look at GenericIdentity. Add the following code to Main:

GenericIdentity genericIdentity = new GenericIdentity("Andras");

Inspect the ‘genericIdentity’ variable in the Locals window and you’ll see again that the Claims collection has been populated with the Name claim:

This is great. Even if you use the old-style WindowsIdentity and GenericIdentity objects you have access to the Claims collection that you can query.

Build your own IIdentity object

In the past if you needed to build your own IIdentity object then you may have done something like this:

public class CompanyIdentity : IIdentity
    {
        public CompanyIdentity(string location, int allowance)
        {
            Location = location;
            Allowance = allowance;
        }

        public String Location { get; set; }
        public int Allowance { get; set; }


        public string AuthenticationType
        {
            get { throw new NotImplementedException(); }
        }

        public bool IsAuthenticated
        {
            get { throw new NotImplementedException(); }
        }

        public string Name
        {
            get { throw new NotImplementedException(); }
        }
    }

You may have implemented the IIdentity interface and added the custom properties that represent a User. These extra properties, such as Location are nothing but Claims really.

Today you would instead inherit from the ClaimsPrincipal object and populate the Claims collection with the AddClaim method:

public class CompanyIdentity : ClaimsIdentity
    {
        public CompanyIdentity(string location, int allowance)
        {
            AddClaim(new Claim(ClaimTypes.Locality, location));
            AddClaim(new Claim("http://www.mycompany.com/allowance", allowance.ToString()));
        }

        public string Location
        {
            get
            {
                return FindFirst(ClaimTypes.Locality).Value;
            }
        }

        public int Allowance
        {
            get
            {
                return Convert.ToInt32(FindFirst("http://www.mycompany.com/allowance").Value);
            }
        }
    }

The Location and Allowance getters are optional. You can directly inspect the claims collection of the CompanyIdentity object. The getters are there for convenience.

This was a rather short post dedicated to the new Identity and Principal inheritance model in .NET4.5. The next post will deal with claims transformation, i.e. how you can “dress up” an initial set of claims with new ones before your auth logic kicks in.

You can view the list of posts on Security and Cryptography here.