About Metadata Administration :: SAS(R) Environment Manager 2.5 Administration: User's Guide

About Access Management

You can use SAS Environment Manager to manage access in the metadata authorization layer. The access control tasks that are provided by SAS Environment Manager include:

application of access control templates (ACTs) to objects
maintenance of ACTs
application of explicit controls to objects
management of repository-level controls

Over the lifecycle of SAS 9.4, functions will be added to extend SAS Environment Manager's capabilities as a centralized administration application for all SAS products. SAS Environment Manager is not currently a replacement for SAS Management Console, and no functionality has been removed from SAS Management Console.

The following topics provide a brief overview of the metadata authorization model. For a comprehensive discussion, see the SAS Intelligence Platform: Security Administration Guide.

Access management determines which objects a user can see and interact with. Permissions that you set on the Authorization page are part of a metadata-based access control system within the SAS Metadata Server.

The SAS metadata authorization layer supplements protections in other layers (such as the operating system, a third-party DBMS, or the SAS Content Server). Protections are cumulative across layers. You cannot perform a task unless you have sufficient access in all layers.

CAUTION:

Do not rely exclusively on the metadata authorization layer to protect data.

You must manage physical access (operating system and DBMS permissions) in addition to metadata layer access.

About ACTs

Why Use ACTs?

Use ACTs to avoid having to repeatedly add the same explicit controls for the same identities on multiple objects. When you apply an ACT to an object, the pattern settings in an ACT are added to the direct controls of an object.

Tip

Settings in the pattern of an ACT affect access to all of the objects to which the ACT is applied. Settings on the Authorization page for an ACT affect who can access that ACT.

Why Create Custom ACTs?

Several predefined ACTs are provided. To further centralize access management, create an ACT for each access pattern that you use repeatedly. Here are some common patterns and tips:

It is often useful to create ACTs to manage Read access for different business units.
It is often useful to create an ACT that manages Write access for a functional group that includes users from multiple business units.
You do not have to capture all of an object's protections in one ACT. You can use combinations of ACTs, explicit controls, and inherited settings to define access to an object.

About Granularity and Mechanics

Repository-Level Controls

Repository-level controls function as a gateway. Participating users need ReadMetadata and WriteMetadata permissions for the foundation repository.

Repository-level controls also serve as a parent of last resort, defining access to any objects that do not have more specific settings. Repository-level controls are displayed on the ACT: Pattern page of the repository access control template (Default ACT).

Why Adjust the Repository-Level Controls?

CAUTION:

Altering the repository-level controls for service identities can prevent necessary access.

We recommend that you do not change these settings.

Here are some key points about working with repository-level controls for a foundation repository:

If you want some or all users to have default Read access to all data, grant the Read permission at the repository level.
If you want to experiment with changing repository-level access, we recommend that you create a new ACT and designate that ACT as the repository ACT (instead of modifying the original repository ACT).
All users need ReadMetadata and WriteMetadata access to the foundation repository. It is appropriate for the SASUSERS group to be granted these permissions in the pattern of the repository ACT.

Which ACT is the Repository ACT?

If your site has multiple metadata repositories, you have multiple repository ACTs. Each repository has its own repository ACT, which is usually named Default ACT.

As an alternative to opening each ACT to determine which repository it belongs to, navigate to the ACT from within the Folders module.

ACTs for the foundation repository are located in the SAS FoldersSystemSecurityAccess Control Templates folder.
ACTs for a custom repository are located in the SAS Folderscustom-repositorySystemSecurityAccess Control Templates folder.

Note: The repository ACT indictor is located at the bottom of the ACT: Usage page for access-control-template.

Object-Level Controls

Object-level controls manage access to a specific object such as a report, an information map, a stored process, a table, a cube, or a folder. You can define object-level controls individually (as explicit controls) and in patterns (as directly applied access control templates).

Fine-Grained Controls

Fine-grained controls affect access to subsets of data within an object. 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 the roles of each user in order to determine which menu items and features to display for that user. Roles management is part of user administration.

