Authorization Decisions

Access Control Evaluation Process

The relative precedence of each access control is based on where it set, who it is assigned to, and how it is set. The following list summarizes how the metadata server evaluates all relevant access controls to reach an authorization decision:

Direct controls (permissions that are set directly on the target object) are examined.
- Any conflicts that arise from group membership are resolved by the identity hierarchy. For example, an explicit control that is assigned to a user overrides a conflicting explicit control that is assigned to a group to which the user belongs.
- If there is a conflict between an explicit control and an ACT setting at the same level in the identity hierarchy, then the explicit control takes precedence.
- If there is a conflict between two explicit controls (or two ACT settings) at the same level in the identity precedence hierarchy, then the outcome is a denial.
- If one or more permission conditions have been defined, then the condition that is assigned at the highest level of identity precedence is applied. Other conditions that also apply to a user because of group memberships do not provide additional, cumulative access (unless there are multiple tied groups at the highest level of identity precedence).
- If there are no relevant direct controls, then the evaluation process continues.
The step 1 evaluation process is applied to the immediate parent of the target object. For example, the immediate parent of a report is its folder. If no direct controls are found, each successive parent object is examined in turn.

Note: In the unusual circumstance in which an object has more than one immediate parent, a grant from any inheritance path is sufficient to provide access.
If no direct controls are found on the object or on any of its parent objects, the permission pattern of the repository ACT (Default ACT) is examined. The repository ACT serves as the inheritance parent of last resort.
- If the repository ACT grants or denies the requested permission, then that grant or denial is determinative.
- If the repository ACT neither grants nor denies the permission, then the permission is denied.
- If there is no repository ACT, then the permission is granted. You should always have a designated repository ACT.

Precedence Principles and Examples

The following table summarizes the principles of the authorization decision process for a user (Joe) who is looking for an object (LibraryA or ObjectA):

Precedence Principles for Authorization

Principle	Example1	Outcome
Settings on an object have priority over settings on the object'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 object 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.2	Joe can see ObjectA.
1The settings described in this column are the only explicit or ACT settings for ReadMetadata permission on LibraryA (or ObjectA).
2Having more than one immediate parent is not a common circumstance.

Authorization Decisions

Access Control Evaluation Process

Precedence Principles and Examples

See Also