MicroStrategy ONE

Single Sign-on to MicroStrategy Web

Single sign-on is a special authentication case where a user's request for MicroStrategy Web content or functionality is handled without specifically prompting the user for MicroStrategy login credentials. This is accomplished either by extracting the credentials programmatically or by simply validating the user request. Single sign-on to MicroStrategy Web is supported out-of-the-box in some environments, while others require customization.

The sections below provide the following general information about single sign-on to MicroStrategy Web:

Environments that support single sign-on to MicroStrategy Web

The following environments support the ability for a user to access MicroStrategy Web content or functionality without requiring the user to explicitly provide MicroStrategy user credentials. Single sign-on is supported:

  • When Windows NT system credentials are used for MicroStrategy authentication and session creation.

    Single sign-on is supported out-of-the-box for Windows NT, provided that user objects in the MicroStrategy metadata include or are linked to Windows NT credentials. You must use a custom ESM if you want to use a custom login page, perform custom authentication, or map one set of user credentials to another.  

  • When an identity management application controls access to MicroStrategy Web.

    For single sign-on with an identity management application, you must create a custom ESM to support SSO.  

  • When MicroStrategy Web content or functionality are accessed through a portal application.

    MicroStrategy provides out-of-the-box portlets for:

    • Oracle WebLogic
    • IBM WebSphere
    • Microsoft SharePoint
    • SAP Enterprise Portal
    • Liferay Portal
    • Drupal
    • DotNetNuke

    • The out-of-the-box MicroStrategy portlets support single sign-on using either the portal user repository or a special credentials mapper class. A custom ESM is provided with each out-of-the-box MicroStrategy portlet, but it simply informs the user to refresh the portlet if the session times out and does not perform any authentication functions. If you build a custom MicroStrategy portlet and want to provide single sign-on, you must create a custom ESM which performs authentication to support single sign-on.

Single sign-on entry points to MicroStrategy Web content or functionality

There are several single sign-on entry points to MicroStrategy Web content or functionality. A user can make a request to MicroStrategy Web from a browser, a portal/portlet, a third-party application, or an identity management application and be granted access without being prompted for MicroStrategy credentials if the MicroStrategy environment is properly configured. In each case, MicroStrategy Web can be configured to use the information passed with the request to try to authenticate the user (including using the information to retrieve or generate other credentials), transparently to the user. If this authentication is successful, a MicroStrategy user session is created on Intelligence Server and single sign-on is successful.

To achieve single sign-on when MicroStrategy Web receives a request from one of these entry points, the application must be able to authenticate or validate the user, using whatever information has been forwarded to it and in whatever form it is passed. Information can be passed in the URL, HTML form data, or cookies, and it can include user credentials, session state, a session ID representing an established session, or a token representing a trusted authentication provider. The information that is passed can be used to generate or retrieve other credentials. The table below lists the typical information passed from each entry point.

Entry point Typical information passed

Browser

User credentials in URL

Portal / portlet

User credentials, token, session ID, or mapped user ID

Third-party application

User credentials, token, session ID, or mapped user ID

Identity management application

Token or mapped user ID

Prerequisites for implementing single sign-on to MicroStrategy Web

The following are prerequisites for implementing single sign-on to MicroStrategy Web:

  1. MicroStrategy user objects must exist in the MicroStrategy metadata, and these user objects must have the required identifying information for each supported authentication mode (that is, authenticating authority) enabled for MicroStrategy Web. 

  2. The identifying information for the MicroStrategy user objects must be kept updated (that is, synchronized), based on changes to the user in the user repository over time.

    A mechanism must exist for linking the credentials the user initially supplies to log into the system with the credentials needed to authenticate the user to MicroStrategy Web. The relationship between these two sets of credentials, called user mapping, must remain synchronized in order for single sign-on to work— that is, the MicroStrategy user profile must be kept updated based on any changes to the user in the system user repository over time. For example, new users may be added or existing users may be moved from one business department to another, possibly changing their ACL/access privileges within the MicroStrategy application.   

  3. The specified authentication mode (that is, authenticating authority)— and the associated user repository— must exist. The user repository must contain the identifying information needed by the authenticating authority for authentication and session creation.

    In most cases, the user repository used by the authenticating authority is an external database, an LDAP directory, a Windows domain, or a flat file. Generally, the information in these repositories— that is, the credentials used to authenticate the user to the system or controlling application— is not the information used to authenticate the user to MicroStrategy. Instead, it is associated with another set of credentials that is used to authenticate the user to MicroStrategy. The relationship between these two sets of credentials is called user mapping. 

  4. If required, a custom External Security Module (ESM) must provide the logic or links to an external application that are needed to perform some or all of the authentication tasks. In some cases, a custom ESM is provided to support out-of-the-box single sign-on, such as for the supported portal products. In other cases, you must create a custom ESM.

Workflow for single sign-on to MicroStrategy Web

Regardless of the specific environment or entry point, the high-level process of single sign-on to MicroStrategy Web is generally the same. What differs is the specific authentication or validation process, which is determined by such factors as the authenticating authority, if and how credentials are saved in an external user repository, and how these credentials are used to provide MicroStrategy Web authentication.

  1. A user logs on to the application or system that controls authentication to MicroStrategy Web (that is, to one of the environments that support single sign-on to MicroStrategy Web). 

  2. The user attempts to access MicroStrategy Web content or functionality, from one of the entry points to MicroStrategy Web. 

  3. The application or system controlling authentication uses the information provided for its initial authentication (such as login credentials or tokens) to try to authenticate or validate the user to MicroStrategy Web. The exact mechanism for authentication or validation varies, depending on such factors as the specific environment, whether single sign-on is provided out-of-the-box or by a custom implementation, and whether authentication involves session creation or validation of an existing session. One of the following actions takes place. 

    • The user is authenticated using Windows NT system credentials.

      The administrator must have enabled Windows NT authentication and linked the MicroStrategy user credentials to Windows credentials. 

    • The user is authenticated by an identity management application.

      A custom ESM must validate the token passed by the identity management application. 

    • The user is authenticated by a portal application.

      The retrieval of credentials is handled automatically by the portlet for out-of-the-box MicroStrategy portlets, but you must create a credentials mapper class if you want to map one set of credentials to another. (For out-of-the-box portlets, the custom ESM provided for you simply asks the user to refresh the portlet if the user session expires.) If you build a custom portlet, you are responsible for creating a custom ESM to implement single sign-on. 

  4. If authentication or validation succeeds, it is transparent to the user and single sign-on is a success. Control— and a session ID— are passed to MicroStrategy Web and normal processing continues. If authentication fails, there are several options for what happens next, but each reflects the fact that single sign-on has not succeeded. Examples of possible actions include displaying an error message, giving the user a chance to enter MicroStrategy credentials directly, or redirecting the user to another page.

See also: