This article is based on the presentation given by Brock Allen and I would like to thanks him that he allowed me to use his presentation and code.

Pleae refer his presentation here.

http://brockallen.com/2012/10/16/demos-microsoft-devboston-windows-identity-foundation-in-net-4-5/

Traditional Approach to Authentication –

Authentication is the intrinsic part of the application, any or every application need authentication at some point of time. As every application needs it, same authentication logic or processes gets implemented in every application, sometime change in the authentication mechanism needs application changes.

Also with increasing uses of different authentication service provider like Google, Facebook or any other provider there is a need to outsource authentication or trust a provider which does authentication on behalf of application.

Windows Identity Foundation solves this problem in many ways and provides flexibility to focus on application code rather than authentication/authorization.

Identity in Microsoft.NET –

Identity has been at the center for security in .NET Framework 1.0, in simple terms Identity represents the user on whose behalf the code is running or what a user can do (Role), this include resource access, i/o operations or any other operation within application domain. Every request in application has an identity associated; it could be the user who is connected or impersonating any other user’s identity.

With the enhancement in the .NET Framework there has been significant change with in the framework to handle the security either it is windows based authentication or form authentication, but Identity is again at the center in both the authentications. Both are derived from IIdentity interface.

New release of .NET Framework (v 4.5) is bringing the significant change in the way Identity has been maintained; basically the new framework has changed the definition of identity. Now Identity just doesn’t describes the user on whose behalf the code is running but also provide the richer/detailed (Claim) information about the identity and it can provide more granular control on Authentication and Authorization.

with above progression .NET Identity can be divided in to two era.

1. Pre-claims in .NET 1.0 – 4.0
2. Post-claims in .NET 4.5

 Identity in .NET 1.0-

.NET Released in 2002 –

Identity was part of the .NET Framework 1.0 and it was designed based on the security concepts or features in late 1990s. It was also very centric to Windows users and groups to identify and authenticate users.

A Look on IIdentity and IPrincipal –

Based on definition –

IIdentity represent who the user is

IPrincipal is what a user can do (Roles)

namespace System.Security.Principal
{
   public interface IIdentity
   {
       bool   IsAuthenticated    { get; }
       string Name               { get; }
       string AuthenticationType { get; }
   }
   public interface IPrincipal
   {
       IIdentity Identity { get; }
       bool IsInRole(string role);
   }
}

 Identity v1.0 isn’t enough

If you carefully look at the properties of IIdentity and IPrincipal it has basically two properties

1. Name  – This provides the name of the current user
2. IsInRole – A binary function to identify it the user is part of a group or not (Admin vs. not admin)

As I said they Identity is designed based on the requirement of late 1990 and not the current era and it doesn’t satisfy the need of the current scenarios like what is my important attributes like email or something else related to business domain; for example, can I transfer money from my account (Role=Transfer) but can I transfer $ 1000 or more in a day or maybe I am a privilege user and can transfer more than $1000 when my account balance is more than $10000 on that day.

Where does Identity comes from

Or who are my identity providers, it be can be anyone like Active Directory, Application based database to provide the identity or if a business organization whom I am part of but also working with sister company.

Claims-Based Authentication –

This allows application to outsource the authentication logic to a provider (Identity Provider or IP). An IP could be within the organization or a third party provider (like Google), IP hides all the details about authentication logic and provide a simple contract that dictate that user is authenticated or not and if authenticated then information (Claims) about user.

Claims as a better Identity

Definition wise – A claim is a statement about a subject by an issuer. Here claim is properties of the user like “I can transfer $1000 on any day”, where user is the subject and issuers is the authority that provides the claim as part of my identity; in this case my bank is the identity provider who issued certain claims to me to perform certain operation.

Object representation of Claim – Claim consists of 3 properties, issuer, type and value.

namespace System.IdentityModel.Claims
{
   public class Claim
   {
       public string ClaimType { get; }
       public object Resource { get; }
       public string Right { get; }
   }
}

Identity in .NET 4.5

There is has been significant structural changes in the way .NET handles the security. Now claims are the very basic foundation of .NET Security. Now ClaimsIdentity directly implements the good old IIdentity interface and all other Identity (windows, generic, form) derived from ClaimsIdentity. Similarly, ClaimsPrincipal directly implements the IPrincipal Interface and all other principal classes inherit from ClaimsPrincipal.

Claims and Kerberos

As Claims are integrated now with every Identity type you can access them anywhere. E.g. below example demonstrates Claims integrated into Kerberos (WindowsIdentity).

static void Main(string[] args)
{
       var id = WindowsIdentity.GetCurrent();
       foreach (var claim in id.Claims)
       {
           Console.WriteLine("{0}, {1}", claim.Type, claim.Value);
       }
}

 Beyond Claims

Following are the features provided by WIF programming model.

1. Credential types
2. Claims transformation
3. Claims-based authorization
4. Session management
5. Federation

 Credential Types

The advantage with Claims Model is that Application is independent of the authentication logic and will be out of business to handle the security token getting generated as part of the authentication, all your application care is Claims.

