Incoming SAML 2.0 Single Sign-On

Follow

 

Contents:

Introduction

The main purpose of establishing a Single Sign-On (SSO) process with Absorb is to allow your users a single point of entry into your system while providing them access to multiple other independent systems. With this process, a user logs in with a single ID to gain access to a multitude of other systems without being prompted for different usernames and passwords.

This article discusses Incoming SAML 2.0 SSO, meaning your users will login to some external application or site and then access Absorb without entering the second set of credentials. For the purposes of this article, the Absorb system will act as the Service provider (SP). Your system will act as the Identity Provider (IdP). The Absorb LMS currently supports Security Assertions Markup Language (SAML) 2.0 with Identity Provider Initiated (IdP) and Service Provider Initiated (SP) SSO. 

SAML is an industry-standard for achieving SSO; our SSO integration is provider agnostic, so long as the following information is being sent in the SAML Response:

  • Unencrypted x509 certificate key that matches what is entered in the Key field in the Absorb side configuration
  • NameId which is used to match the Id Property field used to match Users between the SSO and LMS
  • The ACS URL using your portal URL that has been Assigned to this SSO configuration on the Absorb settings
  • Attributes will only be used in the event that User Provisioning is enabled; please see Incoming SAML 2.0 SSO Account Provisioning for more information.

Please note that SSO is an additional feature that involves an additional fee and technical resources on the client side to develop and/or configure the solution.

SSO Disclaimer.png

Below are the different Identity Providers that our clients have used successfully in the past. Selecting the name will take you to the article that walks through that specific Identity Provider's setup. 

Setup

The following variables will need to be determined and configured as part of your SSO implementation.

Variables Description Requirement
Name Enter a value to identify this SSO configuration. This field is for your reference only. Mandatory
Method Select SAML. Mandatory
Key The key is the x509 public certificate of the IdP that is used for the SAML assertion signature. You must configure Absorb with your IdP’s public key so that Absorb can verify your signed SAML assertions. Mandatory
Mode Choose the request mode to be used, from either Service Provider Initiated or Identity Provider Initiated.
We recommend selecting Service Provider Initiated when possible. This has two key benefits:
- LMS deep links will function as expected
- SSO can be used to access the mobile app
Mandatory
ID Property (Unique Identifier) A unique identifier field is chosen in the Absorb LMS to be used as the identifying NameID through the SAML assertion. Absorb can be configured to use the following as the Id Property:
• Id (Randomly generated identifier in Absorb database)
• Username
• Email Address
• External Id
• Employee Number
Mandatory
Signature Type Select the correct option for your configuration. Mandatory
Login URL • Service Provider Initiated Mode: This is the endpoint where Absorb will send a SAML request.
• Identity Provider Initiated Mode: This is the URL where Absorb redirects users if they navigate directly to the selected Route(s) without an active session. This redirect is only triggered when the Automatically Redirect feature is turned on.

• Mandatory for SP-initiated

• Mandatory for IDP-initiated with Automatically Redirect ON

• Optional for IDP-initiated with Automatically Redirect OFF

Logout URL This is the URL where Absorb redirects users when they log out of the Absorb system. Optional
Single Logout Enables the single sign-out endpoint. This will attempt to sign the learner out of the identity provider when they log out of the LMS. If this is on, the Logout URL set above will be ignored. Optional
External Single Logout URL The external SLO endpoint to direct single log-out requests to. Optional
Wait for Idp Response Forces Absorb to wait for a response from the identity provider before logging out of Absorb. Optional
Enforce Admin Side SSO Enforces SSO Redirection on the Admin login page. Optional
Automatically Redirect This setting only displays when Identity Provider Initiated Mode is selected. When turned on, this will redirect all users who navigate directly to the selected Route(s) to the Login URL. If not turned on, users will land on the portal's landing page.
Note: When Service Provider Initiated Mode is selected, this setting is hidden. All unauthenticated users who navigate to the selected Route or Routes will be authenticated through SSO.
Optional
Assigned Routes Use this field to search for and select a Route or Routes to assign to this SSO configuration. A Route must be selected in order for SSO authentication to be successful. This Route will be referenced in the settings you configure in your Identity Provider. Mandatory
Allow User Provisioning This setting determines whether User Provisioning is enabled. To successfully create users via this method, the required values must be sent in the Attribute Statement. For further details, see our article on user provisioning: Incoming SAML 2.0 SSO Account Provisioning  Optional

 

 

