Does ADFS 2.0 deliver on its single sign-on promise?

If you’ve ever tried to develop an online solution that requires a login, you know it isn’t difficult to accomplish — as long as you handle the login information yourself or through a service that retains users’ names, passwords, or other data. These have become commonplace. However, they don’t help so much with federated IDs such as those used for single sign-on via Active Directory, as I discovered firsthand in setting up my company’s learning portal.

It would be so much easier if there were some form of trust or federation with the companies that sign up so that their users log into their Active Directory and can access their online portals as well. The good news is that Active Directory Federation Services (ADFS) 2.0 is making some strides here.

[ Master your security with InfoWorld’s interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter. ]

ADFS 2.0 is an add-on role for Windows Server 2008 that was released in May. The idea is simple: Users log in once to the Active Directory environment and can use those credentials through claims-based authentication to access other applications, as long as they are identity-aware.

When I saw ADFS 2.0, my first thought was, “Here we go with yet another identity solution based upon some proprietary set of standards or protocols.” But ADFS 2.0 supports Security Assertion Markup Language (SAML) 2.0, which is also used by several major third-party cloud services.

There is a hodgepodge of different elements that allow for authentication between an Active Directory environment and the application in question (on-premise and cloud based, for example) to provide the passthrough in a secure manner, including Web Services Federation (WSFed), WS-Trust, and SAML. These all work together to create tokens that make claims that are verifiable. In ADFS 2.0, Microsoft uses these industry-standard interoperable protocols.

How claims-based authentication works Before I go further into ADFS 2.0, let’s take a step back and explain a bit how claims-based authentication works, whether for ADFS 2.0, IBM Tivoli Federated Identity Manager, Novell Access Manager, or any other system.

Digital identities typically relate to users. Those identities are usually provided within a network by security tokens. Sometimes, other security boundaries may be involved (for example, in Active Directory you may have Kerberos tickets), but for simplicity let’s stick with tokens.

In a claims-based world, a token includes various claims; these might include a person’s name, group, and/or age. The tokens and their claims are created by a Security Token Service (STS), which authenticates the user and provides back a token with the claims attached. Note: Users don’t just get whatever token they want. The STS provides the token based on the authentication of the user within Active Directory (in the case of ADFS 2.0) and provides the information within the database that links the user to his or her data and to whatever application that token will be used to access.

The STS is owned by an identity provider (an issuer) that validates the claims when asked to do so. When the user tries to access an application, another enterprise, or a cloud-based service, these applications that receive the token look to see if its issuer is one they trust; if so, they trust the claims made for the user via the token.

One tremendous benefit to developers of this approach, according to Microsoft, is that it gets developers out of the business of authenticating users. Instead, developers can rely on an STS, issuer, and validating application to do the authentication work for them as a service.

One other point to keep in mind is that you may need to use different identity tokens for different applications. In much the same way you might use a birth certificate to identify yourself at times, a driver’s license on other occasions, and a passport on still other levels, as a developer you may require different identity providers and thus need an identity selector to allow you to choose the appropriate STS for your application.

How ADFS 2.0 handles claims authentication With this background in mind, let’s look at ADFS 2.0 specifically.

The STS is handled by ADFS 2.0 by installing it as a role in your Active Directory environment; your organization now becomes the issuer of the token. The application would use Windows Identity Foundation, which is a standard library for creating applications that are claims-aware. You may or may not need an identity selector; if you did, Microsoft is working on CardSpace version 2.0 to take on that role. 

If you want a much more controllable version of claims-based authentication, you can add U-Prove to the mix; it’s a cryptographic technology that integrates with WIF, ADFS 2.0, and CardSpace 2.0. Purchased by Microsoft in 2008 from Credentica, U-Prove was released in March 2010 under its “open specification” promise, and there are open source reference toolkits in C# and Java and a Community Technology Preview that includes a ton of information.

Just because I’ve presented only one view of ADFS 2.0 — that of a single sign-on with users and external, on-premise applications — don’t pigeonhole this technology. You might use it in your enterprise to provide access to applications developed for use in-house. You might use it for applications used in the enterprise that need to authenticate users coming from the Internet. You might develop an application that accepts tokens from trusted identity providers (a good example is Windows Live ID). You might use the same technology to work between two enterprises so that users in the one enterprise can access to an application residing in another. And certainly, with cloud computing, you can see how claims can be used to provide single sign-on to cloud-based applications running on platforms like Microsoft Azure.

ADFS 2.0, if it lives up to its claim (pun intended), will help bring about the elusive single sign-on that so may users, admins, and developers have hoped for all these years — without creating the security risks these same users, admins, and developers continue to fear. As I gain more experience with ADFS 2.0, I’ll keep you posted on how well it delivers on that hope.

This article, “Does ADFS 2.0 deliver on its single sign-on promise?,” was originally published at InfoWorld.com. Read more of J. Peter Bruzzese’s Enterprise Windows blog and follow the latest developments in Windows at InfoWorld.com.