About Inheritance and Precedence

Two Relationship Networks

Permissions are conveyed across two distinct relationship networks—a resource network and an identity network. Permissions that are set directly on an object always have priority over permissions that are set on the parent of an object. For example, when access to a report is evaluated, a denial that is set on the report (and explicitly assigned to the PUBLIC group) overrides a grant that is set on the parent folder of the report (even if the grant is explicitly assigned to you).

The Resource Relationships Network

Permissions that you set on one object can affect access to many other objects. For example, a report inherits permissions from the folder in which the report is located. This relationship network consists primarily of the SAS Folders tree. This list highlights some exceptions:

The root folder is not the ultimate parent. This folder inherits from the repository (through the permission pattern of the repository access control template (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 object to have more than one immediate parent. If there is a tie in this network (for example, if there are no settings on an object, the object has two immediate parents, and one parent provides a grant while the other parent provides a denial), the outcome is a grant. If there are no direct controls, a grant from any inheritance path is sufficient to provide access.
In general, specialized folders (such as search folders, favorites folders, and virtual folders) do not 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 access for 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 an explicit grant and another group an explicit denial), the outcome is a denial.

About Use and Enforcement of Each Permission

Permission Reference
Permission (Abbreviation)	Actions Affected and Limitations on Enforcement
ReadMetadata (RM)	View an object. 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 object. 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 parent folder of the report). WM can also affect the ability to create associations. For example, you need WM on an application server in order to associate a library with that server. WM affects the ability to create objects in certain containers. For example, to add an object anywhere in a repository, you need WM at the repository level. For folders, adding and deleting child objects is controlled by WMM, not WM.
WriteMemberMetadata (WMM)	Add an object to a folder or delete an object 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 the contents of a folder, but with not the folder itself, grant WMM and deny WM.1
CheckInMetadata (CM)	Check in and check out objects in a change-managed area. Change management is an optional feature that is supported by only SAS Data Integration Studio.2
Administer (A)	Monitor, stop, pause, resume, refresh, or quiesce a server or spawner. For the metadata server, the ability to perform tasks other than monitoring is managed by the Metadata Server: Operation role (not by this permission).
Read (R)	Read data. For example, you need RM for a cube in order to see the cube, and you need R for the 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.
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.
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.
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.
ManageMemberMetadata (MMM)	Change the membership of the Group and Role. Cannot change security or other account attributes
ManageCredentialsMetadata (MCM)	Manage accounts and trusted logins of User and Group. Cannot change security or other account attributes.
1A folder's WMM settings mirror its WM settings unless the folder has a direct control for WMM. A grant (or deny) of WMM on a folder becomes an inherited grant (or deny) of WM on the objects 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).
2In any change-managed areas of a foundation repository, change-managed users should have CM (instead of WM and WMM).

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.

Note: For further information, see SAS Intelligence Platform: Security Administration Guide.

About Permission Conditions

What is a Permission Condition?

A permission condition limits an explicit grant of the Read permission so that different users access different subsets of data.

About the Permissions Inspector

The permissions inspector enables you to easily and safely look up effective permissions for any user or group.

To launch the inspector, click permissions inspector

.

The inspector offers the following features:

The inspector shows the effective permissions that a selected identity has for the specified object. Permissions information is displayed after you look up and select an identity.
The contents are also updated when you look up and select a different identity (in the text box within the inspector).
The inspector uses the same icons and indicators that are used on the Authorization page.
You can view permission origin information by clicking the grant or deny icon.

Here are some tips for using the inspector:

The inspector is always read-only. To set permissions, open the target object and use its authorization tabs.
To select an identity, enter a user or group name in the text box. The search is against display name (or, for an identity that does not have a display name, name). The search uses the "contains" criteria — so that you can provide any part of the name.
Conditional grants are indicated in the inspector, but you cannot access the associated permission conditions from the inspector. Use the Authorization page to view or update a permission condition. Permission conditions can be applied to both LASR tables and secured tables.
One inspector window can be open for each object.
The inspector does not reflect unsaved changes.