SAML overview

Security Assertion Markup Language (SAML) is an XML standard for exchanging single sign-on information between an identity provider who asserts the user identity and a service provider who consumes the user identity information.

The SAML Enterprise Identity Source acts as a service provider. It allows an application to contact a separate identity provider to authenticate users and consume the returned user identity information.

The identity provider must provide the URL to initiate a SAML single sign-on flow and the SAML 2.0 identity provider metadata file to enable the SAML Enterprise Identity Source to communicate with the identity provider. The SAML 2.0 identity provider metadata file must be in accordance with the SAML 2.0 specification. It must contain the identity provider’s public key for the SAML Enterprise Identity Source to validate its digital signature and the single sign-on service endpoint for HTTP POST binding.

Following is a sample SAML 2.0 metadata file.

<?xml version=”1.0″ encoding=”UTF-8″?>

<md:EntityDescriptor xmlns:md=”urn:oasis:names:tc:SAML:2.0:metadata” entityID=”https://idp.example.com/SAML”>

<md:IDPSSODescriptor WantAuthnRequestsSigned=”true” protocolSupportEnumeration=”urn:oasis:names:tc:SAML:2.0:protocol”>

   <md:KeyDescriptor use=”signing”>

     <KeyInfo xmlns=”http://www.w3.org/2000/09/xmldsig#”>

       <X509Data>

         <X509Certificate>idp.example.com SSO key</X509Certificate>

        </X509Data>

     </KeyInfo>

   </md:KeyDescriptor>

   <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>

   <md:SingleSignOnService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”https://idp.example.com/SAML/SSO/POST”/>

</md:IDPSSODescriptor>

<md:Organization>

   <md:OrganizationName xml:lang=”en”>idp.example.com</md:OrganizationName>

   <md:OrganizationDisplayName xml:lang=”en”>Example Identity Provider</md:OrganizationDisplayName>

   <md:OrganizationURL xml:lang=”en”/>

</md:Organization>

</md:EntityDescriptor>

The identity provider must obtain the SAML 2.0 service provider metadata file from the SAML Enterprise Identity Source to enable the identity provider to communicate with the SAML Enterprise Identity Source. The content of the SAML 2.0 service provider metadata file that is generated by the Enterprise Identity Source is in accordance with the SAML 2.0 specification.

The SAML Enterprise Identity Source supports HTTP POST binding and identity provider initiated SAML single sign-on flow.

  1. The single sign-on process starts with a user who attempts to access secure web content on the application. The user’s browser is redirected to the URL provided by the identity provider to initiate a SAML single sign-on flow.
  2. The identity provider authenticates the user and generates a SAML response that asserts that the user was authenticated. The SAML response can also carry attributes about the user that the identity provider wants to make available to the service provider. The content of the SAML response must be in accordance with the SAML 2.0 specification and digitally signed.
  3. The identity provider base-64 encodes the SAML response and places it in a hidden form control within a form in an XHTML document and returns the document to the user’s browser.
  4. The user’s browser delivers the SAML response by issuing an HTTP POST request to the SAML Enterprise Identity Source.
  5. The SAML Enterprise Identity Source verifies the SAML response. If the verification is successful, the SAML Enterprise Identity Source propagates the user identity information in the SAML Attribute Assertion <saml:AttributeStatement> to the application.

See the following example of a SAML response whose Attribute Assertion <saml:AttributeStatement> contains the emailAddress and mobileNumber attributes to be propagated to the application.

<?xml version=”1.0″?>

<samlp:Response xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” xmlns:samlp=”urn:oasis:names:tc:SAML:2.0:protocol” xmlns:xs=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” ID=”FIMRSP_549f7c46-014a-195f-b377-f24678dbf88a” IssueInstant=”2014-12-16T19:42:25Z” Version=”2.0″>

<samlp:Status>

   <samlp:StatusCode Value=”urn:oasis:names:tc:SAML:2.0:status:Success”/>

</samlp:Status>

<saml:Assertion ID=”Assertion-uuid549f74ad-014a-120d-a67b-f24678dbf88a” IssueInstant=”2014-12-16T19:42:23Z” Version=”2.0″>

   <saml:Issuer Format=”urn:oasis:names:tc:SAML:2.0:nameid-format:entity”>https://idp.example.com/SAML</saml:Issuer>

   <saml:Subject>

     <saml:NameID Format=”urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress”>testuser</saml:NameID>

     <saml:SubjectConfirmation Method=”urn:oasis:names:tc:SAML:2.0:cm:bearer”>

       <saml:SubjectConfirmationData NotOnOrAfter=”2014-12-16T19:43:23Z” Recipient=”https://sp.example.com/SAML”/>

     </saml:SubjectConfirmation>

   </saml:Subject>

   <saml:Conditions NotBefore=”2014-12-16T19:41:23Z” NotOnOrAfter=”2014-12-16T19:43:23Z”>

     <saml:AudienceRestriction>

       <saml:Audience>https://sp.example.com/SAML</saml:Audience>

     </saml:AudienceRestriction>

   </saml:Conditions>

   <saml:AuthnStatement AuthnInstant=”2014-12-16T19:42:23Z” SessionIndex=”uuid549ad19a-014a-1451-8e4d-998e0731058a” SessionNotOnOrAfter=”2014-12-16T20:42:21Z”>

     <saml:AuthnContext>

       <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>

     </saml:AuthnContext>

   </saml:AuthnStatement>

    <saml:AttributeStatement>

     <saml:Attribute Name=”emailAddress” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:basic”>

       <saml:AttributeValue xsi:type=”xs:string”>testuser@idp.example.com</saml:AttributeValue>

     </saml:Attribute>

     <saml:Attribute Name=”mobileNumber” NameFormat=”urn:oasis:names:tc:SAML:2.0:attrname-format:basic”>

       <saml:AttributeValue xsi:type=”xs:string”>01234556789</saml:AttributeValue>

     </saml:Attribute>

   </saml:AttributeStatement>

</saml:Assertion>

</samlp:Response>