Authorization Model

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

[Authorization Decision Flowchart]

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

explicit settings

A user has an explicit [white check box] 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 check box] (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 [gray check box] 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 [gray check box] 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). [cautionend]

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. [cautionend]

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). 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:

Precedence Principles for Authorization
Principle	Example¹	Outcome
Settings on an item have priority over settings on the item's parents.	LibraryA has an explicit denial for PUBLIC. LibraryA's parent folder has an explicit grant for Joe.	Joe can't see LibraryA.
Conflicting settings on an item are resolved by identity precedence.	LibraryA has an explicit denial for GroupA and an explicit grant for GroupAA. Joe is a direct member of GroupA. GroupA is a direct member of GroupAA.	Joe can't see LibraryA.
In an identity precedence tie, explicit settings have priority over ACT settings.	LibraryA has an ACT denial for GroupA and an explicit grant for GroupB. Joe is a direct member of both GroupA and GroupB.	Joe can see LibraryA.
In an identity precedence tie that isn't resolved by the preceding row, the outcome is a denial.	LibraryA has an explicit denial for GroupA and an explicit grant for GroupB. Joe is a direct member of both GroupA and GroupB.	Joe can't see LibraryA.
A grant from any inheritance path can provide access.	ObjectA has no explicit or ACT settings, one immediate parent that conveys a grant, and another immediate parent that conveys a denial.²	Joe can see ObjectA.
1 The settings described in this column are the only explicit or ACT settings for ReadMetadata permission on LibraryA (or ObjectA). 2 Having more than one immediate parent is not a common circumstance.

	Inheritance Paths
	Identity Precedence
	Summary: Relative Precedence of Access Controls