User Management

The MicroStrategy security model is built around the concept of a user. To work with MicroStrategy products, a user must log in to the system using a valid login ID and password. MicroStrategy users who are successfully logged in to the system can create and own objects such as reports, execute reports, and take advantage of all the other features in the system. Since users are defined in the metadata and exist across projects, you do not have to define users for every project you create in a single metadata repository.

Users are normally added to groups, frequently on functional lines in an organization. This simplifies user management by allowing access privileges and security filters to be applied to sets of users rather than to individual users.

This section provides examples for the most common user management actions.

One of the common user management actions is how to create a new connection map. A connection map in MicroStrategy is a link between a MicroStrategy user, a database connection, and a database login. It is used to apply database (row-level) security to a MicroStrategy user. Connection mapping allows administrators to assign a user or group in the MicroStrategy system to a specific login ID on the data warehouse RDBMS. The mappings are typically used to take advantage of one of several RDBMS data security techniques (security views, split fact tables by rows, split fact tables by columns) that architects may have already created. When a database connection map is modified, MicroStrategy Intelligence Server needs to be refreshed to recognize the changes.Connection mapping is useful when MicroStrategy users must be differentiated from each other at the data warehouse level or when they must be directed to separate data warehouses. These two scenarios are described below.

 

• Connecting to the data warehouse using different database logins

  In this scenario, the project, database instance, and data warehouse are the same for the users in two groups, but the connection mapping specifies different database logins for each group. For example, the CEO of the company has a login that allows access to all data, while all other users have a login that allows limited access to data. In the diagram below, the two different logins used are "MSTR users" and "CEO".

  
  

• Connecting to different data warehouses using the same project

  In this scenario, the project, database instance, and database login are the same, but the connection mapping specifies different database connections (and therefore, different DSNs) for the two groups. In order for the project to work with both data warehouses, they must have the same structure. This is applicable in an environment where there are two data warehouses—for example, one with domestic data and another with foreign data—and users must be directed to one or the other based on the user group to which they belong when they log in to MicroStrategy. In the diagram below, the two different database connections used are "US " and "Europe". Although the data warehouse login ID for both the database connections is "MSTR users", within MicroStrategy the users belong to two different groups - 'US users' and 'Europe users'.