MicroStrategy ONE

Authentication workflows

The MicroStrategy Library authentication workflow varies, depending on the specific authentication modes that are enabled and whether the application is configured to support a single authentication mode or multiple authentication modes.

The diagrams and workflows below illustrate how authentication-related requests are handled with different authentication configurations. In these workflow diagrams:

  • Double-line arrows represent HTTP requests and responses, and single-line represent Java calls.
  • The object names correspond to bean IDs in the configuration XML files. You need to look at the configuration files to find out what Java classes define those beans.
  • Only beans involved in request authentication are included. Filters that simply pass the request along the filter chain or perform actions not directly involved in request authentication are not included. As described in Spring Security architecture, each request passes through multiple Spring Security filters.

The authentication workflows are grouped under multi-mode (multiple authentication modes supported) and single mode (only one authentication mode supported).

Multi-mode workflows

Diagrams and request handling workflows when an application is configured to allow several authentication modes

Single mode workflows

Diagrams and request handling workflows when an application is configured to support only one authentication mode

 

Multi-mode workflows

  • Initial (unauthorized) login request

    The diagram below shows the initial request workflow when an application is configured to support several authentication modes.

    1. The browser submits an initial application request.
    2. Because this request does not contain an authentication mode, the Multi-mode login entry point redirects this request to the Multi-mode login page.

  • Standard authentication mode login request

    The diagram below illustrates the handling of a request submitted by the Multi-mode login page when a user chooses the Standard login mode, enters a user ID and password, and clicks the login button. In this case, the login request will contain the loginMode parameter with a value of 1 (Standard), among other parameters.

    1. The Multi-mode login page submits a login request.
    2. The Multi-mode login filter recognizes that this is a Standard mode login request and delegates to the Standard mode login filter.
    3. The Standard mode login filter uses the Standard mode IServer credentials provider to create IServer credentials.
    4. The Standard mode login filter then passes the IServer credentials to the Standard mode authentication provider to authenticate the user with the IServer.
    5. The Standard mode authentication provider passes the IServer credentials to the Session Manager, which uses the credentials to create an IServer session.
    6. When an IServer session is created, this indicates that authentication succeeded. The Standard mode login filter calls the Login success handler, which redirects the browser to the original request.

  • LDAP authentication mode login request

    The LDAP login request is submitted by the Multi-mode login page when a user chooses the LDAP login mode, enters a user ID and password, and clicks the login button. In this case, the login request will contain the loginMode parameter with a value of 16 (LDAP), among other parameters. The workflow for handling this request is exactly the same as the workflow for a Standard login request except the beans involved have "ldap" in their names instead of "std".

  • Guest authentication mode login request

    The Guest login request is submitted by the Multi-mode login page when a user clicks on the Guest button. In this case, the login request will contain the loginMode parameter with a value of 8 (Anonymous), among other parameters. The workflow for handling this request is exactly the same as the workflow for a Standard login request except the beans involved have "guest" in their names instead of "std".

  • SAML authentication mode login and response requests

    • SAML authentication mode login request

      The SAML login request is submitted by the Multi-mode login page when a user clicks on the SAML button. In this case, the login request will contain the loginMode parameter with a value of 1048576 (SAML), among other parameters. The workflow for handling this request is different from the workflows shown above.

      1. The Multi-mode login page submits a login request.
      2. The Multi-mode login filter recognizes that this is a SAML login request and delegates to the SAML login filter.
      3. Because the SSO login GUI needs to be displayed, the SAML login filter delegates to the SAML Entry point, which redirects to the SSO login end point.

    • SAML authentication mode response request

      This request is submitted (via redirect) by SSO after it authenticates the user.

      1. SSO redirects the user to the MicroStrategy Library application. The redirected request contains a SAML assertion describing the authenticated user.
      2. The SAML processing filter extracts the SAML assertion from the request and passes it to the Authentication Provider.
      3. The Authentication Provider verifies the assertion and then calls the IServer Credentials provider to build an IServer credentials object from the SAML assertion information.
      4. The Authentication Provider passes the IServer credentials to the Session Manager to create an IServer session.

      5. The SAML processing filter calls the Login success handler, which redirects the browser to the original request.

      The sequence of calls in this workflow is different from the Standard login mode workflow. This difference is dictated by the Spring Securtity SAML Extension that the MicroStrategy Library SAML support is based on.

  • Integrated (Kerberos) authentication mode login request

    The Kerberos login request is submitted by the Multi-mode login page when a user clicks on the Integrated button. In this case, the login request will contain the loginMode parameter with a value of 128 (Kerberos), among other parameters.

    1. The Multi-mode login page submits the login request.
    2. The Multi-mode login filter recognizes that this is a Kerberos login request and delegates to the Kerberos login filter.
    3. Because the Kerberos login GUI needs to be displayed, the Kerberos login filter delegates to the Kerberos Entry point, which returns a 401 response code along with SPNEGO protocol headers instructing the browser to show the Kerberos login dialog.

  • SPNEGO processing request

    This request is submitted when a user clicks the Login button on the Kerberos login dialog.

    1. The Kerberos dialog submits the login request containing the user's Kerberos ticket.
    2. The Kerberos processing filter extracts the ticket from the request and passes it to the Authentication Provider.
    3. The Authentication Provider verifies the ticket, creates IServer credentials containing this ticket, and passes the credentials to the Session Manager to create an IServer session.
    4. The Kerberos processing filter calls the Login success handler, which redirects the browser to the original request.

 

