SAML vs. WS-Federation for Single Sign-On

JUNE 28, 2012 BY OLEG_COHEN LEAVE A COMMENT

Two very popular standards for single sign-on are Security Assertion Markup Language (SAML) and Web Services Federation Language (WS-Federation).  They are very similar but also incompatible.  What’s the difference?  Which one should you use?  What are some of the common pitfalls?

SAML and WS-Federation are both standards that allow users that have already logged into one site to access another site without logging in again.  They both do this by allowing sites to present proof that a site and a user are who they say they are.  They both support single sign-out and they both support metadata to exchange SSO information between parties.  They also have bells and whistles to support building large complex federations of many sites in a sophisticated web of trust.  In reality, most people only use the “passive” features that allow single sign-on between web sites.  WS-Federation is primarily championed by Microsoft Corporation which has invested heavily into incorporating WS-Federation into its products.  SAML is an older specification that is well supported by many identity management vendors.  However, most vendors, including Microsoft, are moving to support both standards.  So what’s the difference?  For solving single sign-on problems, not much.  They use different terminology.  One may be easier to set up depending on the environment. But, either can meet your SSO needs.

So which should you choose?  SAML is an older protocol and enjoys widespread support.  Software-as-a-Service (SaaS) vendors are more likely to support it than WS-Federation.  On the other hand, if you are in a mostly Microsoft world, WS-Federation is more ubiquitous.  Microsoft’s Active Directory Federation Services (ADFS) comes with Active Directory supports both WS-Federation and SAML but is easier to configure for WS-Federation.  Microsoft’s Windows Identity Foundation (WIF) toolkits make it easy to enable home-grown ASP.NET applications for WS-Federation.  WIF SAML support is currently in a community technology preview (CTP) release.

You can comfortably pick either standard and implement single sign-on.  The best approach is to understand the various partners, vendors, customers, systems that you indend to federate and see what they support.  The biggest issues to watch out for are: 

1. Underestimating the effort.  Both SAML and WS-Federation are complex, particularly when there are multiple parties involved.  Everyone will have a slightly different implementation and it takes deep expertise to figure out the nuances.  Make sure you have qualified SSO expertise available when implementing.
2. Assuming there is interoperability between the standards.  WS-Federation carries its credentials in claims, and the most popular claim type is, ironically, a SAML Assertion.  This leads people to think that WS-Federation and SAML can talk to each other.  It also leads some SaaS vendors to say they support SAML when they really support SAML claims inside WS-Federation.  Some vendors, including AssureBridge, provide bridging technology between the standards, but it’s better to stick to a single protocol when possible.