Incoming SAML 2.0 Single Sign-On (Single Sign-On) refers to the process where a User logs in through a single authentication source and gains access to multiple systems and applications without needing to log in again for each one.
The term “incoming” typically refers to the direction of the authentication request coming into the system. In the context of SSO, it means that the authentication request is initiated by the User attempting to access a service or application, and upon successful authentication, the User is granted access to other associated services without the need to perform additional logins.
SSO simplifies the User experience by reducing the number of login prompts and managing only one set of credentials. It also enhances security by centralizing the authentication process and reducing the likelihood of password fatigue, where Users might reuse passwords across multiple sites.
For organizations, SSO can streamline User management and reduce the overhead associated with password resets and account maintenance. It’s commonly used in enterprise environments where Users need to access a suite of applications and services as part of their daily workflow.
- SAML uses XML to represent the User’s identity data and simple HTTP for data transport mechanisms.
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 a second set of credentials.
For the purposes of this article, the Absorb system will act as the Service Provider. Your system will act as the Identity Provider (IdP). The Absorb LMS currently supports SAML 2.0 alongside the Identity Provider Initiated (IdP) and Service Provider Initiated (SP) methods of 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 on the Absorb side of the configuration.
-
NameId which is used to match the Id Property field to unique Users.
- This means a User must have the same Id Property in Absorb, as they do in the SSO provider.
- The ACS URL using your portal URL that has been assigned to this SSO configuration in 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.
Absorb LMS supports Incoming SAML 2.0 Single Sign-On as a feature, however we do not officially support any specific client-side (IdP) solution. Although the below IdPs are known to generally work with our implementation of SAML SSO, it is the client's responsibility to configure/develop and maintain their side of the integration. This will require a client resource who is knowledgeable and familiar with your IdP environment. These guides are provided to our clients as a convenience only, based on our experience working with clients who employ these IdPs.
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.
|
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:
|
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. | 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. 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 Experience 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 System Admin or an Absorb representative to discuss enabling the feature.
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.
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:
- From 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.
IdP Initiated
The below process assumes the Automatically Redirect option has been turned on.
-
User attempts to navigate their browser to the Portal URL.
- Absorb checks to see if the Automatically Redirect option is turned on. If it is, Absorb checks what the IdP Login URL is.
- Absorb redirects the user to the Login URL.
- The IdP identifies the User (User usually types in their credentials here if they haven’t already).
- 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 Absorb 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.
- 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.
- If authentication is successful the User is logged into the Absorb system.
- 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
- 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)
- Absorb checks to see if the SP Initiated Mode is selected. If it is, Absorb checks what the IdP Login URL is.
- 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
- The IdP identifies the User (User usually types in their credentials here if they haven’t already).
- 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.
- 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
- If authentication is successful the user is logged into the Absorb system.
- 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
Please advise the following Absorb metadata is not specific to any client Portal, which means there are generic URLs like Subdomain.myabsorb.com that must be edited before you will be able to use it.
<?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>
MIID+TCCAuGgAwIBAgIUdry9Q/umiu6nrtOu74wKvF6H3lwwDQYJKoZIhvcNAQELBQAwgYsxCzAJBgNVBAYTAkNBMRAwDgYDVQQIDAdBbGJlcnRhMRAwDgYDVQQHDAdDYWxnYXJ5MR0wGwYDVQQKDBRBYnNvcmIgU29mdHdhcmUgSW5jLjETMBEGA1UECwwKQWJzb3JiIExNUzEkMCIGA1UEAwwbQWJzb3JiIExNUyBTQU1MIENlcnRpZmljYXRlMB4XDTIzMDYwMTIyMzIzM1oXDTI2MDUzMTIyMzIzM1owgYsxCzAJBgNVBAYTAkNBMRAwDgYDVQQIDAdBbGJlcnRhMRAwDgYDVQQHDAdDYWxnYXJ5MR0wGwYDVQQKDBRBYnNvcmIgU29mdHdhcmUgSW5jLjETMBEGA1UECwwKQWJzb3JiIExNUzEkMCIGA1UEAwwbQWJzb3JiIExNUyBTQU1MIENlcnRpZmljYXRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2GltWTL5ScdVyJ9fUpQPJ294HyfR6JwKra75+pkbFGfWMeVQfNqpIGq3q28ldtaFCosPwh5h9tRaA9jTeUqSn8YtBxXQoRJ2dAxr4GYksSwvO0PrGoV00fullzwlh+dRwRzoUQPNWSJRx6socfs24S5ZutcQbe7o0+NOLvFFiomh/EC3D8NWC5MF234K2QvqnS/259a9yc2mZV/kyxIalHDn43LytQ2MIiEbg6sk84QokuzkOdf+xkyEI1XQSWX9iE+2Nde2KH3CIkoZS1w41YMC2qPlHi8OtqqF7eI0id+GemKMS3RiCqM44sGMhXaEtg4oN4w5ZBFc49xXi6GsJQIDAQABo1MwUTAdBgNVHQ4EFgQUx85ZJmP/+1qBcrEPEi2J1S3sOsYwHwYDVR0jBBgwFoAUx85ZJmP/+1qBcrEPEi2J1S3sOsYwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEAGzrZ6vPwkuOa7FeJrIhqMnxtMN43WyQZL7E7eVH1PfEbJ4TM1/T0o98nN7CuT9ofIc1iOahyI4m+EA4CGzzyKWUicRs65nxSXd123BpdmiUpapNBUYE4zYvg10mrriWKsjJ8TR2C8mQGt26HRIHrjP86klElnT4593uz7WlKLTZlgKAvVj+fG39/3r0Dnzx15pk29K5dgvYYQl3C0JsKOB0OsnhJj6rZAhcEtLajvrpZIP7xnTo/wRqdddYckcq+HTG7riinmtPcGmtCEDnelpF+/H3jXRMfS4Z1Bx+enQVXK39vAtb+z2yF+tKNGpx7ndtOC3ueUPfqcYN2eAaAiQ==
</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: 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)
The metadata presented here will only work with a sandbox Portal. Using this metadata in another environment will present the SSO connection from performing as intended.
<?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.
Examples
The following section includes examples that may be referenced when configuring your own SSO implementation:
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>
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 review our troubleshooting SSO section:
Comments
Article is closed for comments.