Single sign-on with SAML Standards

Single sign-on (SSO)

It is a session/user authentication process that permits a user to enter one name and password in order to access multiple applications/websites. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session.

SSO Advantages

  • Reducing password fatigue from different user name and password combinations
  • Reducing time spent re-entering passwords for the same identity
  • Reducing IT costs due to lower number of IT help desk calls about passwords
  • SSO uses centralized authentication servers that all other applications and systems utilize for authentication purposes, and combines this with techniques to ensure that users do not have to actively enter their credentials more than once.
  • SSO users need not remember so many passwords to log in to different systems or applications.

Introduction to SAML

Security Assertion Markup Language is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is a product of the OASIS Security Services Technical Committee.

SAML Roles

The SAML specification defines three roles: the principal (typically a user), the identity provider (IdP), and the service provider (SP). In the use case addressed by SAML, the principal requests a service from the service provider. The service provider requests and obtains an identity assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision – in other words it can decide whether to perform some service for the connected principal.

Before delivering the identity assertion/user-information to the SP, the IdP may request some information from the principal – such as a user name and password – in order to authenticate the principal. SAML specifies the assertions between the three parties: in particular, the messages that assert identity that are passed from the IdP to the SP. In SAML, one identity provider may provide SAML assertions to many service providers. Conversely, one SP may rely on and trust assertions from many independent IdPs.

SAML Entities

1. Asserting party (AP) or Identity Provider (IDP)
  • IDP is a service /website that provide user identity information like (username, security token and email address etc…) through Saml-2 Request/Response using HTTP-POST.
  • Send assertions to relying party.
2. Relaying party (RP) or Service Provider (SP)
  • This is the actual website/client consumes the Identity information shared by the IDP through Saml 2
    Request/Response using HTTP-POST.
  • Consume the assertions from AP/IDP.
3. Assertions
  • Data exchanged from AP to RP (XML Data).
  • Can include user identity, authentication data, or any other attributes.
4. User/Actor/Browse
  • Request protected resource from service provider.
  • Act as bridge between SP and IDP for SAML communication.

The SAML Use Case Diagram

The primary SAML use case is called Web Browser Single Sign-On (SSO). A user wielding a user agent (usually a web browser) requests a web resource protected by a SAML service provider. The service provider, wishing to know the identity of the requesting user, issues an authentication request to a SAML identity provider through the user agent.

1. Request the target resource at the SP (SAML 2.0 only)
  • The principal (via an HTTP user agent) requests a target resource at the service provider:
  • The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2–7.
2. Redirect to the SSO Service at the IdP (SAML 2.0 only)
  • The service provider determines the user’s preferred identity provider and redirects the user agent to the SSO Service at the identity provider:
  • The value of the SAMLRequest parameter must be Base64 encoded in <samlp:AuthnRequest> element.
3. Request the SSO Service at the IdP (SAML 2.0 only)
  • The user agent issues a GET request to the SSO service at the identity provider where the value of the SAMLRequest parameter is taken from the URL query string at step 2. The SSO service processes the AuthnRequest and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).
4. Respond with an XHTML form
  • The SSO service validates the request and responds with a document containing an XHTML form:
  • <form method=”post” action=”” …>    <input type=”hidden” name=”SAMLResponse” value=”response” />    …    <input type=”submit” value=”Submit” />  </form>

  • The value of the SAMLResponse parameter is the base64 encoding of a <samlp:Response> element.
5. Request the Assertion Consumer Service at the SP
  • The user agent issues a POST request to the assertion consumer service at the service provider. The value of the SAMLResponse parameter is taken from the XHTML form at step 4.
6. Redirect to the target resource
  • The assertion consumer service processes the response, creates a security context at the service provider and redirects the user agent to the target resource.
7. Request the target resource at the SP again
  • The user agent requests the target resource at the service provider (again):
8. Respond with requested resource
  • Since a security context exists, the service provider returns the resource to the user agent.


SAML 2 Login/Authenticate Request

