Over the past several months I’ve seen 4 or 5 presentations on ADFS2. And of course, ADFS2 was released to the web on 5/5/2010. And as announced previously on this blog, we’re actively in a partnership with Microsoft around Shib interop with ADFS2.

So it’s time for all this material to get into a blog post. 🙂

First, see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:%20MicrosoftDownloadCenter%20(Microsoft%20Download%20Center) for the ADFS2 download.

Second, the terminology is important to understand, so here’s a decoder ring. I’ve put in bold the terms I think make the most sense to use.

Security Token Service (STS) = Identity Provider (IdP) = Issuer = the server that verifies identity, adds claims, and issues a SAML token.

Claims = Attributes = Assertions = information about the identity associated with the login token which the token issuer claims/asserts are true.

Relying Party (RP) = Service Provider (SP) = Consumer = a server which wants to consume a federation token, possibly using claims in that token for authorization decisions.

One really important concept to understand about the federation IdP/STS role server is that it is *all* about issuing a token in a standardized form, which in both the Shibboleth and ADFS (either version) cases is a SAML 1.1 token. It takes some form of authentication credentials and “transforms” those provided credentials into a SAML token which you can use in a standardized way. So if you are a Math or Coding geek (as I am) you might think of the federation IdP/STS server as a function that transforms non-standard input into a standardized output. Or if you’ve travelled at all, you might think of the IdP/STS as the money exchange you have to visit each time you go from one country to another. You have currency–it’s just that no one accepts the currency you have, and so you need to get the currency that is accepted locally.

Another really important concept to understand is that the Consumer only knows about a single Issuer, or put another way: the Consumer only trusts a single Issuer. I talk about the federated access dance down below.

Third, you might be wondering a lot of various questions.

Why federate? Why not use Windows Integrated Authentication?
Common answers are:

• you’ve got stuff to protect that isn’t Windows based
• you need to give folks outside the UW access
• you are porting your app to the cloud

Why use ADFS when we’ve already got Shibboleth?
The answer there is much more complex. As I’ve already said previously, ADFS2 has interop features with Shib, so stuff that uses an ADFS2 Security Token Service (STS)–which means the same thing as an IdP in Shibboleth-speak–can accept SAML 1.1 login tokens from a Shib IdP.

But there is more to federation than just issuing login tokens. You also need to accept federated login tokens, i.e. the role that Shib calls a Service Provider (SP) and ADFS calls a Relying Party (RP). And assuming you are accepting login tokens from elsewhere, you also need to perform token transformation or claims transformation. Claims transformation is the process of taking claims issued by another authority and tranforming them to mean something within your environment, typically for use in authorization or to populate a user’s details in an application.

Something like Sharepoint 2010 has built-in support for ADFS2, meaning that as a RP, it understands ADFS2 issued tokens and can leverage ADFS2 claims transformations. As I understand it, *only* using Shibboleth to federate Sharepoint 2010 means you’d need to write code for some custom claims transformations.

So the more appropriate question is can we leverage Shibboleth as the point of token issuance along with ADFS2 for the claims transformation? And the answer to that is yes. I’ve seen several demos of this working.

The trick then becomes figuring out whether you also want to be able to use ADFS2 for token issuance.

Why might you want to use ADFS2 for token issuance on top of Shibboleth?

Well, your Windows login token, i.e. the one you get when you interactively login to your computer via a Windows domain account, can be used to automatically get an ADFS2 login token without throwing yet another authentication prompt in the user’s face. With the advent of UWWI delegated OUs, you might believe that reducing the number of logins is desirable and attainable for some population. Whether there is enough demand there isn’t clear to me yet.

However, if it was something we wanted, then we’d next need to deploy a custom WAYF on the ADFS2 server.

What’s WAYF?

WAYF stands for Where Are You From? WAYF is the mechanism where the client chooses what Issuer they’d like to authenticate with. You’ve probably used the WAYF associated with InCommon to choose that you are from the UW and want to login against the UW Shibboleth IdP. In this case, we’d need to have a WAYF that gave 2 options:

• UW Shibboleth (i.e. Weblogin)
• UW ADFS (i.e. UWWI).

Moving on from high-level stuff, let’s talk more about details.

The federated access dance is something like this:
a) client goes to Consumer (a website)
b) Consumer asks client for a valid token
c) Client tell Consumer it doesn’t have a token
d) Consumer sends a 302 redirect to client to talk it its Issuer (Issuer A)
e) Consumer hits the WAYF at Issuer A
f) Consumer chooses something from WAYF and gets sent a 302 redirect to their Issuer (Issuer B)
g) Client hits Issuer B, provides credentials
h) Client is issued a SAML token by their Issuer (Issuer B), gets sent a post redirect to the original Issuer (Issuer A)
i) Client hits the original Issuer (Issuer A), which takes the SAML token from Issuer A, and transforms it, issuing a new SAML token and sending a post redirect to the Consumer. The transform may drop some claims and add some new claims, all based on business rules specific to the trust between Issuer A and Issuer B.
j) Client hits the Consumer and presents a valid token
k) Consumer evaluates claims in token, and decides what resources the client has access to. In some cases (e.g. Sharepoint 2010), it might have its own “internal” STS that is used across a farm of resources, and issue yet another token to the client (sending us back to step i).

ADFSv2 supports the following possible authentication sources:

• Active Directory
• a “chained” SAML 1.1 token, i.e. a token issued by another federation server

If you have a different authN source (say MIT KDC) or to accept some other kind of token, you no longer can use the “out of the box” ADFS product, but need to build your own STS using the Windows Identity Framework SDK. Many online examples show you how to do this in a step-by-step approach, but this is not for the faint of heart. This point is important to keep in mind, because sometimes when people say they are using ADFS for some interop scenario, they aren’t–they are using a custom STS that is really just a distant cousin of ADFS.

ADFSv2 supports the following possible directory sources for claims:

• Active Directory
• MS AD Lightweight Directory Services (LDS)
• SQL
• LDAP directory which uses Windows integrated