All of the above variables can be configured by logging into the Absorb admin portal as a System Admin and navigating to Portal Settings. From Portal Settings, there is a button in the right-side context menu labelled Manage SSO Settings. If you can't see this button, please contact your Absorb Client Success Manager to discuss enabling the feature.

Capture2.PNG

Once you have clicked the button, you will be brought to the Manage Single Sign-On Settings page. Any existing configurations will appear here, as well as the option to Add a new one. 

Capture.PNG

 

Each route (Portal URL, e.g. company.myabsorb.com) can have its own set of SSO configurations. Please see this article for more information on route-based SSO. The remainder of this article assumes we're talking about a single SSO configuration.

Hybrid Setup

Your Absorb portal can be setup to use a hybrid setup where some users will login using SSO and others can login directly into your Absorb portal. There are two options for achieving this:

  • In the 'Manage Single Sign-On Settings' page (see above) you can set "Automatically Redirect" to OFF in order to allow both SSO and non-SSO users to login using the associated route(s). This only works in IdP Initiated mode, since SP initiated will always forcefully use SSO.
  • Since each route can have its own or no SSO configuration, you could have one route setup to use SSO and another one with no SSO settings. Your users would then be given different URL's depending on whether they are an SSO or non-SSO user.


How it Works

IdP Initiated

The below process assumes the Automatically Redirect option has been turned on.

Figure 1.1

  1. User attempts to navigate their browser to the Portal URL.
  2. Absorb checks to see if the Automatically Redirect option is turned on. If it is, Absorb checks what the IdP Login URL is. 
  3. Absorb redirects the user to the Login URL
  4. The IdP identifies the user (User usually types in their credentials here if they haven’t already).
  5. The IdP does a POST of a signed SAML Response with a SAML Assertion. 

    The SAML Assertion needs to have the “NameID” in the “Subject” to be mapped accordingly to the configured Id Property in Absorb. POST the SAML Response to https://Portal URL/api/rest/v2/authentication/saml

    If the IdP wishes to deep-link the user to a specific resource in the Absorbs user interface the IdP can also pass a RelayState parameter along with the SAML Response. Please see the Deep Link Support article for more information.

  6. Absorb uses the IdP metadata (mainly the x509 public certificate/Key in the Absorb configuration) to verify the signed message from the IdP. Use your private x509 certificate to sign either (or both): 
              • The entire SAML Response

              • The SAML Assertion
  7. If authentication is Successful the user is logged into the Absorb system.
  8. Absorb checks to see if a RelayState parameter is passed along with the SAML Response. If one has been provided, Absorb will parse the RelayState value and redirect the user to the corresponding resource.


SP Initiated

