Advanced Authentication Service › Getting Started with Advanced Authentication › Advanced Authentication Flows › How Advanced Authentication Flows Work

How Advanced Authentication Flows Work

This section provides information about the back-end operations that take place when an end user tries to access a protected resource. In this section, ArcotID PKI is used as an example of the Advanced Authentication credential that can be used by an end user.

Assumptions:

This flow is based on the following assumptions:

• You have enabled the ArcotID PKI credential in the tenant console and configured the ArcotID PKI Only flow.
• You have configured the Credential Handling Service to protect the resource realm with the CA SiteMinder authentication scheme corresponding to the ArcotID PKI Only flow.
• The browser used for transactions is capable of supporting Java Applet and Native Client.
• JavaScript is enabled in the browser.
• An ArcotID PKI credential has been downloaded to the end user’s device.

The Flow:

1. In a browser window, the end user attempts to access a protected resource.
2. The end user is directed to the Credential Handling Service page.
3. The end user clicks the ArcotID PKI Only Flow button.
4. The SiteMinder Web Agent takes control of the request and performs the following operations:
   1. Checks for an existing Single Sign-On (SSO) session, if any. If an SSO session is available, it grants access to the resource.
   2. If no SSO session is available, then the Web Agent interacts with the Policy Server. The Policy Server configuration indicates that ArcotID PKI is configured to protect the resource.
   3. The SiteMinder policy determines that because ArcotID PKI is configured as the primary authentication mechanism, user authentication must be performed by Advanced Authentication service component called Shim and hence passes the authentication request to Shim.
5. Shim creates a shared token in the Advanced Authentication Data Service (AADS), which is a component of the Advanced Authentication service and resides in the Application Tier. It interacts with the database on behalf of the Advanced Authentication components..

   The shared token is used for communication between Shim and the Advanced Authentication application, and it contains information about the transaction state, tenantID, and the authentication scheme.

6. Shim returns to the Web Agent the Advanced Authentication URL to which the browser must be redirected.

   The specific URL to which the end user is redirected is specified when the resource is protected at SiteMinder. Depending on the tenant’s business requirements, this URL corresponds to one of the advanced authentication flows.

   Note: Each advanced authentication flow is supported by a different URL within the Advanced Authentication application.

7. The Web Agent redirects the browser to the Advanced Authentication URL.
8. In the Advanced Authentication application, the shared token is accessed by invoking the AADS. Thus, tenant and end user information is now known to the Advanced Authentication application.
9. The Advanced Authentication application looks up tenant configuration information, creates a page containing the tenant’s logo and style settings, and displays it to the end user.
10. The end user enters their user name and LDAP password on the page and clicks Submit.
11. If the end user enters an invalid password, an error page is displayed prompting the user to enter the correct password.
12. If the end user enters a valid password:
    1. The ArcotID PKI Client signs this challenge using the end user’s private key.
    2. The Advanced Authentication application performs the following operations:
       1. Sends the signed challenge to the Advanced Authentication Server for verification. If the signature is verified, a success message is sent to the Advanced Authentication application.
       2. Updates the shared token in the database indicating the authentication status.
       3. Redirects the browser to the FCC LANDING URL providing the end user’s user name, and tokenID as the password.

          FCC pages are static HTML pages used by Shim to collect user inputs during authentication.

    3. SiteMinder Web Agent receives the redirection request. The Policy Server invokes Shim and provides the user name and password (tokenID).
    4. Shim performs the following operations:
       1. Requests for the transaction state from State Manager.
       2. Verifies the LDAP password.
       3. Validates that the authentication was performed and forwards the authentication result to the Policy Server.
    5. The Policy Server generates a SiteMinder cookie.
    6. The SiteMinder Web Agent adds the cookie to the HTTP header and redirects the browser to the protected resource.