SAML-Based Single Sign-On

Covered by this topic

SSO access is a standard for users accessing protected information, such as patient data. Access is provided by creating and enabling a login trust. This allows users to access all Enterprise Health services by signing in one time. When properly configured, users are redirected to the SSO login page to access the system, accordingly.

The following document provides details and considerations for using Security Assertion Markup Language (SAML)-based single sign-on (SSO) with the Enterprise Health systems. Enterprise Health currently supports SAML 2.0 SP-initiated or IDP-initiated workflows with the HTTP-POST binding.  Enterprise Health provides a SAML-based SSO application program interface (API). For an in-depth review of SAML, see the public Wikipedia page: https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language

The majority of this document was created for technical staff to utilize for SAML SSO configuration. The sections that follow are technical in nature. For a list of terminology commonly encountered as part of this topic, please see our SSO Documentation.

SAML

SAML assertions utilize most of the options detailed throughout the SSO Login Trust documentation. Note that in order to set up the  Enterprise Health system as a SAML service provider (SP), the following must be known about the identity provider (IDP):

  • The IDP Issuer: This goes in the Domain field of the Login Trust.
  • IDP Sign On Service URL: This goes in the Login URL field. Also, identify any steps required to ensure the IDP-specified subjects will be present in the  Enterprise Health system. This may be an interface which creates users, a configuration allowing the IDP to create new users, on demand, or a manual process within the Enterprise Health system.
  • Public Key/Certificate: Used to authenticate the assertions.
Note
SAML provides an option for including the public key in the assertion. This can pose a significant security vulnerability, so  Enterprise Health does not support this functionality. The public key must be provided prior to processing assertions.

Assertion Requirements

The IDP must include the following information in the Assertion (shown in XPath notation):

//Assertion/Subject/NameID - This must be the Enterprise Health username, or match a known translation, if enabled.

//Assertion/Issuer - This is the login trust Domain. Identifies the login_trusts entry (IDP) used for validating the assertion.

  • XMLDSig - The XML Signature. Must validate using the public key on file for the identified IDP.
  • If the Create New Users option has been enabled, the following are also required:
    • //Assertion/AttributeStatement/Attribute[@Name=“lastname”]/AttributeValue
    • //Assertion/AttributeStatement/Attribute[@Name=“firstname”]/AttributeValue
    • Optional:
      • //Assertion/AttributeStatement/Attribute[@Name=“email”]/AttributeValue



https://saml.example.com

5zno9n7vQQIc6bnVbiaUM4272xk= LlHu/jHpIbQAskUs+S1YCqvAo+E+nZnNX3QHZMTJJQ3nCK6Q9ApQk4akUoEqKRd77oJ/PVOXoqnUfWIdE1Mbxg78LCtYSqzT1fvw3Jbwi+eG14+PgjMP5Izx1bTtvFrg2cWI7lOsFrIRxepBgbvD+krTcJMAxVHJSOeYciMM+Vw=

https://saml.example.com

e9f91ee7-8cd0-4017-9a6c-c8e13be33645

123456789
Sam
Jones
urn:oasis:names:tc:SAML:2.0:ac:classes:Password


 

Enterprise Health Documentation

Last Updated:

Last Build: Wed, 11 Dec 2024 15:33:17 UTC
WikiGDrive Version: 2aacb51f060d0354a678419290943a99bd16aad1