Controlling access to objects: Permissions

Permissions define the degree of control users have over individual objects in the system. For example, in the case of a report, a user may have permission to view the report definition and execute the report, but not to modify the report definition or delete the report.

While privileges are assigned to users (either individually, through groups, or with security roles), permissions are assigned to objects. More precisely, each object has an Access Control List (ACL) that specifies which permissions different sets of users have on that object.

Intelligence Server includes special privileges called Bypass All Object Security Access Checks and Bypass Schema Object Security Access Checks. Users with these privileges are not restricted by access control permissions and are considered to have full control over all objects and schema objects, respectively. For information about privileges, see Controlling access to functionality: Privileges.

To modify permissions for an object in Developer

1 In Developer, right-click the object and select Properties. The Properties dialog box for that object opens.

To modify an object's ACL, you must access the Properties dialog box directly from Developer. If you access the Properties dialog box from within an editor, you can view the object's ACL but cannot make any changes.

2 Select the Security category.
3 For the User or Group (click Add to select a new user or group), from the Object drop-down list, select the predefined set of permissions, or select Custom to define a custom set of permissions. If the object is a folder, you can also assign permissions to objects contained in that folder using the Children drop-down list.
4 Click OK.

For specific information about each setting in the dialog box, press F1 to see the Help.

To modify permissions for an object in MicroStrategy Web

1 In MicroStrategy Web, right-click an object and select Share. The Share dialog box for that object opens.
2 To modify permissions for a user or group, from the Permission Level drop-down list for that user or group, select the predefined set of permissions, or select Custom to define a custom set of permissions.
3 To add new users or groups to the object’s access control list (ACL):
a Click Choose Users/Groups. The User/Group browser opens.
b Select the users or groups that you want to add to the object’s ACL.
c From the Choose a Permission Level drop-down list, select the predefined set of permissions, or select Custom to define a custom set of permissions.
d Click Add. The users or groups are added to the list of users or groups, with the specified permissions.
4 To remove a user or group from the object’s ACL, click the X next to the user or group’s name.
5 When you are finished modifying the object’s permissions, click OK. The dialog box closes and your changes are saved.

Access control list (ACL)

The Access Control List (ACL) of an object is a list of users and groups, and the access permissions that each has for the object.

For example, for the Northeast Region Sales report you can specify the following permissions:

The Managers and Executive user groups have View access to the report.
The Developers user group (people who create and modify your applications) has Modify access.
The Administrators user group has Full Control of the report.
The Everyone user group (any user not in one of the other groups) should have no access to the report at all, so you assign the Denied All permission grouping.

The default ACL of a newly created object has the following characteristics:

The owner (the user who created the object) has Full Control permission.
Permissions for all other users are set according to the Children ACL of the parent folder.

Newly created folders inherit the standard ACLs of the parent folder. They do not inherit the Children ACL.

When creating new schema objects, if the Everyone user group is not defined in the ACL of the parent folder, Developer will add the Everyone user group to the ACL of the new schema object, and set the permissions to Custom. If the Everyone user group has permissions already assigned in the parent folder ACL, they will be inherited properly.

For example, if the Children setting of the parent folder’s ACL includes Full Control permission for the Administrator and View permission for the Everyone group, then the newly created object inside that folder will have Full Control permission for the owner, Full Control for the Administrator, and View permission for Everyone.

Modifying the ACL of a shortcut object does not modify the ACL of that shortcut’s parent object.

When you move an object to a different folder, the moved object retains its original ACLs. When you copy an object, the copied object inherits its ACL from the Children ACL of the folder into which it is copied.

What permissions can be granted for an object?

When you edit an object’s ACL using the object’s Properties dialog box, you can assign a predefined grouping of permissions or you can create a custom grouping. The table below lists the predefined groupings and the specific permissions each one grants.

Grouping

Description

Permissions granted

View

Grants permission to access the object for viewing only, and to provide translations for an object’s name and description.

Browse
Read
Use
Execute

Modify

Grants permission to view and/or modify the object.

Browse
Read
Write
Delete
Use
Execute

Full Control

Grants all permissions for the object and also allows to modify the ACL for the object.

Control and all other permissions are granted

Denied All

Explicitly denies all permissions for the object. None of the permissions are assigned.

none; all are denied

Default

Neither grants nor denies permissions. All permissions are inherited from the groups to which the user or group belongs.

none

Custom

Allows the user or group to have a custom combination of permissions that you can define.

custom choice

Consume

(Only available in MicroStrategy Web)

(Intelligent Cube only) Grants permission to create and execute reports based on this Intelligent Cube.

