If you’re doing research on protocols that enable single sign-on, a typical question is, “How does SAML work?” (credits: http://www.gluu.org/blog/how-does-saml-work-idps-sps/)

” SAML, or Security Assertion Markup Language, is the leading SSO protocol today and is a valuable standard to understand in order to fully comprehend how single sign-on works.

SAML boils down to attribute exchange through the creation of trust relationships between IdP’s and SP’s. A basic example is signing into your active directory to log on to your work computer in the morning, and automatically gaining access to your company gmail or salesforce.

The three main components of the SAML protocol:

  • Assertions – Most common are the following 2 SAML assertions:
    • Authentication assertions are used to make people prove their identities.
    • Attribute assertions are used to generate specific information about the person, for example their phone number or email address.
  • Protocol – This defines the way that SAML asks for and gets assertions, for example, using SOAP over HTTP.
  • Binding – This details exactly how SAML message exchanges are mapped into SOAP exchanges.

5 Benefits of using a SAML IdP:

There are many reasons to use a SAML IdP. Besides being the dominant single sign on protocol in use today, there are a host of reasons an organization should consider implementing a SAML IdP. Here are 5 reasons to use SAML for SSO:

1. User passwords never cross the firewall, since user authentication occurs inside of the firewall and multiple Web application passwords are no longer required.

2. Web applications with no passwords are virtually impossible to hack, as the user must authenticate against an enterprise-class IdM first, which can include strong authentication mechanisms.

3. “SP-initiated” SAML SSO provides access to Web apps for users outside of the firewall. If an outside user requests access to a Web application, the SP can automatically redirect the user to an authentication portal located at the Identity Provider. After authenticating, the user is granted access to the application, while their login and password remains locked safely inside the firewall.

4. Centralized federation provides a single point of Web application access, control and auditing, which has security, risk and compliance benefits.

5. A properly executed identity federation layer that satisfies all of the use cases described above and supports multiple protocols can provide an enterprise-wide, architecturally sound Internet SSO solution ”

For more on the SAML protocol and transaction steps, go to: http://en.wikipedia.org/wiki/SAML_2.0

SAML transaction steps (overview): Let’s take a real-life example. Say someone logs in and uses a Web service, is authenticated and then wants to go to a partner site. With SAML, he can be authenticated at the second site without having to sign on. The nearby figure shows each step of the process:

In Step 1 the user has authenticated himself with Site 1 and wants to visit Site 2. He clicks on a link to go to Site 2.

In Step 2, instead of being sent straight to Site 2, he is instead sent to the SAML service for Site 1.

In Step 3 the SAML service appends a partner ID and a special handle to Site 2’s URL in the user’s browser. For example, if the user wants to go to the site http://www.softprovider.com, after the SAML service appends the extra information, the URL might now be https://www.softprovider.com?SAMLart=  . Note that the protocol has changed to the secure https instead of http. The user is redirected now to Site 2’s SAML service, which examines the URL with the appended information. Based on the information in the URL, Site 2’s SAML service communicates with Site 1’s, and Site 1 sends along the authenticated identity of the user, along with any rights that the user has.

In Step 4 the user is sent to Site 2, fully authenticated. The user can now perform transactions on the site just as if he had logged directly into the site.