Windows Identity Foundation

In Brief

Windows identity Foundation (WIF) is a component of Microsoft's identity and access management solution. It is a 'Federated' and 'Claims' based identity framework with the distinct goal of decoupling the mode of authentication from an application and/or service. On the face of it then, WIF appears to be an solution for externalising the authentication mechanism altogether, no longer necessitating the need to create custom identity providers and user account tables for disparate applications within and without an organisation. 



WIF uses 'claims' based authentication, replacing the role style security model. Claims are a replacement for the 'Role' based security model due to the need to be more granular across applications in what a user 'can do' or 'has' etc.. Claims are more then just roles and permissions, claims can be information, data, profiles... what ever is needed but are essentially Active Directory Attributes which are called claims because of the context in which they are used. In building WIF, Microsoft has recognised that across business', clients and departments, across systems and applications, the meaning of 'Groups' and 'Roles' varies dependent upon the user's domain. Roles are still there, but instead, logical roles are mapped to claims, meaning the introduction of new roles ought never pervade the meaning of currently existing roles. 

So simply, WIF's goals are to:

• Introduce a more flexible security model across an organisation by decoupling applications user management providers and freeing up developer resources.
• Reduce the time needed to manage users across multiple systems i.e. profile synchronisation.
• Granting external clients trusted domain permissions in order to access web-facing business applications with or without the ability of Single Sign-on (SSO).
• Replace roles with a more 'granular artifact for authorisation'; a claim. Roles do exist, but are essentially containers for multiple claims.Scenario's.

Do we have a need for claims?

For the following scenarios's single sign-on (SSO) is taken to mean that a user logs in on their computer, and after which all applications are available to themselves without the need to login again at any other point. In the event that this means the alternative, meaning that we sign in to one piece of software, and are automatically signed in to all other sites, then this issue becomes nought anyway.

For the scenario's of;

• Non-web facing SSO applications; Windows integrated security ought to be used.
• Web-facing SSO applications for internal users, sign-on for external users; Windows integrated security should be used. Failure to authenticate via Kerberos and Active Directory will return the user to web form where manual authentication can be used.
• Web-facing SSO applications for internal and external users; at this point Windows integrated authentication becomes invalid because user's are on different domains. At this point some form of Claims authentication ought to be considered. This is when WIF can help.

There is absolutely nothing stopping you from using WIF internally for SSO, and so WIF can also help in the following;

• Company merges where multiple Active directories exist.
• Authentication between a .NET application and a non .NET application
• Need to share identities between different platforms i.e. Windows and Macintosh.

WIF & Claims

The reason claims authentication works between platform independent systems is because claims is reliant on SOAP and Security Tokens. Generally, a user will authenticate with a Security Token 'Issuer' , which returns a security token of claims (first name, last name, email address...) which ends up in transit with the user on the way to the web application which validates the token and the user is logged in. The majority of work here is done on the 'Issuer', there are alternatives, but the most common on the Windows platform is Active Directory Federation Services 2.0 (ADFS). ADFS has methods that, when a Security Token is created, allows you to add rules to gather information from different sources (database, XML, ADLDS).

The previous example is one of an internal system using WIF, however, for there to be 'Federated' SSO between a business domain application and the client domain, both the business and the client must install a Security Token Service (STS) Issuer. 

The application must be configured to Trust the Issuer's, important factors are what claims are available, the key it should use to validate token signatures, and the URL a user must access to request a token from the issuer.

Just as the application ought know about the issuer, the issuer needs to know about the Application to ensure that any claims it issues are going to authorized recipients. Also, it needs to be configured to know what claims to send, and whether the token requires encryption or not.

So...

Chances are, we'll need something like WIF to cross-domain authenticate user's ONLY IF we need cross-domain Single Sign-on. Otherwise we don't. Either way we still need to provide web forms alternative login. I just don't see smaller clients or supplier that have enough need for this other then P&G, Tesco's, maybe Equiniti.

MSDN licenses include access to all of this software, however for Clients who want SSO, they'll need an STS Issuer for their domain whether that's a server with Windows 2003 or later with ADFS, or a Cloud Issuer, or a home-brew one. They'll need to purchase one if they haven't already.

The general rule that a system should know only what it needs to know about a user should hold true for the claims an STS Issuer makes - limited to profile (name, email, etc.) and roles. However on the issue of Roles, again, I'm not entirely sure on the point that WIF makes about the use of Roles. How does a 'Role' from another Domain, a claim that it has a role, provide any information in our application unless we configure the application to make sense of the companies roles in the first place?  Therefore, I don't think we rely on this for application wide Roles, but for automatic membership and identity.  

Pre-requisites

.NET Framework 3.5 SP1 or later.
Windows Server 2003 or later installed with ADFS2.0
Windows Server 2008 R2 Enterprise Edition license holders are automatically licensed to run ADFS 2.0

Further Reading

A Guide to claims based authentication, http://msdn.microsoft.com/en-us/library/ff423674.aspx, January 2010

Windows Identity Foundation Overview, http://msdn.microsoft.com/en-us/library/ee748484.aspx,No Date Provided

Claims-Based Authorization with WIF, http://msdn.microsoft.com/en-us/magazine/ee335707.aspx, November 2009