Posts‎ > ‎

Identity I: SAML Single Sign On Tutorial

posted May 29, 2011, 6:55 AM by Ellie Kesselman   [ updated Jun 3, 2011, 6:41 AM ]


Security Assertion Markup Language (SAML) enjoys the dominant position in terms of industry acceptance and production federated identity deployments. SAML is deployed in tens of thousands of Cloud Single Sign-On (SSO) connections, and thousands of large enterprises, government agencies and service providers have selected it as their standard protocol for communicating identities across the Internet.

How it Works

The SAML 2.0 (since 2005) has been the standard managed by the OASIS Security Services Technical Committee. SAML 2.0 is actually a combination of three predecessor identity federation standards: SAML 1.1, ID-FF (Identity Federation Framework) 1.2, and Shibboleth.


Since it is XML-based, SAML has extensiblity, which makes it a very flexible standard. Two federation partners can choose to share whatever identity attributes they want in a SAML assertion (message) payload as long as those attributes can be represented in XML. This flexibility has even led to SAML  being incorporated into other standards such as WS-Federation.

Interoperability gives SAML an advantage over proprietary SSO mechanisms, which require the Identity Provider (IdP) and Service Provider (SP) to both implement the same software. For an enterprise, proprietary SSO means each  connection potentially requires different software implementation. With SAML, a single implementation can support SSO connections with many different federation partners.  

The Kantara Initiative, formerly known as the Liberty Alliance, has established a very successful testing program where SAML vendors prove out-of-the-box interoperability with other SAML implementations


Liberty certified over 80 solutions from numerous vendors and organizations worldwide. PingFederate has completed SAML 2.0 interoperability testing with more vendors than any other.

When establishing a new SAML connection, the primary reason projects fail or experience costly delays is because the security, scalability and interoperability is either not tested or not proven. A certified product can be the difference between a two-hour configuration and testing exercise or a multi-month distributed debugging nightmare. In 2007, the US GSA began requiring successful certification testing for participating in the US E-Authentication Identity Federation.