Introduction to Access Management :: SAS(R) 9.3 Management Console: Guide to Users and Permissions

About Access Management

Access management determines which items a user can interact with. The permissions that you set in SAS Management Console are part of a metadata-based access control system that SAS provides. These permission settings supplement protections in other layers (such as the operating system and the WebDAV). Across layers, protections are cumulative. You cannot perform a task unless you have sufficient access in all layers.

CAUTION:

Do not rely exclusively on metadata layer permissions to protect data.

Manage physical access (operating system and DBMS permissions) in addition to metadata layer access.

You manage access to an item as part of the item's properties (on the item's Authorization tab). Your roles and permissions determine which access management tasks you can perform.

Granularity and Mechanics of Permissions

Repository-Level Controls

Repository-level controls function as a gateway. Participating users usually need ReadMetadata and WriteMetadata permissions for the foundation repository. 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.

Resource-Level Controls

Resource-level controls manage access to a specific item such as a report, an information map, a stored process, a table, 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

Fine-grained controls affect access to subsets of data within a resource. To establish fine-grained controls, you define permission conditions that constrain access to rows within a table or members within an OLAP dimension.

Feature-Level Controls

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 not an authorization feature; they are managed and documented as part of user administration.

Inheritance and Precedence of Permissions

Two Relationship Networks

Permission settings are conveyed across two distinct relationship networks, a resource network and an identity network. Permissions that are set directly on an item have priority over permissions that are set on the item'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).

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 relationship network consists primarily of a folder tree. This list highlights exceptions:

The root folder is not the ultimate parent. This folder inherits from the repository (through the permission pattern of the repository ACT ).
The root folder is not a universal parent. Some system resources (such as application servers, identities, and ACTs) have the repository as their immediate and only parent.
Inheritance within a table or cube follows the data structure. For example, table columns and cube hierarchies do not have a folder as their immediate parent. Instead, a column inherits from its parent table and a hierarchy inherits from its parent cube.
In unusual circumstances, it is possible for an item to have more than one immediate parent. If there is a tie in this network (for example, if there are no settings on an item, the item has two immediate parents, and one parent provides a grant while the other parent provides a denial), the outcome is a grant. In other words, a grant from any inheritance path is sufficient to provide access.
In general, specialized folders (such as search folders, favorites folders, and virtual folders) don’t convey permissions to the objects that they contain. An exception is that a favorites folder does convey permissions to any child favorites folders (favorites groups) that it contains.

The Identity Relationships Network

Permissions that you assign to one group can affect many other identities. For example, if you grant a group access to an OLAP cube, that grant applies to all users who are members of the group. This relationship network is governed by a precedence order that starts with a primary identity, can incorporate multiple levels of 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 deny), the outcome is a deny.

Use and Enforcement of Each Permission

Permission (Abbreviation)	Actions Affected and Limitations on Enforcement
ReadMetadata (RM)	View an item or navigate past a folder. For example, to see an information map you need RM for that information map. To see or traverse a folder you need RM for that folder.
WriteMetadata (WM)	Edit, delete, change permissions for, or rename an item. For example, to edit a report you need WM for the report. To delete a report you need WM for the report (and WMM for the report's parent folder). WM affects the ability to create associations. For example, you need WM on an application server in order to associate a library to that server. WM affects the ability to create items in certain containers. For example, to add an item anywhere in a repository, you need WM at the repository level. For folders, adding and deleting child items is controlled by WMM, not WM.
WriteMemberMetadata (WMM)	Add an item to a folder or delete an item from a folder. For example, to save a report to a folder, you need WMM for the folder. To remove a report from a folder, you need WMM for the folder (and WM for the report). To enable someone to interact with a folder's contents but with not the folder itself, grant WMM and deny WM.1
CheckInMetadata (CM)	Check in and check out items in a change-managed area. Applicable only in SAS Data Integration Studio.2
Read (R)	Read data. For example, while you need RM for a cube in order to see a cube, you need R for that cube in order to run a query against it. Enforced for OLAP data, information maps, data that is accessed through the metadata LIBNAME engine, and dashboard objects.
Write (W)	Update data. For example, on a table, W controls updating the rows in the table. Enforced for data that is accessed through the metadata LIBNAME engine, for publishing channels, and for dashboard objects.
Create (C)	Add data. For example, on a table, C controls adding rows to the table. Enforced for data that is accessed through the metadata LIBNAME engine.
Delete (D)	Delete data. For example, D on a library controls the deletion of tables from the library. Enforced for data that is accessed through the metadata LIBNAME engine and for dashboard objects.
Administer (A)	Operate (monitor, stop, pause, resume, refresh, or quiesce) servers and spawners. For the metadata server, the availability of similar tasks is managed by the Metadata Server: Operation role (not by this permission).
1A folder's WMM settings mirror its WM settings unless the folder has explicit or ACT (green) settings of WMM. A grant (or deny) of WMM on a folder becomes an inherited grant (or deny) of WM on the items and subfolders within that folder. WMM is not inherited from one folder to another. WMM is not applicable to specialized folders (such as virtual folders, favorites folders, or search folders).
2For any change-managed areas or resources, change-managed users should have CM (instead of WM or WMM). Change management is a SAS Data Integration Studio feature.

Note: For information about the Insert, Update, Select, Create Table, Drop Table, and Alter Table permissions, and an additional use of the Delete permission, see the SAS Guide to Metadata-Bound Libraries.