MicroStrategy ONE

Defining Sets of Privileges: Security Roles

A security role is a collection of project-level privileges that are assigned to users and groups. For example, you might have two types of users with different functionality needs: the Executive Users who need to run, sort, and print reports, and the Business Analysts who need additional capabilities to drill and change subtotal definitions. In this case, you can create two security roles to suit these two different types of users.

Security roles exist at the project source level, and can be used in any project registered with Intelligence Server. A user can have different security roles in each project. For example, an administrator for the development project may have a Project Administrator security role in that project, but the Normal User security role in all other projects on that server.

A security role is fundamentally different from a user group in the following ways:

  • A group is a collection of users that can be assigned privileges (or security roles) all at once, for the project source and all projects in it.
  • A security role is a collection of privileges in a project. Those privileges are assigned as a set to various users or groups, on a project-by-project basis.

For information about how privileges are inherited from security roles and groups, see Controlling Access to Functionality: Privileges

Managing Security Roles

The Security Role Manager lists all the security roles available in a project source. From this manager you can assign or revoke security roles for users in projects, or create or delete security roles. For additional methods of managing security roles, see Other Ways of Managing Security Roles.

To Assign a Security Role to Users or Groups in a Project

  1. In Developer, log in to the project source containing the security role.
  2. Expand Administration, then Configuration Managers, and then select Security Roles.
  3. Double-click the security role you want to assign to the user or group.
  4. Select the Members tab.
  5. From the Select a Project drop-down list, select the project for which to assign the security role.

  6. From the drop-down list of groups, select the group containing a user or group you want to assign the security role to. The users or groups that are members of that group are shown in the list box below the drop-down list.

    • By default, users are not shown in this list box. To view the users as well as the groups, select the Show users check box.
    • To assign a top-level group to a security role, from the drop-down list select All Groups.
  7. Select a desired user or group.
  8. Click the > icon. The user or group moves to the Selected members list. You can assign multiple users or groups to the security role by selecting them and clicking the > icon.
  9. When you are finished assigning the security role, click OK.

To Create a Security Role

  1. In Developer, log in to the project source you want to create the security role in.
  2. Expand Administration, go to Configuration Managers > Security Roles.
  3. From the File menu, point to New, and select Security Role.
  4. Enter a name and description for the new security role.
  5. Select the Privileges tab.
  6. Select the privileges to add to this security role. For an explanation of each privilege, see the List of Privileges section.

    To select all privileges in a privilege group, select the group.

  7. To assign the role to users, select the Members tab and follow the instructions in To Assign a Security Role to Users or Groups in a Project.
  8. Click OK.

To Delete a Security Role

  1. In Developer, log in the project source you want to remove the security role from.
  2. Expand Administration, then Configuration Managers, and then select Security Roles.
  3. Click the security role that you want to remove.
  4. From the File menu select Delete.
  5. Click Yes.

Other Ways of Managing Security Roles

You can also assign security roles to a user or group in the User Editor or Group Editor. From the Project Access category of the editor, you can specify what security roles that user or group has for each project.

You can assign roles to multiple users and groups in a project through the Project Configuration dialog box. The Project Access - General category displays which users and groups have which security roles in the project, and allows you to re-assign the security roles.

You can also use Command Manager to manage security roles. Command Manager is a script-based administrative tool that helps you perform complex administrative actions quickly. For specific syntax for security role management statements in Command Manager, see Security Role Management in the Command Manager on-line help (from Command Manager, press F1, or select the Help menu). For general information about Command Manager, see Automating Administrative Tasks with Command Manager.

If you are using UNIX, you must use Command Manager to manage your system's security roles.

Controlling Access to a Project

You can deny user or group access to a specific MicroStrategy project by using a security role.

