Typical MicroStrategy Single Sign-on Workflow

The diagram below illustrates the steps taken during a typical MicroStrategy Web single sign-on workflow. The specific steps taken in your environment depend on the external authentication mechanism used and on the type of programmatic authentication you choose.

The explanations provided in the steps below correspond to the numbered steps in the single sign-on workflow diagram shown above:

1. User request

   The user makes a request to MicroStrategy Web.  

2. Challenged for credentials

   The user's request is intercepted by a 3rd-party single sign-on application. The single sign-on application checks to see whether the user has already been authenticated. If not, it asks the user to provide login credentials.  

3. Pass credentials

   The single sign-on application passes the credentials provided by the user to its policy server so that they can be authenticated.  

4. Authenticated against user store

   The policy server verifies the credentials against the external repository where user credentials are stored (such as a directory server).  

5. Evaluate and grant access

   Once the user has been authenticated, the single sign-on application checks with its policy server to determine whether it is valid for this user to access the requested MicroStrategy resource (that is, whether the user is authorized to perform the requested action). If the request is valid, the user credentials are forwarded to MicroStrategy Web along with a session token (which is a transient, time-based token).  

6. User tokens and credentials passed

   MicroStrategy Web receives the user credentials and token.  

7. User token

   MicroStrategy Web has been configured previously to handle such tokens by communicating with an external authentication mechanism through a custom MicroStrategy External Security Module (ESM). MicroStrategy Web passes the token to the custom ESM to handle.  

8. Pass token

   The custom ESM makes a call to the policy server (or possibly a token validation server) and passes the token so that its validity can be determined.  

9. Access granted

   The policy server sends a response indicating whether the token is valid or not and, if required, sends any relevant error messages.  

10. Process validation rules

    The custom ESM enforces validation rules such as where to send the user if validation fails or if the user has no access to MicroStrategy Web.  

11. MicroStrategy user profile

    The MicroStrategy user profile is passed from the custom ESM to MicroStrategy Web.  

12. MicroStrategy user profile

    The MicroStrategy user profile is sent to Intelligence Server so that it can be used to handle the user request.  

13. The user's request is handled and the requested content is sent to the user.