Examining Permissions

You cannot view someone's permissions by looking at their user definition. To view someone’s permissions, navigate instead to an object or container that you are interested in, open the Properties dialog box, and select the Authorization tab.

How to Interpret the Authorization Tab

The List of Names

The List of Permissions

How to Check the Permissions of an Unlisted User

Basic Technique

Advanced Technique

Which Items are Parents to This Object?

How to Interpret the Authorization Tab

The List of Names

The Users and Groups list box includes only those users and groups who participate in the current object's settings. An identity participates if they are included in any of these places:

the repository ACT's Permission Pattern tab
a setting that this object inherits from a parent object
an applied ACT's Permission Pattern tab
an explicit setting on the object

Note: You cannot remove identities that participate through the repository ACT, an applied ACT, or an inherited setting.

Any restricted user who is not listed has the access of their closest listed group. For each unlisted user, group memberships and identity precedence determine which listed group is closest. For example, the closest listed group for an administrator might be SAS Administrators, and the closest listed group for a regular user might be SASUSERS. For a full discussion of identity precedence, see SAS Intelligence Platform: Security Administration Guide.

The List of Permissions

The Effective Permissions list box displays the metadata layer access that the selected user or group has to the current object. Effective permissions are a calculation of the net effect of all applicable permission settings. Effective permissions do not reflect role-based constraints or access controlled in other layers such as the operating system.

This table explains the significance of the check box colors:

Significance of Color in the Permissions List
Color	Term	Significance
(clear)	Explicit	The permission is set on the current object and assigned to the selected identity.
(green)	ACT	The permission comes from an applied ACT whose pattern explicitly assigns the grant or denial to the selected identity.
(gray)	Indirect	The permission comes from someone else (the unrestricted role or a group that has an explicit or ACT setting) or somewhere else (a parent object or the repository ACT).1
1 For the WriteMemberMetadata permission, gray means that the setting either mirrors the setting for the WriteMetadata permission or is derived from group settings.

How to Check the Permissions of an Unlisted User

Basic Technique

Click Add and temporarily add the user to the Authorization tab.

Note: Each restricted identity that you add gets an explicit clear check box

grant of the ReadMetadata permission. If you remove the user from the Users and Groups list box, the automatically created explicit grant of ReadMetadata is deleted.

Advanced Technique

If you are unrestricted, an Advanced button on each object's Authorization tab provides access to the object's Explore Authorizations tab. On the Explore Authorizations tab, you can add any user or group and view their permissions for the current object. You cannot change settings on the Explore Authorizations tab. It is not necessary to remove identities from this tab. This tab is for investigation only.

Note: Both the Authorization tab and the advanced Explore Authorizations tab always display effective permissions.

Which Items are Parents to This Object?

If you are unrestricted, an Advanced button on each object's Authorization tab provides access to the Inheritance tab. On this tab, you can trace the current object's parents.

The Inheritance tab displays a tree of items, organized by their security relationships. The first object in the tree is always the current object. If the current object has an immediate parent other than the repository ACT, you can expand the first node in the tree to see those parents. You can continue expanding nodes to further trace the inheritance. The repository-level parent (the repository ACT) is not displayed in the tree.

Tip

When you move from the Folders tab to the Inheritance tab, there is a shift in orientation. On the Folders tab, you expand parent nodes in order to get to an object that you are interested in. On the Inheritance tab, you begin with the object that you are interested in and expand nodes to move up that object's inheritance path.

These examples describe how the Inheritance tab displays inheritance paths:

Each user, group, role, ACT, and application server inherits only from the repository ACT. On the Inheritance tab for any of these items, only the object itself is listed.
Each report inherits from one immediate parent. On the Inheritance tab for a report, there is one expandable node immediately below the report.