Examining Permissions

You can not 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 Item?

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 item'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 item inherits from a parent item
an applied ACT's Permission Pattern tab
an explicit setting on this item

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 the 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 item. 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)1	Explicit	The permission is set on the current item 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 item or the repository ACT).2
1Explicit controls are usually white because the background color for the permissions list box is usually white.
2 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 item's Authorization tab provides access to the item's Explore Authorizations tab. On the Explore Authorizations tab, you can add any user or group and view their permissions for the current item. 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 Item?

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

The Inheritance tab displays a tree of items, organized by their security relationships. The first item in the tree is always the current item. If the current item 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 item that you are interested in. On the Inheritance tab, you begin with the item that you are interested in and expand nodes to move up that item'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 item itself is listed.
Each BI content item (such as a report, information map, folder, or stored process) inherits from one immediate parent. On the Inheritance tab for each of these items, there is one expandable node immediately below the item.