Best Practices for Permissions

Centralize Permissions with Access Control Templates

Deny Broadly, Grant Selectively (To the Extent Possible)

Assign Access Controls to Groups

You can simplify access control by assigning permissions to groups rather than to individual users. Here are some examples:

To allow only unrestricted users to access an object, assign denials to the PUBLIC group.
To enable only registered users to access an object, assign denials to the PUBLIC group and grants to the SASUSERS group.
To enable only information developers and unrestricted users to access an object, create a group for the developers. On the object, assign denials to the PUBLIC group and assign grants to the developers group.

Use Folders to Organize Content

You can simplify access control by creating a folder structure that reflects the access distinctions that you want to make. Instead of adding access controls to each individual object, add access controls to parent folders. The objects in a folder inherit the effective permissions for a folder.

Tip

To protect the folder structure, do not grant WriteMetadata permission on a folder to someone if granting them WriteMemberMetadata permission is sufficient.

Centralize Permissions with Access Control Templates

You can simplify access control by using access control templates (ACTs). An ACT is a reusable pattern of settings that you can apply to multiple objects. Each ACT consists of the following elements:

a list of users and groups
for each identity and permission, an indication of whether the pattern of an ACT provides a grant, a denial, or no pattern setting

Deny Broadly, Grant Selectively (To the Extent Possible)

Assign denials to the broadest group (PUBLIC) and then add offsetting grants for users or groups whose access you want to preserve. Deny access at the highest point of control and then grant access back on specific containers or objects. The following constraints apply:

The highest point of control is the repository-level settings for the foundation repository. The security model requires that participating users have ReadMetadata and WriteMetadata access at this level. Therefore, broadly denying access in the permission pattern of the foundation repository’s Default ACT is not a workable approach. Instead, use the next point of control, which is the top of the SAS Folders tree.
In order to navigate within the folder tree, users need a clear path of grants of ReadMetadata to the objects that they use. For the ReadMetadata permission, setting denials on folders at a high level is not a workable approach.

Note: When users access objects by searching (instead of by navigating through the folder tree), a clear path of grants of ReadMetadata is not required.

Last updated: February 22, 2018