Tips for Efficiently Using Permissions :: SAS® 9.4 Management Console: Guide to Users and Permissions

Assign Permissions to Groups

You can simplify access control management by assigning permissions to groups rather than to individual users. These examples assume that there are not other explicit or ACT settings on the object:

To allow only unrestricted users to access an object, set denials on that object for the PUBLIC group.
To enable only registered users to access an object, set denials for the PUBLIC group and then grant access back to the SASUSERS group.
To enable only ETL developers and unrestricted users to access an object, create a group for the ETL developers. Then deny permissions to the PUBLIC group and grant access back to the ETL developers group.

Use Folders to Organize Content

You can simplify access control management by creating a folder structure that reflects the access distinctions that you want to make. Instead of setting permissions on each individual object, set permissions on the folders. The objects in a folder inherit the folder's effective permissions.

Tip

To protect the folder structure, do not grant WriteMetadata permission on a folder to someone for whom WriteMemberMetadata permission is sufficient.

Centralize Permissions with ACTs

You can simplify access control management by using ACTs. An ACT is a reusable named pattern of settings that you can apply to multiple objects. Each ACT consists of these elements:

a list of users and groups
an indication of whether each permission is granted, denied, or unspecified for each user and group in the list

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. These constraints apply:

The highest point of control is the repository-level settings that are defined on the repository ACT's Permission Pattern tab. The security model requires that participating users have ReadMetadata and WriteMetadata access at the repository level, so broadly denying access here is not a workable approach. Instead, use the next point of control (for example, the top of the folder tree on the Folders tab).
Within the folder tree, users need a clear path of grants of ReadMetadata in order to navigate to the objects that they use. For this permission, setting denials on folders at a high level is not a workable approach.