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.

   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.

To Modify Permissions for an Object in MicroStrategy Web

1. In MicroStrategy Web, right-click an object and select Share.
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):
   • Click Choose Users/Groups.
   • Select the users or groups that you want to add to the object's ACL.
   • 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.
   • Click Add.
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.

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.

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 they belong 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.

If the user does not have access to objects used in a prompt, such as an attribute in an element list prompt, object prompt, or attribute qualification prompt or a metric in metric qualification prompt or object prompt, the prompt is considered as not applied if the prompt answer is optional. Alternatively, the execution may fail to complain about a lack of access if a prompt answer is required.

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.