To Deny User or Group Access to a Project

  1. In Developer, right-click on the project you want to deny access to. Select Project Configuration.
  2. Expand the Project Access category.
  3. In the Select a security role drop-down list, select the security role that contains the user or group who you want to deny project access.
  4. On the right-hand side of the Project access - General dialog, select the user or group who you want to deny project access. Then click the left arrow to remove that user or group from the security role.
  5. Using the right arrow, add any users to the security role for whom you want to grant project access. To see the users contained in each group, highlight the group and check the Show users check box.
  6. Make sure the user or group whose access you want deny does not appear in the Selected members pane on the right-hand side of the dialog. Then click OK.
  7. In Developer, under the project source that contains the project you are restricting access to, expand Administration, then expand User Manager.
  8. Click on the group to which the user belongs who you want to deny project access for. Then double-click on the user in the right-hand side of Developer.
  9. Expand User Definition, then select Project Access.
  10. In the Security Role Selection row, under the project you want to restrict access to, review the Security Role Selection drop-down list. Make sure that no security role is associated with this project for this user.
  11. Click OK.

When the user attempts to log in to the project, they receive the message "No projects were returned by this project source."

The Role-Based Administration Model

Beginning with version 9.0, the MicroStrategy product suite comes with a number of predefined security roles for administrators. These roles makes it easy to delegate administrative tasks.

For example, your company security policy may require you to keep the user security administrator for your projects separate from the project resource administrator. Rather than specifying the privileges for each administrator individually, you can assign the Project Security Administrator role to one administrator, and the Project Resource Administrator to another. Because users can have different security roles for each project, you can use the same security role for different users in different projects to further delegate project administration duties.

The predefined project administration roles cover every project-level administrative privilege except for Bypass All Object Security Access Checks. None of the roles have any privileges in common. For a list of the privileges included with each predefined security role, see the List of Privileges section.

The predefined administration security roles are:

  • Analyst, who have authoring capabilities.
  • Analytics Architect, who can create, publish, and optimize a federated data layer as the enterprise’s single version of the truth. Users can build and maintain schema objects and abstraction layers on top of various, changing enterprise assests.
  • Application Administrator, who have access to all application-specific tasks.
  • Application Architect, who create, share, and maintain intelligence applications for the enterprise.
  • Certifier, who can certify objects in addition to having authoring capabilities.
  • Collaborator, who can view and collaborate on a dashboard or document they have access to.
  • Consumer, who can only view a dashboard or document they have access to.
  • Database Architect, who can optimize query performance and utilization based on query type, usage patterns, and application design requirements by tuning VLDB settings or configuring schema objects.
  • Embedded Analytics Architect, who can inject, extend, and embed analytics into portals, third-party, mobile, and white-labelled applications.
  • IntroBI, which is used for the MicroStrategy class "Introduction to Enterprise Business Intelligence."
  • Mobile Architect, who builds, compiles, deploys, and maintains mobile environments and applications. This user can also optimize the end user experience when accessing applications via mobile devices.
  • Northeast Users, which is used for the MicroStrategy class "Introduction to Enterprise Business Intelligence."
  • Platform Administrator, who configures the Intelligence Server, maintain the security layer, monitor system usage, and optimize architecture in order to reduce errors, maximize uptime, and boost performance.
  • Power Users, which have the largest subset of privileges of any security role.
  • Project Bulk Administrators, who can perform administrative functions on multiple objects with Object Manager (see Copy Objects Between Projects: Object Manager), Command Manager (see Automating Administrative Tasks with Command Manager), and the Bulk Repository Translation Tool.
  • Project Operations Administrators, who can perform maintenance on various aspects of a project.
  • Project Operations Monitors, who can view the various Intelligence Server monitors but cannot make any changes to the monitored systems.
  • Project Resource Settings Administrators, who can configure project-level settings.
  • Project Security Administrators, who create users and manage user and object security.
  • System Administrator, who sets up, maintains, monitors, and continuously supports the infrastructure environment through deployment on cloud, Windows, or Linux.

For instructions on how to assign these security roles to users or groups, see Managing Security Roles.

Do not modify the privileges for an out-of-the-box security role. During upgrades to newer versions of MicroStrategy, the privileges for the out-of-the-box security roles are overwritten with the default privileges. Instead, you should copy the security role you need to modify and make changes to the copied version.