The SAML authentication process

When the Privileged Access Service presents a user to a SAML-enabled web application, it creates a SAML assertion for the user session that satisfies the requirements of the service provider (the web application host) and presents necessary information about the current user. The following figure shows the steps the Privileged Access Service takes when it authenticates a user to a SAML application added to the app catalog using the generic SAML application template. The steps follow.

  1. The user launches the web application in the Admin Portal.
  2. The Admin Portal notifies the Privileged Access Service that the user wants a session with the web application.
  3. The Privileged Access Service creates a set of JavaScript objects for this SAML user session:

    • An Application object that contains the properties of the web application as they’re defined in the web application profile. Those properties are defined using the generic SAML application template and include the application name, the URL, the issuer, the IdP sign-in URL, and others that appear in the template in the Admin Portal. The Application object is a read-only object. A script reads its properties through the object’s Get() method.
    • A LoginUser object that contains information about the user identity used to log onto the service provider: the user identity recognized by the web application (which is not necessarily the Admin Portal login user name) and so on. This is a read-write object that the Privileged Access Service or the user map script may alter before it’s used later in the custom SAML script to set the user name in the SAML assertion.
    • A private assertion object that defines the elements of the SAML assertion that the Privileged Access Service builds to send to the web application. This object isn’t visible to the custom SAML script, but the script may set the assertion object’s properties using a family of global “set” methods (described later).
  4. The Privileged Access Service determines the web application log-on user name as it was specified in the generic SAML application template. The template specifies one of these three methods:

    • The Privileged Access Service checks the user’s Active Directory user record through the connector, retrieves the specified attribute as the application user name, then assigns the user name to the LoginUser.Username property. The Privileged Access Service caches the returned attribute so that it doesn’t have to retrieve it again from Active Directory for later identical queries.
    • The Privileged Access Service reads the shared single user name specified in the template and assigns it to LoginUser.Username.
    • The Privileged Access Service executes the user map script set in the template, which creates a user name and assigns it to LoginUser.Username.
  5. The Privileged Access Service executes the custom SAML script to specify a SAML assertion for the user session.

    The script must define all the SAML assertion elements required by the web application. The script uses the global assertion-set methods to define the elements in the private assertion object.

  6. The Privileged Access Service creates a SAML assertion based on the properties of the private assertion object and includes the assertion in a SAML response.
  7. The Privileged Access Service signs the SAML response (or the SAML assertion within the response, depending on what’s specified in the custom SAML script). It uses the Privileged Access Service certificate private key unless the application profile is set to provide a different certificate. (Certificate assignment is set in the Application Settings tab of the generic SAML application template.)
  8. The Privileged Access Service sends the SAML response to the Admin Portal (or the browser running it). The SAML response has a redirection that instructs the Admin Portal to send the response to the web application at the URL specified in the SAML assertion.
  9. The Admin Portal sends the SAML response to the specified URL.
  10. The web application reads the SAML response and then (if the key and assertion checks out) logs the user into the web application.