Table 5.1 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.
Permissions by Object Type 49
Folder
For folders, follow these guidelines:
n 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.
n To enable users to contribute objects to a folder, grant them WriteMemberMetadata permission on that folder.
n On a folder, grant WriteMetadata permission only to users who should be able to delete, move, or rename that folder.
n Do not assume that every permission that is listed for a folder is relevant for every object in that folder.
n If you deny ReadMetadata permission on a folder, make sure that you do not 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 Chapter 6, “Access to Metadata Folders,” on page 71.
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:
n A broad approach is to grant Read permission to SASUSERS in the repository ACT's permission pattern, or on the top folder.
n A narrow approach is to grant Read permission to smaller groups on specific subfolders or even specific information maps.
Report
If a user cannot run a report, check these things:
n Does the user have Read permission for the underlying information map?
n Does the user have Read permission for any underlying OLAP cube?
n Does the user have Read permission for any underlying relational data that is accessed via the MLE?
n Does the SAS Trusted User have ReadMetadata permission for any underlying cube?
n 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 cannot 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 System Publishing Channels 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 System Publishing Subscribers Content Subscribers folder).
Dashboard
See “Implementing Security for SAS BI Dashboard” in SAS Intelligence Platform: Web Application Administration Guide.
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 cannot 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 cannot 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 precisely (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.
Permissions by Object Type 51