Authorization Model

Overview of the Metadata Authorization Model

	About Metadata-Based Permissions
	Granularity and Mechanics
	Inheritance Paths and Identity Precedence

About Metadata-Based Permissions

SAS provides a metadata-based authorization layer that supplements protections from the host environment and other systems. Across authorization layers, protections are cumulative. In order to perform a task, a user must have sufficient access in all applicable layers.

CAUTION:: Some clients (such as SAS Data Integration Studio and SAS Enterprise Guide) enable power users to create and run SAS programs that access data directly, bypassing metadata layer controls.
It is important to manage physical layer access in addition to metadata layer controls. For example, use host operating system protections to limit access to any sensitive SAS data sets. See Host Access to SAS Tables.

CAUTION:: Not all permissions are enforced for all items.
Enforcement of permissions other than ReadMetadata and WriteMetadata varies by item type and (for data) by the method with which a library is assigned. See Use and Enforcement of Each Permission.

Granularity and Mechanics

You can set permissions at these levels of granularity:

Repository-level controls function as a gateway and as a parent-of-last-resort. Repository-level controls are managed from the Permission Pattern tab of the repository ACT. All registered users should have ReadMetadata and WriteMetadata permissions for the foundation repository.
Resource-level controls manage access to a specific item such as a report, an information map, a stored process, a table, a column, a cube, 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 add constraints called permission conditions to explicit grants of the Read permission.

See Also

	Permissions on Folders
	Permissions on Servers
	Fine-Grained Controls for Data

Inheritance Paths and Identity Precedence

Permission settings are conveyed across two distinct relationship networks:

In the resource relationships network, permissions that you set on one item can affect many other items. For example, a report inherits permissions from the folder in which the report is located. This network is a simple folder tree, with these exceptions:
- The root folder isn't the ultimate parent. This folder inherits from the repository (through the permission pattern of the repository ACT).
- The root folder isn't a universal parent. Some system resources (such as application servers, identities, and ACTs) are not in the folder tree. For these items, the repository ACT is the immediate and only parent.
- Inheritance within a table or cube follows the data structure. For example, table columns and cube hierarchies don't have a folder as an immediate parent. Instead, a column inherits from its parent table and a dimension inherits from its parent cube.
In the identity relationships network, permissions that you assign to one identity can affect many other identities. For example, if you grant a group access to a report, that grant applies to everyone who is a member of the group. This relationship network is governed by a precedence order that starts with a primary (usually individual) identity, can incorporate multiple levels of nested group memberships, and ends with implicit memberships in SASUSERS and then PUBLIC.