Single mode workflows

  • Standard authentication mode login

    The diagram below shows the initial request workflow when an application is configured to support only Standard authentication mode.

    1. The browser submits the initial application request.
    2. Since the only available authentication mode is Standard, the Multi-mode login entry point delegates to the Standard mode entry point.

    3. The standard mode entry point redirects this request to the Standard-mode login page.

      Notice that by default this workflow redirects to the same Multi-mode login page as in the multi-mode workflow This page is smart enough to adjust its GUI depending on what authentication modes are enabled for a given application.

    When the user clicks on the login button, the Standard mode login request is submitted. The workflow for handling this request is described in the Standard mode login request section for multi-mode workflows.

  • LDAP authentication mode login

    The workflow for handling the initial request when an application is configured to support only LDAP mode is the same as the workflow for the Standard login mode described above. The only difference is that it uses mstrLdapEntryPoint instead of mstrStdEntryPoint.

  • SAML authentication mode login

    The diagram below shows the initial request workflow when an application is configured to support only SAML authentication mode.

    • The browser submits the initial application request.
    • Since the only available authentication mode is SAML, the Multi-mode login entry point delegates to the SAML entry point.
    • The SAML entry point redirects this request to the SSO login end point.

  • Integrated (Kerberos) authentication mode login

    The diagram below shows the initial request workflow when an application is configured to support only Integrated (Kerberos) authentication mode.

    1. The browser submits the initial application request.
    2. Sinces the only available authentication mode is Integrated, the Multi-mode login entry point delegates to the Kerberos entry point.
    3. The Kerberos entry point generates a 401 response with SPNEGO headers, which instruct the browser to display the Kerberos login GUI.

  • Guest authentication mode login request

    The diagram below shows the initial request workflow when an application is configured to support only Guest authentication mode. Because this login mode does not require any GUI, the original request is handled by the filters.

    1. The browser submits the initial application request.
    2. Since the only available authentication mode is Guest, the Multi-mode login filter delegates to the Guest login filter.
    3. The Guest login filter uses the Guest IServer credentials provider to create IServer credentials.
    4. The Guest login filter passes the IServer credentials to the Guest authentication provider to authenticate the user with the IServer.
    5. The Guest authentication provider passes the IServer credentials to the Session Manager, which creates an IServer session.
    6. The Guest login filter uses the Login success handler, which in this case passes the original request, now authenticated, down the filter chain.

  • Trusted authentication mode login request

    1. The browser submits the initial application request.
    2. The request is intercepted by the SSO proxy, which authenticates the user in some way.
    3. The SSO proxy resubmits the original request with additional headers containing information about the authenticated user.
    4. Since the only available authentication mode is Trusted, the Multi-mode login filter delegates to the Trusted login filter.
    5. The Trusted login filter uses the Trusted IServer credentials provider to create an IServer credentials object and populates it with data from the SSO headers.
    6. The Trusted login filter passes the IServer credentials to the Trusted authentication provider.
    7. The Trusted authentication provider passes the IServer credentials to the Session Manager, which creates an IServer session.
    8. The Trusted login filter uses the Login success handler, which in this case passes the original request, now authenticated, down the filter chain.