We reserve the right to update our (Service Provider) use of the relevant elements in accordance with the SAML 2.0 specifications as part of our release process and as such the client will assume the responsibility for ensuring their (Identity Provider) implementation follows the said standard.
The information provided in this article was provided prior to Absorb implementing Just-In-Time (JIT) User Provisioning for SAML 2.0. Today, we recommend using the SSO User Provisioning feature with SAML 2.0 if that is what you want to achieve. Learn more here.
Clients using a standard Identity Provider do not usually need to write any code in order to implement SAML 2.0. You can read more about SAML 2.0, including Identity Providers our clients have used here.
This article details Absorb specific elements that are required if you are building a custom SAML solution for SSO. For the purposes of this article, we'll assume a basic understanding of the SSO process along with some background in software development.
Once a User is authenticated in your system (the Identity Provider), the User will look to navigate to your Absorb Portal, the Service Provider. Most likely this will be done through a link that passes them to Absorb.
To do this, your system should first confirm the User exists in your Absorb portal. If the User does not exist, it should be created then logged in. It’s possible to automate this process using REST API.
The following documentation may be useful:
- Getting Started with the Absorb RESTful API
- Configuring Single Logout (SLO)
- Incoming SAML 2.0 Single Sign-On
- Outgoing SAML 2.0 Single Sign-On
- Troubleshooting SSO: Incoming SAML 2.0 Account Provisioning
Absorb does not provide support for writing, debugging, or troubleshooting client code.
Custom SAML Identity Provider
In the context of implementing your own Identity Provider, there are important SAML data elements that should be included in your SAML assertions for the SSO flow to work. It is expected for your IdP to follow the official SAML 2.0 specification, and the Web Browser SSO profile:
- https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
- http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
Below are the important elements that are required for the following scenarios supported by Absorb.
Important Fields for SAML Assertion
These fields are essential when interacting with a SAML assertion:
| Field | Description |
|---|---|
| Assertion | The package element of information with one or more statements. |
| ID | Identifier for this assertion. |
| IssueInstant | Time that the instant is issued in UTC.. |
| Version | The SAML version for this assertion, should be “2.0”. |
| Issuer | The authority making the claim in this assertion, should be the URI for your IdP. |
| <ds: Signature> | Contains the XML Signature that protects the integrity of this assertion. |
| Subject | The package element for the subject’s (User) identity. |
| NameId | The ID Property identifier as configured in Absorb SSO settings. |
| Conditions | Contains information that denotes the validity of the assertion. |
| NotBefore | A time instant in UTC. |
| NotOnOrAfter | A time instant in UTC. |
| AuthnStatement | Contains information of the assertion subject. |
| AuthnContext | The context of the authentication event. |
Important Fields for Incoming Single Sign-On (SSO)
These fields are essential when interacting observing Incoming Single Sign-On:
| Field | Description |
|---|---|
| SAML Assertion | All the elements as denoted above. |
Important Fields for Outgoing SSO
For a SAML Authentication Request (AuthNRequest) sent to the LMS, the following elements are required:
| Field | Description |
|---|---|
| ID | Identifier for this request. |
| IssueInstant | Time that the instant is issued in UTC. |
| Version | The SAML version for this assertion, should be “2.0”. |
| Issuer | The authority making the claim in this assertion, should be the URI for your IdP. |
| ProtocolBinding | The protocol for sending the authentication response, should be HTTP-POST. |
| <ds: Signature> | Contains the XML Signature that protects the integrity of this assertion. |
Important Fields for Single Logout (SLO)
For a SAML Authentication Response (SAML Response) sent to the LMS, the following elements are required:
| Field | Description |
|---|---|
| SAML Assertion | All the elements as denoted above. |
| SessionIndex | Part of the AuthStatement, contains a session identifier. |
For a SAML Logout Response (LogoutResponse) sent to the LMS, the following elements are required:
| Field | Description |
|---|---|
| Issuer | The authority making the claim in this assertion, should be the URI for your IdP. |
| <ds: Signature> | Contains the XML Signature that protects the integrity of this assertion. |
| Status | Contains the StatusCode. |
Important Fields for Account Provisioning
For a SAML Authentication Response sent to the LMS, the following elements are required:
| Field | Description |
|---|---|
| SAML Assertion | All the elements as denoted above. |
| AttributeStatement | All elements as denoted below. |
The SAML Authentication Response must contain the following attributes:
| Field | Description |
|---|---|
| Username | The Username. Must be unique, and between 1 and 255 characters |
| FirstName | The User's First Name. Must be between 1 and 255 characters |
| LastName | The User's Last Name. Must be between 1 and 255 characters |
| DepartmentId* | A GUID that matches a Department's GUID within Absorb. |
| ExternalDepartmentId* | Matches a Department's External ID within Absorb. |
User Account Provisioning only requires DepartmentId or ExternalDepartmentId; not both. Additional custom fields can be discovered in this article: here.
Comments
Article is closed for comments.