Browse
Read
Use

Add

(Only available in MicroStrategy Web)

(Intelligent Cube only) Grants permission to create and execute reports based on this Intelligent Cube, and republish/re-execute the Intelligent Cube to update the data.

Browse
Read
Use
Execute

Collaborate

(Only available in MicroStrategy Web)

(Intelligent Cube only) Grants permission to create and execute reports based on this Intelligent Cube, republish/re-execute the Intelligent Cube to update the data, and modify the Intelligent Cube.

Browse
Read
Write
Delete
Use
Execute

The permissions actually assigned to the user or group when you select a permission grouping are explained in the table below.

Permission

Definition

Browse

View the object in Developer and MicroStrategy Web

Read

View the object’s definition in the appropriate editor, and view the object’s access control list. When applied to a language object, allows users to see the language in the Translation Editor but not edit strings for this language.

Write

Modify the object’s definition in the appropriate editor and create new objects in the parent object. For example, add a new metric in a report or add a new report to a document.

Delete

Delete the object

Control

Modify the object’s access control list

Use

Use the object when creating or modifying other objects. For example, the Use permission on a metric allows a user to create a report containing that metric. For more information, see Permissions and report/document execution. When applied to a language object, allows users to edit and save translations, and to select the language for display in their Developer or MicroStrategy Web language preferences. This permission is checked at design time, and when executing reports against an Intelligent Cube.

A user with Use but not Execute permission for an Intelligent Cube can create and execute reports that use that Intelligent Cube, but cannot publish the Intelligent Cube.

Execute

Execute reports or documents that reference the object. To execute a report or document, a user must have Execute access to all objects on the report/document. For more information, see Permissions and report/document execution. This permission is checked at run time.

The user must have Use permission on an Intelligent Cube to execute reports against that Intelligent Cube.

When you give users only Browse access to a folder, using the Custom permissions, they can see that folder displayed, but cannot see a list of objects within the folder. However, if they perform a search, and objects within that folder match the search criteria, they can see those objects. To deny a user the ability to see objects within a folder, you must deny all access directly to the objects in the folder.

For example, grant the Browse permission to a folder, but assign Denied All for the folder’s children objects, then select the Apply changes in permissions to all children objects check box. This allows a user to see the folder, but nothing inside it. Alternatively, if you assign Denied All to the folder and to its children, the user cannot see the folder or any of its contents.

Permissions for server governing and configuration

A server object is a configuration-level object in the metadata called Server Definition. It contains governing settings that apply at the server level, a list of projects registered on the server, connection information to the metadata repository, and so on. It is created or modified when a user goes through the Configuration Wizard. Server definition objects are not displayed in the interface in the same way other objects are (reports, metrics, and so on).

As with other objects in the system, you can create an ACL for a server object that determines what system administration permissions are assigned to which users. These permissions are different from the ones for other objects (see table below) and determine what capabilities a user has for a specific server. For example, you can configure a user to act as an administrator on one server, but as an ordinary user on another. To do this, you must modify the ACL for each server definition object by right-clicking the Administration icon, selecting Properties, and then selecting the Security tab.

The table below lists the groupings available for server objects, the permissions each one grants, and the tasks each allows you to perform on the server.

Grouping

Permissions Granted

Allows you to...

Connect

Browse

Connect to the server

Monitoring

Browse
Read
View server definition properties
View statistics settings
Use the system monitors

Administration

Browse
Read
Use
Execute
Start/stop the server
Apply runtime settings
Update diagnostics at runtime
Cancel jobs
Idle/resume a project
Disconnect user
Schedule reports
Delete schedules
Trigger events
Perform cache administration
Create security filters
Use Security Filter Manager

Configuration

Browse
Read
Write
Delete
Control
Change server definition properties
Change statistics settings
Delete server definition
Grant server rights to other users

Default

All permissions that are assigned to "Default"

Perform any task on that server.

Custom...

custom choice

Perform the tasks your custom selections allow.

How permissions are determined

A user can have permissions for a given object from the following sources:

User identity: The user identity is what determines an object’s owner when an object is created. The user identity also determines whether the user has been granted the right to access a given object.
Group membership: A user is granted access to an object if he or she belongs to a group with access to the object.
Special privileges: A user may possess a special privilege that causes the normal access checks to be bypassed:
Bypass Schema Object Security Access Checks allows the user to ignore the access checks for schema objects.
Bypass All Object Security Access Checks allows the user to ignore the access checks for all objects.

Permission levels

