Does CorpU Support Single Sign-On?

Single Sign-On

Overview

CorpU supports SAML 2.0 for single sign-on (SSO). Security Assertion Markup Language (SAML) creates endpoints 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

  • CorpU supports 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

  • AWS CorpU will perform the SP (service provider) role in the SAML v2.0 trust relationship
  • CorpU requires 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)
  • CorpU will provide a SP metadata file that contains the following:
    • The SP endpoint
    • The X.509 public certificate used for Authn request signing (if applicable)

Development Process

CorpU currently has two environments for SSO integration: TEST and PRODUCTION. CorpU recommends that development and testing of SSO integrations happens on a TEST site provided for this purpose. A typical integration workflow is as follows:

  • Scoping call to connect your SSO team with CorpU’s SSO team. This call is to agree on process steps, use of TEST environment and which configuration options will be used
  • You provide the IDP metadata file for the TEST environment
  • CorpU builds the TEST environment and provides a SP metadata file. If Authn request signing is enabled, CorpU will provision a separate X.509 certificate for the TEST environment.
  • 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.
  • You provide the IDP metadata for the PRODUCTION environment.
  • CorpU pre-configures the production environment and provides the SP metadata file for the PRODUCTION environment.

Supported Configurations

CorpU currently supports the following SAML configurations:

  • Single logout (SLO)
    • o   Disabled – CorpU does 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) / Redirec

Getting Started

Setup Questions

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

  • What will you be using as the unique identifier for users in your system?
    • CorpU 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.
  • 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 CorpU?
  • Do you want to create new users in CorpU at the time of authentication if the user does not already have an account in CorpU?
    • 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 CorpU?
  • Will every user that needs access to CorpU be able to access your SSO solution?
    • If no, will you require a dual login experience that supports the username/password form as well as the SSO login options?

Configuring SSO

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

  1. CorpU will create an SSO test environment for you
  2. You will be asked to provide a limited number of users that you can use to test SSO while in the test environment
  3. CorpU will provide the SP Metadata XML
  4. You will configure SSO on your end and provide CorpU with the IDP Metadata XML
  5. CorpU will apply your IDP Metadata XML to complete the setup of the test environment
  6. You will user test and validate the test SSO environment
  7. Once the test environment has been validated, CorpU and your team will agree on the timing of the production implementation.
Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help or have feedback? Contact Us Contact Us