SAML (Security Assertion Markup Language) is an XML-based framework for communicating user authentication, entitlement and attribute information between different organizations. SAML is developed by OASIS (Organization for the Advancement of Structured Information Standards). SAML abstracts authentication mechanism so that it is not tied to any vendor specific implementations.

SAML Participants

In Web SSO user authenticates to one web site and then without additional authentication user is able to access a protected resource at another site.

 

 

Identity Provider:

Identity Provider is an entity that authenticates users during web SSO. Identity Provider creates maintains and manages user’s identity information.

Service Provider:

Service provider is an entity that provides services. Service provider relies on a trusted identity provider for user authentication and authorization. Service provider is also called as Relying Party.

SAML addresses following limitations

  • Most of the existing products which support SingleSignOn use browser cookies to maintain state, so that re-authentication is not required. Browser cookies are not transferred between domains. For providing the cross domain SingleSignOn, SSO products use different techniques.
  • When SSO products which have proprietary mechanism are used to provide the cross domain SSO, all the partners need to use same SSO product, which may not be possible in all cases.

Since SAML is an XML-based framework, it has extensibility which makes it a very flexible standard. Interoperability also gives huge advantage over SSO products which has proprietary mechanism.

SAML2 Use Cases

Identity provider initiated SSO:

In an IDP initiated use case, Instead of visiting SP directly, the user accesses the IDP site and then clicks on one of the links to gain access to the protected resource on service provider. This triggers creation of a SAML assertion which is sent to the service provider.

Service provider initiated SSO:

In SP initiated SSO, the user attempts to access a protected resource on SP. As user does not have a session on SP, User is sent to the IDP for login and IDP provides a SAML assertion with the user identity back to the SP.

Service provider initiated Single Logout:

In SP initiated log out, SP destroys the local session and then sends a request to IDP requesting log out on user session.

Identity provider initiated Single Logout:

In this use case, log out process is initiated by the user visiting the IDP.

 

Identity provider initiated Single Sign On

Identity provider is configured with the links that refer to the service provider; these links actually refer to the IDP’s SSO service.  When a link is clicked, IDP generates SAML assertion which is sent to the remote service provider. SAML assertion contains user authentication and authorization information.

1)    User tries to access the IDP

2)    User is asked to provide credentials.

3)    User provides valid credentials.

4)    User access links on the IDP to request access to the remote service provider.

5)    IDP SSO service creates a SAML assertion which contains user information. SAML Assertion is sent to service provider using HTTP POST.

6)    Service provider’s Assertion Consumer Service get the SAML assertion from HTTP POST request and validates the digital signature on the SAML assertion. Assertion content is processed in order to create a session for the user in SP. If Relay State information is provided then SP determines desired application resource URL and sends HTTP redirect to the browser directing to access the requested resource.

In order to configure SSO, Service Provider needs to be registered with the IDP. To accomplish this, the SAML specification defines a format for “SAML Metadata” which tells the IDP about service provider’s Assertion Consumer Service. Metadata file can help the identity provider understand what the service provider need in the SAML assertion.

Example MetaData:

<EntityDescriptor entityID=”http://serviceprovider/sso“>

<SPSSODescriptor protocolSupportEnumeration=”urn:oasis:names:tc:SAML:2.0:protocol”> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</NameIDFormat> <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat> <AssertionConsumerService index=”0″ isDefault=”true” Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”http://serviceprovider/assertion_consumer_service.jsp“/>

</SPSSODescriptor>

<Organization>

<OrganizationName xml:lang=”en”>ServiceProvider</OrganizationName> <OrganizationDisplayNamexml:lang=”en”>ServiceProvider</OrganizationDisplayName>

<OrganizationURL xml:lang=”en”>www.serviceprovider.com</OrganizationURL>

</Organization>

</EntityDescriptor>

Example SAML Assertion with subject

<saml:Assertion>

<saml:Issuer>https://identityprovider/sso/saml2</saml:Issuer>

<saml:Subject>

<saml:NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”> userid@idp.com

</saml:NameID>

</saml:Subject>

</saml:Assertion>