Basics of Metadata Authorization :: SAS(R) 9.3 Intelligence Platform: Security Administration Guide

Where Permissions Are Set

Effective access to an object is displayed in the authorization properties section of the object's metadata definition. You can set permissions on individual content objects (such as reports) and on containers (such as folders). For simplicity, try to set permissions on containers, instead of on individual content objects, whenever possible.

Tip

The metadata authorization model is object-centric, not identity-centric. To examine a user's permissions, do not begin by finding their user definition. Instead, begin by navigating to the object that you want to examine.

Who Permissions Are Assigned To

You can assign permissions to individual users and to groups. For simplicity, try to avoid assigning permissions to individual users.

The main authorization list includes only those users and groups that participate in access controls that could affect the object. The list usually includes at least the following groups:

PUBLIC

automatically includes everyone who can access the metadata server.

SASUSERS

automatically includes everyone who is registered in the metadata (SASUSERS is a subset of PUBLIC).

SAS Administrators

should include only metadata administrators that require broad access.

SAS System Services

should include only the service identity (or, identities) that require broad access.

Anyone who isn't listed in the basic authorization properties display has the access of their closest listed group, as determined by group memberships and identity precedence. Here are some examples:

The closest (and only) listed group for an unregistered user is PUBLIC.
The closest listed group for a registered user is often SASUSERS.
The closest listed group for an administrator is usually SAS Administrators.

How Permissions Are Set

Use a combination of the following techniques to manage access:

direct controls

You can assign grants and denials directly on a target object. There are two types of direct controls:

explicit controls

are individual grants and denials.

access control template (ACT) controls

are grants and denials within a predefined pattern.

Tip

For simplicity, try to avoid setting unnecessary (redundant) direct controls.

object inheritance

You can assign grants and denials on a parent object, and rely on inherited settings to protect each child object. For example, a report inherits effective permissions from its parent folder. In the metadata layer, access control inheritance happens automatically and can't be turned off. All objects have inherited settings. Most objects have inherited settings only.

The following table summarizes the three types of access controls:

Direct Access Controls and Indirect Settings

Term	Significance
Direct control: explicit	An access control is explicit for a particular identity if the control is set directly on the target object and assigned directly to that identity. For example, if an individual access control on ReportA grants the ReadMetadata permission to UserA, then we say that UserA has a direct control on ReportA (specifically, an explicit grant of the ReadMetadata permission). Explicit controls are sometimes referred to as ACEs (access control entries).
Direct control: ACT	An access control is a direct ACT control for an identity if the control comes from an ACT that is directly applied to the target object, with a pattern that directly assigns a grant or denial to that identity. For example, if the DemoACT is directly applied to FolderA, and the DemoACT’s permission pattern explicitly grants the ReadMetadata permission to GroupA, then we say that GroupA has a direct control on FolderA (specifically, an ACT-based grant of the ReadMetadata permission).
Indirect setting	An indirect setting comes from someone else (a group that has an explicit or ACT setting), from somewhere else (a parent object, the repository ACT), or from a special status (such as unrestricted). For the WriteMemberMetadata permission, indirect means that the setting mirrors the WriteMetadata setting. Note: The authorization model includes two distinct relationship networks: object inheritance (for example, a folder and its contents) and identity precedence (for example, a group and its members). A setting that is derived through either of these hierarchies is called an indirect setting.

How Permissions Differ from Capabilities

Having a certain capability is not an alternative to meeting permission requirements. Permission requirements and capability requirements are cumulative. For example, even if you are in the Enterprise Guide: OLAP role, you can't access data in a cube for which you don't have the Read and ReadMetadata permissions.

Use roles and permissions in conjunction with one another. You can use permissions to constrain the scope of a role. For example, to allow someone to create reports but add them to only one folder, give the person the Web Report Studio: Report Creation role, but grant them the WriteMemberMetadata permission on only that one folder.