Authorization Decisions

The following figure depicts the evaluation process that determines whether a restricted user (Joe) has a particular permission for a particular item.

Authorization Decision Flowchart

Here are some details that help you interpret the preceding figure:

explicit settings

A user has an explicit setting on an item if the user is individually granted or denied a permission on the item's Authorization tab. Explicit settings have the highest precedence. However, managing a large number of explicit settings for individual users can be cumbersome. For greater efficiency, we recommend that you set explicit permissions for groups, use ACTs, and rely on inheritance.

ACT settings

A user has an ACT setting (green) on an item if an ACT that is applied to the item has a permission pattern that explicitly grants or denies the relevant permission to the user. Each ACT adds its pattern of grants and denials to the settings for each item to which the ACT is applied. A green check box on an item's Authorization tab indicates that at least one ACT is applied to that item. To determine which ACTs are applied to an item, click the Access Control Templates button on the item's Authorization tab.

indirect settings (derived from group memberships)

A user has a group setting on an item if a group to which the user belongs has an explicit or ACT setting on the item. Group settings matter only if the requesting user has no relevant explicit or ACT settings on the target item. Identity precedence determines which group settings are closest to each user. See Identity Precedence.

If you directly assign a user to multiple groups (or directly assign a group to multiple groups), you can get identity precedence ties. For example, if Joe is a direct member of GroupA and GroupB, and the only settings on an item are conflicting explicit settings for those groups, both of those settings are closest to Joe. These conflicts are resolved as follows:

• Explicit settings have precedence over ACT settings.

• Conflicting explicit settings result in a denial.

• Conflicting ACT settings result in a denial.

indirect settings (inherited from a parent item)

Inherited settings come from a parent item (such as a folder). Inherited settings matter only if there are no relevant explicit, ACT, or group settings on the target item. When there are no relevant settings on an item, access to the item is the same as access to the item's immediate parent. The controlling setting is usually an explicit or ACT setting that is defined somewhere in the item's inheritance path.

If there are no explicit or ACT settings on any parent (or if the item's only parent is the repository), the repository ACT determines the outcome. If that ACT's pattern neither grants nor denies the permission, then the permission is denied.

Note:   If there is no repository ACT, all permissions are granted (you should always have a designated repository ACT).  

Note:   If an item has more than one immediate parent, a grant from any inheritance path is sufficient to provide access. Having multiple immediate parents is not a common situation.  

permission conditions

Permission conditions constrain explicit grants of the Read permission on OLAP dimensions (limiting access to members) or information maps (limiting access to rows). If you are using the table server, a permission condition on a table constrains explicit grants of the Select permission (limiting access to rows). On the Authorization tab, the presence of an Edit Condition or Edit Authorization button indicates that a permission condition is assigned to the currently selected user or group. See Precedence for Permission Conditions.

The following table summarizes the principles of the authorization decision process:

See Also

Copyright © 2009 by SAS Institute Inc., Cary, NC, USA. All rights reserved.