MicroStrategy ONE

User Authentication and Validation

In the MicroStrategy Web single sign-on workflow, a user who has already logged in once to another system or application does not need to provide credentials again when logging in to MicroStrategy Web. The specific steps in the workflow are determined by what kind of external mechanism is used for authentication and whether credentials are saved in an external repository. In almost all cases, the user information against which the original authentication is performed is stored in an external repository such as an external database, an LDAP directory, a Windows domain, or a flat file. While each of these repositories requires slightly different handling, the high-level requirements for user creation and synchronization, authentication, and validation are generally the same.

The high-level requirements for authenticating and validating users to MicroStrategy Web when an external user repository is used for initial authentication are listed below:

  1. Creating, updating, and synchronizing users

    Before you implement single sign-on for MicroStrategy Web, you must have in place a mechanism for creating and updating MicroStrategy users, as well as a process for synchronizing these MicroStrategy user profiles with the user profiles against which the original authentication takes place.  

  2. Authenticating a user

    You can authenticate users in two ways, depending on the external mechanism used for authentication. You can either extract the credentials programmatically or simply validate the user request.  

  3. Validating an authenticated user

    You can use one of two general methods to validate users who have already been authenticated.

Creating, updating, and synchronizing users

Before single sign-on can take place, the user's MicroStrategy profile must be created. Additionally, this profile must be kept updated based on any changes to the user in your external user repository over time.

  • Creating users within the MicroStrategy metadata and assigning proper application privileges and access control

    You can use the User Manager GUI tool to create users, or you can create users programmatically with Command Manager or via the MicroStrategy Web API.  

  • Responding to changes in the user's profile, such as moving to a different department, as well as adding new users

    The need to synchronize the user profiles in your external user repository and the user profiles in the MicroStrategy metadata arises for a number of reasons. For example, a user may move from one business department to a different department. This may mean the user now has different ACL/access privileges within MicroStrategy Web. Or, a user's properties may change in your external user repository, and this change must be synchronized with the user's profile in the MicroStrategy metadata. Synchronization can occur in a batch process triggered either by time or by a specific action, or synchronization can happen every time a user logs on.

Authenticating a user

Once users have been created and their user profiles synchronized as needed, they can be authenticated. When a user connects to MicroStrategy Web and authentication is required, credentials must be passed to MicroStrategy Web in order to authenticate the user. There are two general methods for doing this:

  1. Passing credentials programmatically

    If the login credentials and the MicroStrategy credentials are the same, the login credentials can be passed programmatically without the user being prompted to enter them again. The passed credentials are verified against the user profile in the external user repository, and the request is processed.  

  2. Performing user mapping

    If the login credentials and the MicroStrategy credentials are different, the login credentials can be associated with a different MicroStrategy user profile by performing user mapping. The user mapping can be stored in a database, passed as part of the request, or programmatically generated based on an algorithm. Using one of these methods, the login credentials are used to retrieve or generate the MicroStrategy credentials, which are then used to authenticate the user so that the request can be processed.

The choice of which authentication method to use depends on the external mechanism used for authentication and on the type of programmatic authentication performed. Common options for both of these variables are described in the following lists.

  • External mechanisms used for authentication:

    • A portal through which users connect to MicroStrategy Web  

    • An identity management application through which users connect to MicroStrategy Web  

    • A Windows domain through which users connect to MicroStrategy Web  

    • An already established MicroStrategy Web session which is passed along with the user's request

  • Types of programmatic authentication:

    • Credentials passed in the URL  

    • Credentials retrieved from a remote location, such as a credentials vault  

    • Credentials retrieved or generated by mapping an external user profile to a MicroStrategy user profile

    • In summary, to programmatically authenticate a user requires one or more of the following activities to take place:

    • Using login credentials passed programmatically  

    • Using an algorithm or lookup mechanism to map the login credentials to MicroStrategy credentials  

    • Retrieving MicroStrategy credentials from a credentials vault or other similar storage mechanism

Validating an authenticated user

Once a user has been authenticated with MicroStrategy Web, that existing authentication can simply be validated to give the user access to MicroStrategy Web, rather than requiring the user to be authenticated again. There are two general methods to validate the authentication of a user who has already been authenticated before connecting to MicroStrategy Web.

  1. Passing tokens

    In this scenario, a user has already been authenticated by an external authentication mechanism— such as a portal or an identity management application like CA SiteMinder, Oracle Identity Manager, IBM Tivoli, or RSA Security— before connecting to MicroStrategy Web. MicroStrategy Web simply verifies that the user is already authenticated using information, such as a token or other user information, provided by the external authentication mechanism. 

  2. Passing a session

    In this scenario, a MicroStrategy session has already been created by an external application (such as by a portlet servlet within a portal), and this session is passed when a request is made to MicroStrategy Web. MicroStrategy Web uses this existing session to handle the request.

    If a user's session is no longer valid— for example, because it has timed out— MicroStrategy Web should refresh the session without prompting the user for credentials, using the same mechanism it used previously to establish the user's credentials during single sign-on.

See also