Permissions by Object Type

Permission Tips for Selected Content and Data Objects

Permission Tips for Selected System and Administrative Objects

Introduction

The following figure depicts common objects and uses arrows to indicate objects whose permission settings are most likely to need an adjustment. Here are some details about the figure:

Most of the up arrows indicate a need to extend the ability to read data. In the interest of a more secure initial deployment, Read access to data is not granted by default.
Each down arrow indicates a need to limit the ability to modify or delete a system object. Other system items are protected by default.
MLE refers to the metadata LIBNAME engine. The MLE items are listed to highlight the elevated permission requirements that apply when data is accessed through this engine.
The intent of the figure is to highlight the adjustments that are most commonly needed. In general, it is preferable to set permissions on a parent (such as a folder) rather than on each individual object (such as a report).

Common Access Adjustments by Object Type

The following tables provide object-specific instructions and tips. The purpose of the tables is to highlight special requirements for common items.

Tip

For any change-managed areas or resources, change-managed users should have CheckInMetadata (CM) permission (instead of WM or WMM). See Setting up Change Management in SAS Intelligence Platform: Desktop Application Adminstration Guide.

Permission Tips for Selected Content and Data Objects

Permissions Tips: Selected Content and Data Objects

Root folder	The root folder (the SAS Folders node) is an important point of control for narrowing WM. Unlike other folders, the root folder does not have the WriteMemberMetadata permission in its permission list. This is because the root folder is a software component object, not a true folder. The root folder can contain only other folders.
Folder	For folders, follow these guidelines: Provide users with a clear path of grants of ReadMetadata permission to all of the content that they access. This is a navigational requirement. To browse past a folder, you need ReadMetadata permission for that folder. To enable users to contribute objects to a folder, grant them WriteMemberMetadata permission on that folder. On a folder, grant WriteMetadata permission only to users who should be able to delete, move, or rename that folder. Don't assume that every permission that is listed for a folder is relevant for every object in that folder. If you deny ReadMetadata permission on a folder, make sure that you don't prevent the SAS Trusted User from having that permission on all cubes and schemas within that folder. One approach is to give the SAS System Services group a grant of ReadMetadata permission on the folder. This preserves necessary access for this privileged service identity. See Permissions on Folders.
Information map	To access any data through an information map, you need Read permission on that information map. You can manage Read permission globally or selectively. For example: A broad approach is to grant Read permission to SASUSERS in the repository ACT's permission pattern, or on the top folder. A narrow approach is to grant Read permission to smaller groups on specific subfolders or even specific information maps.
Report	If a user can't run a report, check these things: Does the user have Read permission for the underlying information map? Does the user have Read permission for any underlying OLAP cube? Does the user have Read permission for any underlying relational data that is accessed via the MLE? Does the SAS Trusted User have ReadMetadata permission for any underlying cube? Does the account that retrieves any underlying SAS data have physical access to that data? It is especially important to manage ReadMetadata permission to pregenerated reports, because those reports can contain embedded data. Any user who views a pregenerated report sees the same data, regardless of his or her permissions to the underlying tables or cubes.
Stored process	To run a stored process, you need ReadMetadata permission on the stored process. If you can see a stored process but can't run it, you might lack the necessary grant of Read permission for the underlying data. To register a stored process, you need WriteMetadata permission for the target application server. The method that you use to make a stored process available can affect data retrieval and security. For example, in the standard configuration, a stored process that is assigned to a workspace server and embedded in an information map retrieves SAS data under the pooled workspace server's host identity. However, if a user opens that same stored process directly (for example, as a report in SAS Web Report Studio), the host identity of the requesting user (or group) retrieves the data.
Channel	In a new deployment, only the SAS Administrators group can add channels, subscribers, and content. To enable all registered users to publish content to a particular channel, navigate on the Folders tab to SystemPublishingChannels and grant Write and WriteMetadata permissions to SASUSERS on that channel (WM is required only if a channel has an archive persistent store). To enable all registered users to add channels or subscribers, grant WriteMemberMetadata permission on the relevant parent folder (for example, on the SystemPublishingSubscribersContent Subscribers folder).
Dashboard	See Implementing Security for SAS BI Dashboard in SAS Intelligence Platform: Web Application Administration Guide. Dashboards and their related items (indicators, data models, and ranges) have a specialized authorization model.
Schema	To associate an OLAP schema with an application server, you need WriteMetadata permission for the schema and the server. To add cubes to a schema, you need WriteMetadata permission for the schema and WriteMemberMetadata permission for the target folder. The SAS Trusted User must have ReadMetadata permission for all OLAP schemas and cubes. This access is usually granted through the SAS System Services group.
Cube	To register cubes, you need WriteMetadata permission for the OLAP schema and WriteMemberMetadata permission for the target folder. To associate a cube with a schema, you need WriteMetadata permission for the cube and the schema. Read permission is enforced for cubes. Grant Read permission broadly (as described for information maps), or add narrower grants of Read permission on folders or individual cubes. The SAS Trusted User must have ReadMetadata permission for all OLAP schemas and cubes. This access is granted through the SAS System Services group.
Cube component	For cube components, Read permission is enforced. If you lack access to a measure that participates in a calculated measure, you can get unintended results. There are also navigational requirements for Read permission on cube components. If a user does not have Read permission to a hierarchy, the user can't navigate to the top levels within the hierarchy. If a user does not have Read permission to a particular level in a hierarchy, the user can't navigate to the next level.
Shared dimension	To set permissions on a shared dimension, navigate to it directly under its parent folder. You cannot set permissions on a shared dimension that you accessed by navigating within a cube. You cannot delete a shared dimension that is in use (that is included in one or more cubes).
Library	To associate a library with an application server, you need WriteMetadata permission for the server (but not for the library). For a library that is accessed via the metadata LIBNAME engine (MLE), you need the Create permission in order to add tables and the Delete permission in order to delete tables.
Table	To associate a table with a library, you need WriteMetadata permission for the table and the library. For a table that is accessed via the MLE, you need Read permission in order to access data. The Create, Delete, and Write permissions affect your ability to add, update, or delete data. You can grant these permissions broadly (as described in the information map row) or narrowly (for example, to a small group of users on a particular table.
Column	The MLE doesn't support column-level access distinctions for the Read permission. Column-level access distinctions for the ReadMetadata permission are supported.

Permission Tips for Selected System and Administrative Objects

Permissions Tips: Selected System and Administrative Objects

Repository	On a foundation repository, all participating users should have repository-level ReadMetadata and WriteMetadata permissions. Other predefined entries in the permission pattern of the repository ACT (Default ACT) provide necessary administrative and service access.
Application server	To monitor or operate servers other than the metadata server, you need the Administer permission on the server. (The metadata server requires the Metadata Server: Operation role instead of the Administer permission.) To associate a stored process, OLAP schema, or library with an application server, you need WriteMetadata permission for that application server. Certain service identities need ReadMetadata permission to all server definitions. See Permissions on Servers.
Logical server	To use a logical server, you need ReadMetadata permission for at least one of that server's connections. This is called server access security. Certain service identities need ReadMetadata permission to logical server definitions. See Hide Server Definitions.
Identity	User administration capabilities (from the Metadata Server: User Administration role) enable you to create, update, and delete users, groups, and roles. You can delegate management of an identity to someone who doesn't have user administration capabilities by adding explicit or ACT grants of WriteMetadata permission in the identity's authorization properties. An identity's authorization properties have no effect on what that identity can do.
ACT	To create an ACT, you need repository-level WriteMetadata permission. Each predefined ACT is protected by direct access controls. ACTs that you create aren't automatically protected. It is essential to add protections (direct controls in the ACT’s authorization properties) to any ACTs that you create.

Permissions by Object Type

Introduction

Permission Tips for Selected Content and Data Objects

Permission Tips for Selected System and Administrative Objects

See Also