Identity Federation is becoming a hot feature for web applications.  Salesforce.com now supports federation, such that your corporate network credentials can be used to access the applications.  Boeing, for another example, is federating its employee accounts to dozens of applications.  I have personally yearned for Passport/Live ID integration for years, and this is an enabler for that too.

Ws-Federation Products

I identified numerous products that seem to support WS-Federation.

• Active Directory Federation Services (ADFS) - A built-in component of Windows Server 2003 R2 that "extends Active Directory over the Internet".  In the account partner scenario, your directory of user accounts can be used by other sites.  In the resource partner scenario, your claims-enabled ASP.NET 2.0 application can (with the help of the ADFS-supplied System.Web.Security.SingleSignOn.dll) authenticate/authorize against credentials from other sites. 
• Ping Federate - A Java-based federation server product that supports database-backed credentials, provides library code for a variety of platforms, and has interesting licensing options including an easy-on for single-partner federation.
• IBM Tivoli Federated Identity Manager
• Shibboleth - An Internet2 initiative related to federation.  It has been deployed by the InCommon people among others; check out the login options provided by the Shibboleth Wiki for a great example of federation in action.

WS-Federation and Passport (aka Windows Live ID)

It is public knowledge that Live ID will support WS-Federation.  It will no doubt plug in seamlessly into ADFS (or other federation server) as an account partner, such that your claims-enabled application can use Live ID accounts with ease.  This has long been envisioned by Microsoft; see this "Network of Trust" article. 

ADFS and Account Stores (Active Directory)

ADFS, acting as a resource server, can be useful without the involvement of Active Directory.  But let's face it, you are likely porting an application with legacy accounts, so you must also act as an account partner to your own application.  How to best hook your assumedly database-backed accounts into ADFS?  You have at least four options.  One, migrate your accounts into AD or ADAM.  Two, use a product such as Microsoft Identity Integration Server to synchronize the accounts with AD.  Three, implement WS-Federation directly.  Four, buy a federation product with good support for database-backed credentials.  I chose the third option, which I will discuss below. 

ADFS Development

To implement WS-Federation to act as an account server, I located a great piece of sample code from the Microsoft Patterns & Practices group.  The SAML STS for WSE 3.0 QuickStart sample provides much of the code needed to generate and sign a SAML 1.1 token, which is the most substantial aspect of implementing WS-Federation. 

The missing ingredient in the QuickStart is support for WS-Federation Passive Profile, which in essence consists of an HTTP handler, some user/roles lookup code, and some federation-specific claims code.  This code was surprisingly easy to write.  Achieving interop with ADFS was, on the other hand, a bit of a nightmare. 

ADFS simply rejected my SAML token with a vague validation error.  By instrumenting and debugging the ADFS server library (using this great technique) I identified the four problems that were behind it:

1. The Subject must be specified on every SAML statement (my fault). 
2. The SubjectLocality must not be specified (interop issue).
3. The XML signature is sensitive to the method used to serialize the security token.  The entire WSE3 SecurityTokenResponse is first serialized to an instance of XmlDocument.  I then used the Save method to emit the literal XML to be passed using a hidden form field as described by the passive profile.  The signature would then fail to be validated by ADFS, despite the canonicalization method that is applied on both ends.  The solution turned out to be to use DocumentElement.OuterXml instead; a very subtle and frustrating issue.
4. The self-signed certificate I was using was unusable because its revocation status could not be checked (0x80092012 CRYPT_E_NO_REVOCATION_CHECK).  Certificate Revocation List checking can be disabled for ADFS by following these instructions (which I simply applied manually to TrustPolicy.xml).

Of course, whenever developing with ADFS be sure to enable the myriad of debug flags in the snap-in, in the server's web.config, and perhaps in the registry as documented in the troubleshooting guide. 

I whoteheartedly recommend experimenting using the ADFS Virtual Lab, then subsequently using Virtual Server on your workstation (complete with undo disks) to develop an ADFS solution.

ADFS Profile

Here is some facts I know about ADFS, after long hours of debugging.  More interop knowledge can be obtained by examining the Shibboleth source code and notes.

With respect to SAML attribute statements, ADFS supports a single namespace to carry the group and custom claims:

ADFS in the Future

ADFS is a maturing component of Windows Server.  Today it supports only the WS-Federation Passive Requestor Profile, which allows browsers to support single sign-on.  Future versions will support the Active Client Profile, which allows web services to support impersonation of federated identities.

Longhorn appears to be taking it further yet (beyond Active Directory perhaps):

“A WCF-based system has several system services that provide essential functionality to all services. One of these services is identity federation. An upcoming version of the security system in Windows supports a federation service that allows identities from foreign trust boundaries to be managed and validated. The Windows federation service uses WS-Federation to securely broker the authentication between the service and the corresponding trust authority.”

What is the Windows Communication Foundation?

Hope this information helps!