Refer to Figure 1.1
 
  1. User attempts to navigate their browser to the Portal URL, which may include a valid Absorb deep link. E.g., https%3A%2F%2Fyourdomain.myabsorb.com%2F%23%2Fonline-courses%2F8a70a2d4-21ab-4eda-9d36-50aada8ff7ae (which is the encoded version of:  https://yourdomain.myabsorb.com/#/online-courses/8a70a2d4-21ab-4eda-9d36-50aada8ff7ae)
  2. Absorb checks to see if the SP Initiated Mode is selected. If it is, Absorb checks what the IdP Login URL is.
  3. Absorb redirects the user to the Login URL with a SAML authentication request, which includes these parameters:
              • SAMLRequest – A URL-encoded, Base64-encoded, compressed (gzip) SAML message
              • SigAlg – The algorithm used to sign the SAML message
              • Signature – The digital signature used to sign the SAML message
              • RelayState – The Absorb resource requested by the client

  4. The IdP identifies the user (User usually types in their credentials here if they haven’t already).
  5. The IdP does a POST of a signed SAML Response with a SAML Assertion. 

    The SAML Assertion needs to have the “NameID” in the “Subject” to be mapped accordingly to the configured Id Property in Absorb.

    POST the SAML Response to https://Portal URL/api/rest/v2/authentication/saml

    If a deep link has been specified (refer to step #1) then a RelayState parameter will need to be returned to Absorb in the post request, which Absorb will use to redirect the user to the corresponding resource.  Please see the Deep Link Support article for more information.

  6. Absorb uses the IdP metadata (mainly the x509 public certificate/Key in the Absorb configuration) to verify the signed message from the IdP. Use your public x509 certificate to sign either (or both):
              • The entire SAML Response
              • The SAML Assertion

  7. If authentication is Successful the user is logged into the Absorb system.

  8. Absorb checks to see if a RelayState parameter is passed along with the SAML Response. If one has been provided, Absorb will parse the RelayState value and redirect the user to the corresponding resource.  Please see the Deep Link Support article for more information.
 

Metadata

Metadata is used to ensure a secure transaction between an identity provider and a service provider. You can find Absorb's metadata below, or it can be downloaded as an xml file at the bottom of this page.

Absorb’s SP Metadata (New - Valid as of June 2020 #2 Release)

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="https://company.myabsorb.com" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
	<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
		<md:KeyDescriptor use="signing">
			<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
				<ds:X509Data>
					<ds:X509Certificate>
MIID7jCCAtagAwIBAgIJAJYOwUdjFGKyMA0GCSqGSIb3DQEBCwUAMIGLMQswCQYDVQQGEwJDQTEQMA4GA1UECAwHQWxiZXJ0YTEQMA4GA1UEBwwHQ2FsZ2FyeTEdMBsGA1UECgwUQWJzb3JiIFNvZnR3YXJlIEluYy4xEzARBgNVBAsMCkFic29yYiBMTVMxJDAiBgNVBAMMG0Fic29yYiBMTVMgU0FNTCBDZXJ0aWZpY2F0ZTAeFw0yMDA2MjUxOTQwMzNaFw0yMzA2MjUxOTQwMzNaMIGLMQswCQYDVQQGEwJDQTEQMA4GA1UECAwHQWxiZXJ0YTEQMA4GA1UEBwwHQ2FsZ2FyeTEdMBsGA1UECgwUQWJzb3JiIFNvZnR3YXJlIEluYy4xEzARBgNVBAsMCkFic29yYiBMTVMxJDAiBgNVBAMMG0Fic29yYiBMTVMgU0FNTCBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALlRlsHwExZq6wTL/ZnDSklJrLIROBq/AuroWOgB795753GOReeDgjAYmfFTuDQFqnh2nqW2MsR4iKjDCNKyL9adSf0Tarvl26iHrMstV23eamtx51rH+rghRFWRMhfPblqyc3l6/sP72QFTMZqR+lCq+wiSaHJl8c5KJ4zs/DDuURMvePvFWY0SCVse+TdWSjtHMvC9Aaaull2ENjYdeqgCdFlVEgFl77Whq2ny5JKmbTxDtzD34+XrnDahQ2KGRQq+oVBIuUttGqL2QkNJXw68ba8De2oqu/8cNzMsmPi0PUiQIcoxx1DcGywWmIescC8jSB+F1sAV9RShJw9EsQUCAwEAAaNTMFEwHQYDVR0OBBYEFIARyfxr16BLliiJnXROi/OS976wMB8GA1UdIwQYMBaAFIARyfxr16BLliiJnXROi/OS976wMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAHc9GplQv2jwbYvplp2OoHefstl6MY8S3AVGcDOZNulOD84MrRsQjHsESyxsRYZZHj7jmUGAd/eFstONNLWLZ7ymQzjeoPSP1Gd3+1oPRXlpJHQZ/4GHx076IHtptSNZ3YxPACSfD9++CrI8LcIzMQ5JRLKDJkM4hrlP1cupEpM9XxvF4SwH3XG4MBXe7Ic1t/Up7hXVkaaZhVOGhRe5JOcOz/furKQBG56DFh2Dkp7ukW5LHnzzazwpsYf+Auu386YKCoci26XNumq0NZREskDyeEp9ybSADjCd7k79RLCWt9/CAKOX0DrL+5nKDzRKjBxnTBmWNE/APu//ynfVyPk=
				</ds:X509Certificate>
				</ds:X509Data>
			</ds:KeyInfo>
		</md:KeyDescriptor>
		<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="ACS URL" index="0" isDefault="true"/>
	</md:SPSSODescriptor>
</md:EntityDescriptor>

Important: Ensure you are using the new metadata and embedded certificate above, and enabling 'Use Newer SAML' when configuring SSO settings in Absorb. The old metadata and certificates will no longer be valid as of July 17th 2020 and the 'Use Newer SAML' (which allows switching between old and new certificates) will be removed in the following system release. See this article for more details on the certificate expiry.

Important: You will need to replace the "ACS URL" with your portal URL using the following format (Please ensure you replace "company.myabsorb.com" with your Portal URL.):

  • Absorb  - Learner Experience: https://company.myabsorb.com/api/rest/v2/authentication/saml

Example with the ACS URL replaced:

	...
		<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://company.myabsorb.com/api/rest/v2/authentication/saml" index="0" isDefault="true"/>
	...

You can also add the Absorb metadata to your list of trusted Service providers if required.

Absorb’s SP Metadata (Sandbox)

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="https://company.sandbox.myabsorb.com" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
	<md:SPSSODescriptor AuthnRequestsSigned="true" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
		<md:KeyDescriptor use="signing">
			<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
				<ds:X509Data>
					<ds:X509Certificate>
MIID7jCCAtagAwIBAgIJAMKBX1aYfB7yMA0GCSqGSIb3DQEBCwUAMIGLMQswCQYDVQQGEwJDQTEQMA4GA1UECAwHQWxiZXJ0YTEQMA4GA1UEBwwHQ2FsZ2FyeTEdMBsGA1UECgwUQWJzb3JiIFNvZnR3YXJlIEluYy4xEzARBgNVBAsMCkFic29yYiBMTVMxJDAiBgNVBAMMG0Fic29yYiBMTVMgU0FNTCBDZXJ0aWZpY2F0ZTAeFw0yMDA2MjUxOTQ5MjFaFw0zMDA2MjMxOTQ5MjFaMIGLMQswCQYDVQQGEwJDQTEQMA4GA1UECAwHQWxiZXJ0YTEQMA4GA1UEBwwHQ2FsZ2FyeTEdMBsGA1UECgwUQWJzb3JiIFNvZnR3YXJlIEluYy4xEzARBgNVBAsMCkFic29yYiBMTVMxJDAiBgNVBAMMG0Fic29yYiBMTVMgU0FNTCBDZXJ0aWZpY2F0ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALu93AM4VaxAW+1yUqNAOI6MDr2evvS4nY3D+N4nJ/qL0Y3bwBypk7gESqHxYW/dBUE3sO5GGnsgM2hAZNu1iAOM4dkWfFxI3PXMHnSAwiNDivX/oQp6lMyf794d7jbZwWVSJqZ1pBClfs0cDkMKz8UvFr4qm4y3+q7edGsSUySbCjByQQ7Mq9K4jrQF0M8FjxfQ6Ib0qP/BWesSrcXJ4lsCpKGHh3SbCMEVV6PsUusDMH7uuKpNJ0tLy6xoezGFsIX7e74n0fDypAjnn+EEt6Y05ZuL1Cn6G8QAECbNK4ezCG1Dpbd7P9W80Uu0vKlj0/VUxAjekqO0efLyw/v5x3sCAwEAAaNTMFEwHQYDVR0OBBYEFNtCRS1L4ja141BnUdXR2X9oQvUdMB8GA1UdIwQYMBaAFNtCRS1L4ja141BnUdXR2X9oQvUdMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAEYBLTDVUgjZ1qe3KqzVzi1R8hVysGy7EQH2zKbiF4JNibx60FsBoCiVoTn1g3o6Tp7W6rTMz6qO+2x3AhtsAhq0bjFQablqoMJfK9/WFK0yPKzKV1ET0IDCKQhX3GJsBuLh/amCRGU+45Dz190BBFry7EIPcxCPCyTiKqSnJ0UkaOctHgCAcXRtpUMnP7xP8QpgsqJhMlL2tc70lWyFsS3YbrUEHeM4C+6TT2hWA7tV4/8edPzXOKZCG7Dj/dhT7kpttwSpADoxSCdcQFD4IOAZrdpO8pg3kPuZS+6Lo2IXfv9NYxwxul3b84AXfCLrGWvAutUM7scqPIAH/kuQu10=
					</ds:X509Certificate>
				</ds:X509Data>
			</ds:KeyInfo>
		</md:KeyDescriptor>
		<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="ACS URL" index="0" isDefault="true"/>
	</md:SPSSODescriptor>
</md:EntityDescriptor>

IdP Metadata

Your IdP Metadata can be used to obtain your public X509 certificate. The X509 certificate should be added to the Key field under Portal Settings - see the Setup section for more details.

 

Examples

SAML Response:

The following HTML code can be used to POST a form to Absorb's SAML SP endpoint. The below example includes the SamlResponse and RelayState parameters for Absorb deep linking:

<html>
<body>
	<form action="https://company.myabsorb.com/api/rest/v2/authentication/saml" method="POST" id="samlform">
	  SamlResponse <br><textarea name="samlresponse" id="samlresponse" rows="25" cols="50">...Base64 Encoded SAMLResponse and Assertion...</textarea><br><br>
	  RelayState <br><input type="text" name="relaystate" id="relaystate" value="...DeepLink URL..." size="100"><br>
	  <br>
	  <input type="submit" value="Submit">
	</form>
</body>
</html>

Where SamlResponse = base64 encoded SAML Response + SAML Assertion as shown here: 

Before base64 encoding: 

Please note the x509 certificate used in the example below would be replaced with one from the IdP.

<samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_2"
    InResponseTo="identifier_1"
    Version="2.0"
    IssueInstant="2004-12-05T09:22:05"
    Destination="https://company.myabsorb.com/api/rest/v2/authentication/saml">
    <saml:Issuer>https://IdP.example.org/SAML2</saml:Issuer>
    <samlp:Status>
      <samlp:StatusCode
        Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion Version="2.0" ID="_aca78291-11a2-40f2-ba16-4cfbd93865db" IssueInstant="2015-08-11T21:14:33.053Z"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:Issuer>https://IdP.example.org/SAML2</saml:Issuer>
    <Signature
        xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
            <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
            <Reference URI="#_aca78291-11a2-40f2-ba16-4cfbd93865db">
                <Transforms>
                    <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                        <InclusiveNamespaces PrefixList="#default saml ds xs xsi"
                            xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
                        </Transform>
                    </Transforms>
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                    <DigestValue>T+64Rwm7xlNr2mTli9rU/Jmyd5o=</DigestValue>
                </Reference>
            </SignedInfo>
            <SignatureValue>WDjZhBehjVKAGLwe1nYMiQtCMspwZaDxnknn+eMk62kD08R8S4bt2nm4kTCaJ6hKxaQ/P7S5W8Kq0JIQV0pRqR+Y9m98CHtT97No6LQFbgBjlMXpEWyZbJ8zBpy5dJbUHOC3ZaFlnBrfLBxW0DR8l0mb6+uLs0VuqQm+5T606Dw=</SignatureValue>
            <KeyInfo>
                <X509Data>
                    <X509Certificate>MIIBnjCCAQcCBEbTmdAwDQYJKoZIhvcNAQEEBQAwFjEUMBIGA1UEAxMLd3d3LmlkcC5jb20wHhcNMDcwODI4MDM0MzEyWhcNMTcwODI1MDM0MzEyWjAWMRQwEgYDVQQDEwt3d3cuaWRwLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAo31q3mJZayXfZkLDuLcnanc/KG+RDFW+OlYDP+RubvWnt8X5jtiUTcp8IQ46TNEUFskmsonUb5AnG+zOCcawb2dJr8kBtCNhfi/TufZGBQNjuAxNMi34yIgRdGinaznHgclrAIIZTyKerQqYjPL1xRDsFGpzqGGi/2opzN8nV5kCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBmNwFN+98aybuQKFJFr69s9BvBVYtk+Hsx3gx0g4e5sLTlkcSU03XZ8AOet0my4RvUspaDRzDrv+gEgg7gDP/rsVCSs3dkuYuUvuWbiiTq/Hj4EKuKZa8nIerZ3Oz4Xa1/bK88eT7RVsv5bMOxgJbSEvTidTvOpV0G13duIqyrCw==</X509Certificate>
                </X509Data>
            </KeyInfo>
        </Signature>
        <saml:Subject>
            <saml:NameID>absorb.test</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData Recipient="https://company.myabsorb.com/api/rest/v2/authentication/saml" />
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions NotBefore="2015-08-11T15:14:33.053Z" NotOnOrAfter="2015-08-11T15:19:33.053Z">
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2015-08-11T21:14:33.053Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>

 

After base64 encoding:
PHNhbWxwOlJlc3BvbnNlCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiIKICAgIElEPSJpZGVudGlmaWVyXzIiCiAgICBJblJlc3BvbnNlVG89ImlkZW50aWZpZXJfMSIKICAgIFZlcnNpb249IjIuMCIKICAgIElzc3VlSW5zdGFudD0iMjAwNC0xMi0wNVQwOToyMjowNSIKICAgIERlc3RpbmF0aW9uPSJodHRwczovL2NvbXBhbnkubXlhYnNvcmIuY29tL2FwaS9yZXN0L3YyL2F1dGhlbnRpY2F0aW9uL3NhbWwiPgogICAgPHNhbWw6SXNzdWVyPmh0dHBzOi8vaWRwLmV4YW1wbGUub3JnL1NBTUwyPC9zYW1sOklzc3Vlcj4KICAgIDxzYW1scDpTdGF0dXM+CiAgICAgIDxzYW1scDpTdGF0dXNDb2RlCiAgICAgICAgVmFsdWU9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpzdGF0dXM6U3VjY2VzcyIvPgogICAgPC9zYW1scDpTdGF0dXM+CiAgICA8c2FtbDpBc3NlcnRpb24gVmVyc2lvbj0iMi4wIiBJRD0iX2FjYTc4MjkxLTExYTItNDBmMi1iYTE2LTRjZmJkOTM4NjVkYiIgSXNzdWVJbnN0YW50PSIyMDE1LTA4LTExVDIxOjE0OjMzLjA1M1oiCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj4KICAgIDxzYW1sOklzc3Vlcj5odHRwczovL2lkcC5leGFtcGxlLm9yZy9TQU1MMjwvc2FtbDpJc3N1ZXI+CiAgICA8U2lnbmF0dXJlCiAgICAgICAgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPgogICAgICAgIDxTaWduZWRJbmZvPgogICAgICAgICAgICA8Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMTAveG1sLWV4Yy1jMTRuIyIgLz4KICAgICAgICAgICAgPFNpZ25hdHVyZU1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNyc2Etc2hhMSIgLz4KICAgICAgICAgICAgPFJlZmVyZW5jZSBVUkk9IiNfYWNhNzgyOTEtMTFhMi00MGYyLWJhMTYtNGNmYmQ5Mzg2NWRiIj4KICAgICAgICAgICAgICAgIDxUcmFuc2Zvcm1zPgogICAgICAgICAgICAgICAgICAgIDxUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZW52ZWxvcGVkLXNpZ25hdHVyZSIgLz4KICAgICAgICAgICAgICAgICAgICA8VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIj4KICAgICAgICAgICAgICAgICAgICAgICAgPEluY2x1c2l2ZU5hbWVzcGFjZXMgUHJlZml4TGlzdD0iI2RlZmF1bHQgc2FtbCBkcyB4cyB4c2kiCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIiAvPgogICAgICAgICAgICAgICAgICAgICAgICA8L1RyYW5zZm9ybT4KICAgICAgICAgICAgICAgICAgICA8L1RyYW5zZm9ybXM+CiAgICAgICAgICAgICAgICAgICAgPERpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNzaGExIiAvPgogICAgICAgICAgICAgICAgICAgIDxEaWdlc3RWYWx1ZT5UKzY0UndtN3hsTnIybVRsaTlyVS9KbXlkNW89PC9EaWdlc3RWYWx1ZT4KICAgICAgICAgICAgICAgIDwvUmVmZXJlbmNlPgogICAgICAgICAgICA8L1NpZ25lZEluZm8+CiAgICAgICAgICAgIDxTaWduYXR1cmVWYWx1ZT5XRGpaaEJlaGpWS0FHTHdlMW5ZTWlRdENNc3B3WmFEeG5rbm4rZU1rNjJrRDA4UjhTNGJ0Mm5tNGtUQ2FKNmhLeGFRL1A3UzVXOEtxMEpJUVYwcFJxUitZOW05OENIdFQ5N05vNkxRRmJnQmpsTVhwRVd5WmJKOHpCcHk1ZEpiVUhPQzNaYUZsbkJyZkxCeFcwRFI4bDBtYjYrdUxzMFZ1cVFtKzVUNjA2RHc9PC9TaWduYXR1cmVWYWx1ZT4KICAgICAgICAgICAgPEtleUluZm8+CiAgICAgICAgICAgICAgICA8WDUwOURhdGE+CiAgICAgICAgICAgICAgICAgICAgPFg1MDlDZXJ0aWZpY2F0ZT5NSUlCbmpDQ0FRY0NCRWJUbWRBd0RRWUpLb1pJaHZjTkFRRUVCUUF3RmpFVU1CSUdBMVVFQXhNTGQzZDNMbWxrY0M1amIyMHdIaGNOTURjd09ESTRNRE0wTXpFeVdoY05NVGN3T0RJMU1ETTBNekV5V2pBV01SUXdFZ1lEVlFRREV3dDNkM2N1YVdSd0xtTnZiVENCbnpBTkJna3Foa2lHOXcwQkFRRUZBQU9CalFBd2dZa0NnWUVBbzMxcTNtSlpheVhmWmtMRHVMY25hbmMvS0crUkRGVytPbFlEUCtSdWJ2V250OFg1anRpVVRjcDhJUTQ2VE5FVUZza21zb25VYjVBbkcrek9DY2F3YjJkSnI4a0J0Q05oZmkvVHVmWkdCUU5qdUF4Tk1pMzR5SWdSZEdpbmF6bkhnY2xyQUlJWlR5S2VyUXFZalBMMXhSRHNGR3B6cUdHaS8yb3B6TjhuVjVrQ0F3RUFBVEFOQmdrcWhraUc5dzBCQVFRRkFBT0JnUUJtTndGTis5OGF5YnVRS0ZKRnI2OXM5QnZCVll0aytIc3gzZ3gwZzRlNXNMVGxrY1NVMDNYWjhBT2V0MG15NFJ2VXNwYURSekRyditnRWdnN2dEUC9yc1ZDU3MzZGt1WXVVdnVXYmlpVHEvSGo0RUt1S1phOG5JZXJaM096NFhhMS9iSzg4ZVQ3UlZzdjViTU94Z0piU0V2VGlkVHZPcFYwRzEzZHVJcXlyQ3c9PTwvWDUwOUNlcnRpZmljYXRlPgogICAgICAgICAgICAgICAgPC9YNTA5RGF0YT4KICAgICAgICAgICAgPC9LZXlJbmZvPgogICAgICAgIDwvU2lnbmF0dXJlPgogICAgICAgIDxzYW1sOlN1YmplY3Q+CiAgICAgICAgICAgIDxzYW1sOk5hbWVJRD5hYnNvcmIudGVzdDwvc2FtbDpOYW1lSUQ+CiAgICAgICAgICAgIDxzYW1sOlN1YmplY3RDb25maXJtYXRpb24gTWV0aG9kPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6Y206YmVhcmVyIj4KICAgICAgICAgICAgICAgIDxzYW1sOlN1YmplY3RDb25maXJtYXRpb25EYXRhIFJlY2lwaWVudD0iaHR0cHM6Ly9jb21wYW55Lm15YWJzb3JiLmNvbS9hcGkvcmVzdC92Mi9hdXRoZW50aWNhdGlvbi9zYW1sIiAvPgogICAgICAgICAgICA8L3NhbWw6U3ViamVjdENvbmZpcm1hdGlvbj4KICAgICAgICA8L3NhbWw6U3ViamVjdD4KICAgICAgICA8c2FtbDpDb25kaXRpb25zIE5vdEJlZm9yZT0iMjAxNS0wOC0xMVQxNToxNDozMy4wNTNaIiBOb3RPbk9yQWZ0ZXI9IjIwMTUtMDgtMTFUMTU6MTk6MzMuMDUzWiI+CiAgICAgICAgICAgIDxzYW1sOkF1ZGllbmNlUmVzdHJpY3Rpb24+CiAgICAgICAgICAgICAgICA8c2FtbDpBdWRpZW5jZT5FbmhhbmNlVTpfY2lkPTEyMjA1MDwvc2FtbDpBdWRpZW5jZT4KICAgICAgICAgICAgPC9zYW1sOkF1ZGllbmNlUmVzdHJpY3Rpb24+CiAgICAgICAgPC9zYW1sOkNvbmRpdGlvbnM+CiAgICAgICAgPHNhbWw6QXV0aG5TdGF0ZW1lbnQgQXV0aG5JbnN0YW50PSIyMDE1LTA4LTExVDIxOjE0OjMzLjA1M1oiPgogICAgICAgICAgICA8c2FtbDpBdXRobkNvbnRleHQ+CiAgICAgICAgICAgICAgICA8c2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj51cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZDwvc2FtbDpBdXRobkNvbnRleHRDbGFzc1JlZj4KICAgICAgICAgICAgPC9zYW1sOkF1dGhuQ29udGV4dD4KICAgICAgICA8L3NhbWw6QXV0aG5TdGF0ZW1lbnQ+CiAgICA8L3NhbWw6QXNzZXJ0aW9uPgogIDwvc2FtbHA6UmVzcG9uc2U+

And the RelayState = URL deep link as shown here: 

https%3A%2F%2Fyourdomain.myabsorb.com%2F%23%2Fonline-courses%2F91db68a0-581f-467c-84fa-e67430d1c661

In this example we are deep linking into a particular course. Please refer to the Deep Link Support article for more details.

Please also keep in mind the HTML form shown in the example above implicitly URL encodes all data sent in the POST. So you may need to URL encode your messages if the framework you are using doesn’t already do this implicitly.

SAML AuthnRequest:

Here is an example SAML Request that would be sent as part of SP initiated mode:

Before base64 encoding:

<samlp:AuthnRequest ID="identifier_1"
                    Version="2.0"
                    IssueInstant="2017-08-16T15:32:26.225Z"
                    Destination="https://company.myabsorb.com/"
                    ForceAuthn="false"
                    IsPassive="false"
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                    AssertionConsumerServiceURL="https://company.myabsorb.com/api/rest/v2/authentication/saml"
                    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    >
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://company.myabsorb.com</saml:Issuer>
</samlp:AuthnRequest>

After base64 encoding:

PHNhbWxwOkF1dGhuUmVxdWVzdCBJRD0iaWRlbnRpZmllcl8xIgogICAgICAgICAgICAgICAgICAgIFZlcnNpb249IjIuMCIKICAgICAgICAgICAgICAgICAgICBJc3N1ZUluc3RhbnQ9IjIwMTctMDgtMTZUMTU6MzI6MjYuMjI1WiIKICAgICAgICAgICAgICAgICAgICBEZXN0aW5hdGlvbj0iaHR0cHM6Ly9jb21wYW55Lm15YWJzb3JiLmNvbS8iCiAgICAgICAgICAgICAgICAgICAgRm9yY2VBdXRobj0iZmFsc2UiCiAgICAgICAgICAgICAgICAgICAgSXNQYXNzaXZlPSJmYWxzZSIKICAgICAgICAgICAgICAgICAgICBQcm90b2NvbEJpbmRpbmc9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpiaW5kaW5nczpIVFRQLVBPU1QiCiAgICAgICAgICAgICAgICAgICAgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPSJodHRwczovL2NvbXBhbnkubXlhYnNvcmIuY29tL2FwaS9yZXN0L3YyL2F1dGhlbnRpY2F0aW9uL3NhbWwiCiAgICAgICAgICAgICAgICAgICAgeG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCIKICAgICAgICAgICAgICAgICAgICA+CiAgICA8c2FtbDpJc3N1ZXIgeG1sbnM6c2FtbD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFzc2VydGlvbiI+aHR0cHM6Ly9jb21wYW55Lm15YWJzb3JiLmNvbTwvc2FtbDpJc3N1ZXI+CiAgICA8c2FtbHA6TmFtZUlEUG9saWN5IFNQTmFtZVF1YWxpZmllcj0iVXNlcm5hbWUiCiAgICAgICAgICAgICAgICAgICAgICAgIEFsbG93Q3JlYXRlPSJ0cnVlIgogICAgICAgICAgICAgICAgICAgICAgICAvPgo8L3NhbWxwOkF1dGhuUmVxdWVzdD4=

Troubleshooting:

Please see our article on Troubleshooting Incoming SAML 2.0 SSO.

 

Example code (with C#):

http://www.codeproject.com/Articles/56640/Performing-a-SAML-Post-with-C

Jump back to top.

Published on
Have more questions? Submit a request

0 Comments

Article is closed for comments.