Is anyone really using Active Directory Federation Services? Is this a technology worth investing in?

Question

More generally, who is successfully using WIF/ADFS/SSO on the Windows platform, and is it worth implementing, and what is the likeliness it will be a lasting technology?

On the surface, from reading a few whitepapers (PDF), articles and books on the subject, this seems like the perfect solution -- especially for a company that has an internal web site that exposes some level of functionality to external users and partners as well (or plans to in the future). But it sounds almost too perfect. And most of the information I have comes from Microsoft themselves.

I guess my specific questions are:

• Is this a lasting technology and worth investing in (and specifically for a smaller sized (<50 ppl) company)?
• Are there any major companies out there that are actively using this?
• How likely is it that a partner would be willing to setup an STS if we wanted someone else to provide authentication for their company as a trusted issuer? Is there going to be a lot of push-back here?
• Is this going to end up being a configuration nightmare?
• Are there any other pitfalls to look out for when deciding whether to implement this?

Answer 1

As more applications are moved to the cloud and to online services you will see ADFS and other federated identity technologies increase in usage. Organizations with investments in Active Directory will likely move to this solution due the low cost of ownership.

Is this a lasting technology and worth investing in (and specifically for a smaller sized (<50 ppl) company)?

• If you plan on either providing hosted services to other companies or plan on taking advantage of them yourselves ADFS provides a fairly painless way to take advantage of your current security infrastructure.
• If properly implemented it should be fairly simple to replace on federation product with another.

Are there any major companies out there that are actively using this?

• I'm only familiar with a government organization I've worked on, but I'm sure there are others. The nature of federated identity make if difficult to externally identify who.

How likely is it that a partner would be willing to setup an STS if we wanted someone else to provide authentication for their company as a trusted issuer? Is there going to be a lot of push-back here? Is this going to end up being a configuration nightmare?

• Configuration is the most difficult part of ADFS. However, once you have the trust relationships built and policies created configuration will be hands off.
• Other companies will either have the infrastructure in place to support ADFS or won't. Even .NET applications require configuration changes to support ADFS and more likely will require code changes to fully support the federated identity model. If your partners have this in place it is likely they'll happily trust your STS.
• Ask your what your partners have in place, they may already have or be planning infrastructure today.

Are there any other pitfalls to look out for when deciding whether to implement this?

• The most difficult problem I ran into was changing application developer practices.
• Applications need to either be designed around Federation or will need to be retrofitted with it.
• You can't logout of an ADFS application without logging out of all ADFS applications.
• When a federated session expires you must send a user back to the federation service for a new ticket. This could cause loss of post data if not handled properly.

Answer 2

From my experience:

In conjunction with WIF, ADFS offers:

• Standard "outsourced" authentication / authorisation for ASP.NET applications. Once the applications are claims aware, you can make changes on the ADFS / ACS side and the application doesn't change.

• Provides federation facilities with non .NET solutions e.g. OpenSSO and Tivoli.

• Allows (via ACS) use of existing logins e.g. Facebook / Google.

• Provides potential for applications to migrate to the cloud (Azure).

• Standard claims-aware functionality for Sharepoint 2010.

The implementations I've seen are mainly for larger companies trying to put some kind of overall I&AM in place. It's especially useful when companies have both .Net and Java applications in place.

Also in NZ, we have an igovt login which provides one login to all governments departments and this is a possible candidate for "use an existing login" rather than creating a company specific one. igovt can federate with ADFS.

Main pitfall in my experience is that it doesn't work for classic ASP. It has to be ASP.NET.

To answer your other questions:

• Larger companies who want to allow external access to their applications would far rather implement an STS than provision external users in their identity repository.

• Configuration is not trivial but certainly doesn't become a nightmare.