Configuring Single Sign On (SSO) - Leadership Academy

This article outlines the platform’s single sign on (SSO) capabilities and how your organization can enable SSO. If you're interested in configuring SSO for your organization, please contact your Customer Success representative.

Overview

We support SAML 2.0 for single sign-on (SSO). Security Assertion Markup Language (SAML) creates end points that give an organization's users a single URL to sign in and select the applications they are authorized to use. This provides an additional level of security and simplifies user authentication by eliminating further login prompts when switching applications during a particular session.

Advantages of utilizing SSO include:

  • Improved user experience
  • Reduced internal operational cost
  • Centralized management of users
  • Enhanced security to enterprise systems
  • Adhere to Compliance Regulations (SOX, HIPPA)

Standards support

  • We support the OASIS Security Assertion Markup Language (SAML) v2.0 standard for single sign-on
  • SAML v2.0 supports allows integration with many common identity providers including Microsoft Active Directory (via ADFS), Tivoli Federated Identity Manager, Okta and other federated authentication platforms

General assumptions

  • We will perform the SP (service provider) role in the SAML v2.0 trust relationship
  • We require SAML v2.0 compliant IDP (identity provider) metadata files from the IDP. The IDP metadata file will contain:
    • The SingleSignOnService endpoint location
    • X.509 public certificate used for assertion signing (if applicable)
  • We will provide a SP metadata file that contains the following:
    • The SP endpoint

Development process

A typical integration workflow is as follows:

  • Consult with your assigned account representative for which configuration options will be used
  • We provide a SP metadata file URL
  • You provide the IDP metadata file
  • Integration testing and remediation occurs until the appointed stakeholders sign off that the integration is successful. Both IDP-initiated and SP-initiated types of access should be tested. At this point, a production window is agreed upon.

Supported configurations

We currently support the following SAML configurations:

  • Single logout (SLO)
    • Disabled – we do not currently support SLO
  • NameID format
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress (DEFAULT)
    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    • urn:oasis:names:tc:SAML:2.0:nameid-format:encrypted
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent
    • urn:oasis:names:tc:SAML:2.0:nameid-format:transient
    • urn:oasis:names:tc:SAML:2.0:nameid-format:entity
  • Assertions are signed
    • No / Yes (DEFAULT)
  • Authn requests are signed
    • No
  • Provision new users
    • Disabled (DEFAULT) / Enabled
  • Updated existing user attributes
    • Disabled (DEFAULT) / Enabled
  • Preferred Authn request binding:
    • Post (DEFAULT) / Redirect

Setup questions

The first step in getting started with SSO is to first coordinate a meeting with your Customer Success representative to answer the following setup and SSO configuration questions:

  1. What will you be using as the unique identifier for users in your system?
    • Our platform supports the use of an email address or an external globally unique identifier (GUID).
    • The most common setup is to use an external GUID rather than an email address in order to reduce any issues if or when someone’s email address was to change in the future. Additionally, the employee’s employee ID is most commonly used as the external GUID.
  2. Do you want to update user information at the time of authentication?
    • If yes, what fields do you plan to include, and are all fields available within their SSO system? Also, what will you be calling these fields in the SAML assertion and how will those fields map to fields in the platform?
  3. Do you want to create new users in the platform at the time of authentication if the user does not already have an account in the platform?
    • If yes, what fields do you plan to include, and are all fields available within their SSO system? Also, what will you be calling these fields in the SAML assertion and how will those fields map to fields in the platform?
  4. Will every user that needs access to the platform be able to access your SSO solution?
    • If not, will you require a dual login experience that supports the username/password form as well as the SSO login options?

Configuring SSO

Once we have an understanding of your SSO requirements, we can move forward and begin setup. The next steps include:

  1. We will provide the SP Metadata XML.
  2. You will configure SSO on your end and provide our team with the IDP Metadata XML.
  3. We will apply your IDP Metadata XML to complete the setup.
  4. You will user test and validate the environment.
  5. Once validated, we and your team will agree on the timing of the production rollout.

Related articles

Contact Us