Single Sign On and Federated Security in the cloud – part 3

The WIF object model

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 element. They also contain additional members that carry the claim collections that are extracted from the incoming authentication token that AD FS 2.0 generates.

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 ADFS 2
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

Single Sign On and Federated Security in the cloud – part 2

Generic Claims Based Identity scenario

Claims Based Identity

“A claim is a statement about a subject made by an entity” as Vittorio Bertocci writes in his excellent book “Programming Windows Identity Foundation”. And he goes on to explain that the claim is always associated with the entity that issued it.
For example: a user is authenticated by an identity provider and a claim is being issued about the user’s identity.
By removing the need for developers to know exactly how that authentication technically was implemented, but still being able to prove it was made by a trusted entity – it provides a level of indirection and abstraction that helps address our challenges when moving applications to the cloud.

Claims Based Identity provides a standard way of flowing statements – Claims – about authenticated users from an Identity Provider via a Security Token Service to an application – a Relying Party. The Relying Party trusts the Issuer of the Token that contains the claims about the user. The Token can be in different formats but is usually an XML-based construct; SAML being one of the most widely used standards for Security Tokens in Claims Based Identity.
In addition to the claims about the user the Token also contains cryptographic proof from the Issuer of the claims. Using the Issuer’s public certificate thumbprint the Relying Party can make sure the corresponding private key was used by the Issuer to sign the Token.
A Single Sign On solution built on Claims Based Identity is interoperable by design and can without any problem traverse firewalls and proxy servers if the communication is being done through standard HTTP ports.

Generic Claims Based Identity scenario for an application running in the cloud

This time the ticket being issued is a Security Token in a standard format coming from a Security Token Service (STS) through web-compatible protocols (WS-Federation, SAML or WS-Trust depending on the type of client and service).
The arrows doesn’t show exactly how the protocols actually work and how the different requests for tokens are being made, but merely illustrates the flow of Security Tokens at a high level.

In the next blog post we will have a look at handling Claims Based Identity in a Microsoft environment with the help of Windows Identity Foundation and AD FS 2.0.

Category: sso, azure, english

Single Sign On and Federated Security in the cloud – part 1

Kerberos baserd SSO in the domain

I wrote some blog posts on SSO and federated security for the Windows Azure Architect site a while ago, but they seem to have gone missing – so I’m re-posting them as a series of posts here.

The SSO-challenge when moving your application to the cloud

Using Active Directory and integrated Windows Authentication works great as a Single Sign On solution for the intranet and as long as all your systems resides within the boundaries of the domain. The clients get authenticated against the domain controller and a Kerberos ticket is issued and used whenever the clients need to access a resource or service:

Single Sign On inside a domain

The application server trusts Kerberos tickets issued by the Active Directory in the domain and can grant or deny access to resources based on who the user is and what groups the user belongs to (this of course is a simplified description of how the Kerberos protocol actually works, but on a conceptual level holds true).

But what happens when you start moving some of your applications to a cloud environment like Windows Azure?

App moves to the cloud
The application is moved to the cloud

This scenario presents a couple of different challenges:

  • A Kerberos ticket can no longer be used without setting up some kind of VPN network connection since the client still resides in the domain but the application now runs in the security context of another network, across the Internet, possibly accessed through a proxy server and behind one or more firewalls.
  • Another challenge is the amount of information that you can provide in a Kerberos ticket. Such a ticket only provides the user name and what groups the user belongs to. Say for example you need to use the email adress to send automated email from the application to the user. In the intranet scenario you would query Active Directory or some other information store to get additional information. But how would you do that when the application no longer have access to the domain? It would be a lot more convenient if you could extend the ticket to contain arbitrary information. There is no way you can do that with a Kerberos ticket.
  • And what if the system your clients need to access is not a Windows based system at all – a system that doesn’t recognize Windows Authentication – for example a Java based application or some legacy system?
  • Another interesting scenario is if the client would need to access the service from outside of the domain, through public Internet.

In the next post we will look at how to solve these challenges using Claims Based Identity.

Category: sso, azure, english