A user can have permissions directly assigned to an object, and be a member of one or more groups that have a different permission grouping assigned to the object. In this case, user-level permissions override group-level permissions, and permissions that are denied at the user or group level override permissions that are granted at that level. The list below indicates what permissions are granted when permissions from multiple sources conflict.

1 Permissions that are directly denied to the user are always denied.
2 Permissions that are directly granted to the user, and not directly denied, are always granted.
3 Permissions that are denied by a group, and not directly granted to the user, are denied.
4 Permissions that are granted by a group, and not denied by another group or directly denied, are granted.
5 Any permissions that are not granted, either directly or by a group, are denied.

For example, user Jane does not have any permissions directly assigned for a report. However, Jane is a member of the Designers group, which has Full Control permissions for that report, and is also a member of the Managers group, which has Denied All permissions for that report. In this case, Jane is denied all permissions for the report. If Jane is later directly granted View permissions for the report, she would have View permissions only.

Default permissions for folders in a new project

By default, in a new MicroStrategy project, users are only allowed to save objects within their personal folders. Only administrative users can save objects within the Public Folder directory in a MicroStrategy project. Folders in a new project are created with these default ACLs:

Public Objects folder, Schema Objects folder
Administrator: Full Control
Everyone: Browse
Public/Guest: Browse
Inherited ACL
Administrator: Default
Everyone: View
Public/Guest: View

This means that new users, as part of the Everyone group, are able to browse the objects in the Public Objects folder, view their definitions and use them in definitions of other objects (for example, create a report with a public metric), and execute them (execute reports). However, new users cannot delete these objects, or create or save new objects to these folders.

Personal folders
Owner: Full Control

This means that new users can create objects in these folders and have full control over those objects.

Permissions and report/document execution

Two permissions relate to report and document execution: the Use and Execute permissions. These have the following effects:

The Use permission allows the user to reference or use the object when they are modifying another object. This permission is checked at object design time, and when executing reports against an Intelligent Cube.
The Execute permission allows the user to execute reports or documents that use the object. This permission is checked only at report/document execution time.

A user may have four different levels of access to an object using these two new permissions:

Both Use and Execute permissions: The user can use the object to create new reports, and can execute reports containing the object.
Execute permission only: The user can execute previously created reports containing the object, but cannot create new reports that use the object. If the object is an Intelligent Cube, the user cannot execute reports against that Intelligent Cube.
Use permission only: The user can create reports using the object, but cannot execute those reports.

A user with Browse, Read, and Use (but not Execute) permissions for an Intelligent Cube can create and execute reports that use that Intelligent Cube, but cannot publish the Intelligent Cube.

Neither Use nor Execute permission: The user cannot create reports containing the object, nor can the user execute such reports, even if the user has Execute rights on the report.

Interpreting access rights during report/document execution

The ability to execute a report or document is determined by whether the user has Execute permission on the report and Execute permission on the objects used to define that report. More specifically, Execute permission is required on all attributes, custom groups, consolidations, prompts, metrics, facts, filters, templates, and hierarchies used to define the report or document. Permissions are not checked on transformations and functions used to define the report.

If the user does not have access to an attribute, custom group, consolidation, prompt, fact, filter, template, or hierarchy used to define a report, the report execution fails.

If the user does not have access to a metric used to define a report, the report execution continues, but the metric is not displayed in the report for that user.

This enhancement allows a finer level of access control when executing reports. The same report can be deployed to many users who experience different results depending on their respective permissions on metrics.

ACLs and personalized drill paths in MicroStrategy Web

You can control what attribute drill paths users see on reports. You can determine whether users can see all drill paths for an attribute, or only those to which they have access. You determine this access using the Enable Web personalized drill paths check box in the Project Configuration Editor, Project Definition: Drilling category. (In Developer, right-click a project and select Project Configuration.)

With the Enable Web personalized drill paths check box cleared (and thus, XML caching enabled), the attributes to which all users in MicroStrategy Web can drill are stored in a report’s XML cache. In this case, users see all attribute drill paths whether they have access to them or not. When a user selects an attribute drill path, Intelligence Server then checks whether the user has access to the attribute. If the user does not have access (for example, because of Access Control Lists), the drill is not performed and the user sees an error message.

Alternatively, if you select the Enable Web personalized drill paths check box, at the time the report results are created (not at drill time), Intelligence Server checks which attributes the user may access and creates the report XML with only the allowed attributes. This way, the users only see their available drill paths, and they cannot attempt a drill action that is not allowed. With this option enabled, you may see performance degradation on Intelligence Server. This is because it must create XML for each report/user combination rather than using XML that was cached.

For more information about XML caching, see Types of result caches.