<samlp:AuthnRequest ID=”_7B0D70470FDE6C2A98D3DC481FC42169″ Version=”2.0″ IssueInstant=”2012-10-04T20:03:18.89Z” Destination=”” ForceAuthn=”false” IsPassive=”false” ProtocolBinding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” AssertionConsumerServiceURL=”” xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol”>
<saml:Issuer xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”>https:// /</saml:Issuer>
<Signature xmlns=””>
<CanonicalizationMethod Algorithm=”” />
<SignatureMethod Algorithm=”″ />
<Reference URI=”#_7B0D70470FDE6C2A98D3DC481FC42169″>
<Transform Algorithm=”” />
<Transform Algorithm=””>
<InclusiveNamespaces PrefixList=”#default saml ds xs xsi” xmlns=”” />
<DigestMethod Algorithm=”″ />










<samlp:NameIDPolicy AllowCreate=”true” />

SAML 2 Login/Authenticate Response

<samlp:Response ID=”_7A8D347ED92DF25C24DDC641D3E59FF8″ Version=”2.0″ IssueInstant=”2012-10-30T07:29:03.427Z” xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol”>
<saml:Issuer xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”> /</saml:Issuer>
<Signature xmlns=””>
<CanonicalizationMethod Algorithm=”” />
<SignatureMethod Algorithm=”″ />
<Reference URI=”#_7A8D347ED92DF25C24DDC641D3E59FF8″>
<Transform Algorithm=”” />
<Transform Algorithm=””>
<InclusiveNamespaces PrefixList=”#default saml ds xs xsi” xmlns=”” />
<DigestMethod Algorithm=”″ />





















<samlp:StatusCode Value=”urn:oasis:names:tc:SAML:2.0:status:Success” />
<saml:Assertion Version=”2.0″ ID=”_3EB54042A2BA196880600FE7C9C17873″ IssueInstant=”2012-10-30T07:29:03.451Z” xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion”>
<saml:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:bearer”>
<saml:SubjectConfirmationData NotBefore=”2012-10-30T07:19:03.456Z” NotOnOrAfter=”2012-10-30T07:39:03.456Z” Recipient=” /sso/spacs.aspx?wreply” InResponseTo=”_E6A841164DFC1FCB90B5C8583E9C6A92″ />
<saml:Conditions NotBefore=”2012-10-30T07:19:03.456Z” NotOnOrAfter=”2012-10-30T07:39:03.456Z”>
<saml:AuthnStatement AuthnInstant=”2012-10-30T07:29:03.488Z”>

<saml:Attribute Name=”urn:oid:anrsso:companyname” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” FriendlyName=”CompanyName”>
<saml:Attribute Name=”urn:oid:anrsso:countrycode” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” FriendlyName=”CountryCode”>
<saml:Attribute Name=”urn:oid:anrsso:emailaddress” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” FriendlyName=”EmailAddress”>
<saml:Attribute Name=”urn:oid:anrsso:firstname” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” FriendlyName=”FirstName”>
<saml:Attribute Name=”urn:oid:anrsso:gwuserid” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” FriendlyName=”GWUserId”>
<saml:Attribute Name=”urn:oid:anrsso:jobtitle” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” FriendlyName=”JobTitle”>
<saml:Attribute Name=”urn:oid:anrsso:lastname” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” FriendlyName=”LastName”>
<saml:Attribute Name=”urn:oid:anrsso:loginname” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” FriendlyName=”LoginName”>
<saml:Attribute Name=”urn:oid:anrsso:secretkey” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:uri” FriendlyName=”SecretKey”>

SAML Advantages

  • Platform neutrality. SAML abstracts the security framework away from platform architectures and particular vendor implementations. Making security more independent of application logic is an important tenet of Service-Oriented Architecture.
  • Loose coupling of directories. SAML does not require user information to be maintained and synchronized between directories.
  • Improved online experience for end users. SAML enables single sign-on by allowing users to authenticate at an identity provider and then access service providers without additional authentication. In addition, identity federation (linking of multiple identities) with SAML allows for a better-customized user experience at each service while promoting privacy.
  • Reduced administrative costs for service providers. Using SAML to ‘reuse’ a single act of authentication (such as logging in with a username and password) multiple times across multiple services can reduce the cost of maintaining account information. This burden is transferred to the identity provider.
  • Risk transference. SAML can act to push responsibility for proper management of identities to the identity provider, which is more often compatible with its business model than that of a service provider.


Reference links:

About The Author

Leave a Reply