Authentication will be handled by WIF provided module or a third party Identity Provider (STS). There are different type of security token gets generated based on the mechanism we choose to trust/develop the Identity Provider.

1. AD or Kerberos
2. FormAuthentication
3. Certificates
4. SAML Token

WIF has an abstract class SecurityTokenHandler to process the token and it also has different implementation to handle the security token and they are responsible to handle and process the incoming tokens and get the claims in the in ClaimsPrincipal for respective security token handler.

• Saml2SecurityToken
• SamlSecurityToken
• KerberosRequestorSecurityToken
• KerberosReceiverSecurityToken
• RsaSecurityToken
• SessionSecurityToken
• UserNameSecurityToken
• WindowsSecurityToken
• X509SecurityToken
• X509WindowsSecurityToken

Above classes are specific implementation to handle specific security tokens, like Windows SecurityToken handles the windows domain account.

Claims Transformation –

Identity information in token not always enough, every application has some specific requirement which requires application to add, remove, transform and/or reject claims.

WIF provides ‘ClaimsAuthenticationManager’ pipeline to calling application to transform the claims based on its requirement.

public class CustomClaimsAuthenticationManager : ClaimsAuthenticationManager
{
	public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal 										incomingPrincipal)
	{
		if (incomingPrincipal.Identity.IsAuthenticated)
		{
			 return TranformClaims(incomingPrincipal);
		}
		return incomingPrincipal;
	}
 }

Sessions

Once Authenticated from IP or STS, application receives the secured token along with Claims and they will be serialized to store in cache or cookie along with application specific claims to avoid the processing to application specific claims again and again.

Cookie in ASP.NET and WS-SecureConversation in WCF can be used as storage for claims.

var sam = FederatedAuthentication.SessionAuthenticationModule;
if (sam != null)
{
       var token = new SessionSecurityToken(ClaimsPrincipal.Current, TimeSpan.FromHours(8));
       sam.WriteSessionTokenToCookie(token);
}

Implement Authorization

Once user is authorized, its application responsibility to perform the Authorization, WIF provided ClaimsAuthorizationManager is base class to perform the authorization in the application, all you need is to derive an implementation of it.

ClaimsAuthorizationManager provides the centralized and decoupled authorization for application. Authorization can be perform based on User making a request, a resource being accessed or any action being performed.

public class CustomClaimsAuthorization : ClaimsAuthorizationManager
{
    public override bool CheckAccess(AuthorizationContext context)
    {
           var user = context.Principal;
           var resource = context.Resource.First().Value;
           var action = context.Action.First().Value;
           if (resource == "Customer" && action == "Add")
           {
	      return user.HasClaim(ClaimTypes.Role, "Sales");
           }
           return base.CheckAccess(context);
    }
}

Federation

In federation applications are decoupled from authentication and Federation Provider (IP or STS) is responsible to manage the identity and issues the claims which are requested/application for application (relying party). Because application trust the IP for identity, in certain scenario, it is also possible that an IP itself rely on another IP for authentication. This facilitate SSO between multiple application if they trust the claims issued from a IP or STS.

What is behind WIF

There are few basic components which makes all the magic behind WIF.

Federation Metadata – This is a XML file which contains the entire security requirement that a client application needs to know to a build a trust; this includes security protocol you expect, which claims your application requires and so on.

WSFederationAuthenticationModule – Often called as WSFAM, provides most of the functionality, like intercepting request and redirect unauthenticated requests to identity providers and processing of incoming tokens at sign in time.

SessionAuthenticationModule – Often referred as SAM. Once authenticated this module is responsible for session management and all subsequent request will be processed by SAM until the session expire or sign out.

ClaimsAuthorizationModule – This module is responsible for enforcing authorization policies on every request. A sample implementation is covered earlier.

How it works

WIF sits infront in the asp.net processing pipeline and when it sees an unauthenticated request it redirect that request to IP for authentication (Handled by WSFAM), its upto IP to decide about the mechanism to authenticate the user, it could be validating through a login page or kerberos.

After authentication, it issues a secure token containing claims. Now WIF takes this secure token and drops a cookie and established the session.

Identity Provider (IP) or STS

An IP is an entity which knows about subject (user), it knows how to authenticate them and provides claims associated with subject once requested on successful authentication.

IP implementation varies and two variation available currently are Passive and Active. In passive scenario relying party or application redirect user to login page hosted in STS. In active scenario relying party application uses WSTrust protocol to connect with STS and request for secured token.

Though Visual Studio provides ways to implement STS but it is not advisable to create a custom STS, as STS is responsible for handling security specific transaction, and any loop hole in the STS can make organization vulnerable. A STS considered well only when it is secure, available, and high performing and manageable. There are commercial STS are available and it is advised to use them as they are secured and tested. Some of these products are:

1. Active Directory Federation Services (ADFS) v2
2. IBM Tivoli Federation Manager
3. Oracle Identity Manager 

That’s all from the introduction point of view. You will find many example of STS on internet specially passive STS. I am currently working on to build an active STS and I will write about it next time.