User-Password Authentication Overview

When the Privileged Access Service authenticates a user to a user-password web application, the Privileged Access Service creates an HTML response for the user session that satisfies the requirements of the web application and presents necessary information about the current user. The following figure shows user-password authentication steps. Step descriptions 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 user-password 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 user-password application template and include the application name, the URL, the icon, 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 web application log-on user name (which is not necessarily the Admin Portal login user name) and so on. This is a read-write object that may be altered before it’s used later in the custom user-password script to set the user name and password in the HTML response.

    • A response object that defines the elements of the HTML response that the Privileged Access Service builds to send to the web application. The response object is a read/write object that the custom user-password script sets using the object’s AddFormField() method.

  4. The Privileged Access Service determines the web application log-on user name and password as specified in the generic user-password application template.The template specifies any one of these four methods:

    • The Privileged Access Service checks the user’s Active Directory user record through the connector and retrieves the specified attribute as the application user name. It prompts the user for the password. The Privileged Access Service then assigns the user name to the LoginUser.Username property and the password to the LoginUser.Password property.

      The Privileged Access Service caches the returned user-name attribute so that it doesn’t have to retrieve it again from Active Directory for later identical queries. The Privileged Access Service also stores the password locally so the user need not enter it again for future user sessions with this application.

    • The Privileged Access Service reads the shared single user name and password specified in the template and assigns them to LoginUser.Username and LoginUser.Password.

    • The Privileged Access Service prompts the user for the web application log-on user name and password and assigns them to LoginUser.Username and LoginUser.Password.

      The Privileged Access Service stores the user name and password locally so the user need not enter them again for future sessions with this application.

    • The Privileged Access Service executes the user map script set in the template, which creates a user name and assigns it to LoginUser.Username. The script may also create an optional password and assign it to LoginUser.Password.

      The Privileged Access Service prompts the user for a password in any case. If the script doesn’t create its own password, the Privileged Access Service writes the entered password to LoginUser.Password and also stores the password locally so that the user need not enter it again for future sessions with this application. If the script creates its own password, the Privileged Access Service ignores the user’s entered password.

  5. The Privileged Access Service executes the custom user-password script to specify an HTML response for the user session.

    The script must include all the HTML response fields required by the web application and must provide appropriate values for those fields. Most applications require only a user field and a password field, but a few may require additional fields. The script uses response.AddFormField() to define the elements in the private assertion object.

  6. The Privileged Access Service creates an HTML response based on the properties of the response object.

  7. The Privileged Access Service sends the HTML response to the Admin Portal (or the browser running it). The HTML response includes a redirection that instructs the Admin Portal to send the response to the web application at the URL specified in the web application’s profile.

    The profile must contain a standard URL (set in the URL field of the generic user-password application template) and may also contain a mobile URL (set in the Mobile URL field). If the request for connection comes from a mobile device, the Privileged Access Service redirects the HTML response to the mobile URL if one exists, otherwise the Privileged Access Service redirects the response to the standard URL. If the request for connection is not from a mobile device, the Privileged Access Service redirects the response to the standard URL.

  8. The Admin Portal sends the HTML response to the specified URL.

  9. The web application reads the HTML response and then (if the response checks out) logs the user onto the web application.