Introduction to Access Management

Repository-level controls function as a gateway. Participating users should have the ReadMetadata and WriteMetadata permissions at the repository level. Repository-level controls also serve as a parent-of-last-resort, defining access to resources that do not have more specific settings. Repository-level controls are defined on the Permission Pattern tab of the repository ACT. In a standard configuration, the repository ACT is named Default ACT.

Resource-level controls manage access to a specific object such as a report, a stored process, a table, or a folder. You can define resource-level controls individually (as explicit settings) or in patterns (by using access control templates).

Fine-grained controls affect access to subsets of data within a resource. To establish fine-grained controls, you define permission conditions that filter data to constrain access.

Some applications use roles to limit access to functionality. These applications check each user's roles in order to determine which menu items and features to display for that user. Roles are documented as part of user administration.

Permission settings are conveyed across two distinct relationship networks, a resource network and an identity network.

Permissions that are set directly on an object have priority over permissions that are set on the object’s parent. For example, when access to a report is evaluated, a denial that is set on the report (and assigned to the PUBLIC group) overrides a grant that is set on the report's parent folder (even if the grant is assigned to you).

Permissions that you set on one object can affect many other objects. For example, a report inherits permissions from the folder in which the report is located. The resource relationship network consists primarily of a folder tree. For details and exceptions, see the discussion of the metadata authorization model in SAS Intelligence Platform: Security Administration Guide.

Permissions that you assign to one group can affect many other identities. For example, if you grant a group access to a table, that grant applies to all users who are members of the group. The identity relationship network is governed by a precedence order that starts with a primary identity, can incorporate multiple levels of nested group memberships, and ends with implicit memberships in SASUSERS and then PUBLIC.

If there is a tie in this network (for example, if you directly assign a user to two groups and give one group a grant and another group a denial), the outcome is a denial.

The following table introduces the general-purpose permissions:

The following table introduces some of the specialized permissions:

For more information, see the following documents: