Windows Identity Foundation and AD FS 2.0
Some time ago the Identity Division at Microsoft started working on a project code named ‘Geneva’ with the goal to make it significantly easier to implement claims based identity in Windows based solutions. In 2008 the first preview of the resulting products where released and in November 2009 Windows Identity Foundation (WIF) and Active Directory Federation Services version 2 (AD FS 2.0) hit RTM.
Below is an overview of WIF and ADFS 2.0 taken from the whitepaper “Single Sign-On from Active Directory to a Windows Azure Application”:
AD FS 2.0
AD FS 2.0 is a key component in Windows based federated security. In its role as a security token service (STS), it authenticates users and generates authorization information. It does this by implementing web-compatible protocols, including WS-Federation, WS-Trust adn SAML 2.0. AD FS 2.0 is an infrastructure component. This means it is typically managed by IT staff and not by developers. Developers should understand enough about AD FS 2.0 so that they can communicate requirements for claims required by the applications they are developing.
WIF is a developer framework that enhances the .NET Framework capabilities. WIF integrates seamlessly with the existing mechanisms in the .NET Framework for working with identity, namely the interfaces IPrincipal and IIdentity. WIF extends those interfaces with IClaimsPrincipal and IClaimsIdentity. The beuty of IClaimsPrincipal and IClaimsIdentity is that they still can take advantage of existing access control mechanisms, such as IsInRole() and the
The WIF claims object model
As you can see WIF allows us to keep our existing authorization checks intact by using the familiar IPrincipal interface. WIF achieves this by mapping incoming Name- and Group-claims to the corresponding properties of IClaimsIdentity and IClaimsPrincipal instances.
AD FS 2.0, which is part of Active Directory but (right now) ships as a separate install, will act as the STS, authenticating users against the Domain Controller and then constructing the SAML Token containing the claims that the application, the Relying Party, requires:
Claims Based Identity with WIF and AD FS 2.0 for an application running in the cloud
A nice effect of this separation of concerns is that the token can be easily extended to contain other claims than user name and Windows groups. The email address of the user could for example be fetched directly from Active Directory while constructing the token.
Another interesting scenario shown in the above diagram is when clients outside the domain need to access the application. By putting an AD FS proxy server in the DMZ the clients can still be authenticated against the Domain Controller and provided with a valid SAML token that can be sent to the application.
In the next parts we will look at how we can extend this solution so that business partners can achieve SSO with the help of Windows Azure AppFabric Access Control Service.
Category: sso, azure, english