Previous Page | Next Page

Users, Groups, and Roles

Identity Precedence

Identity precedence affects authorization decisions when a user has more than one relevant permission setting because of the user's group memberships. Identity precedence affects login priority when someone has more than one login in an authentication domain. Identity precedence is not relevant for roles.

This is the precedence ranking for users and groups:

  1. the user's individual identity, based on the user's authenticated ID.

  2. a user-defined group that has user as a member. This is a first-level group membership for the user.

  3. a user-defined group that has another user group as a member. For example, assume that the user belongs to a group named ETL_Advanced, and that group is a member of another group called ETL_Basic. In that case, the ETL_Basic group is a second-level group for that user. If you have additional levels of nesting, each successive level has less precedence.

  4. the SASUSERS implicit group, which includes everyone who has an individual identity.

  5. the PUBLIC implicit group, which includes everyone who can access the metadata server (regardless of whether they have an individual identity or not).

The examples in the following table illustrate the hierarchy:

Examples of Identity Hierarchies
User Information User's Identity Hierarchy
User has no individual identity. Primary identity: PUBLIC
User has an identity and no explicit group memberships. Primary identity: self

First-level memberships: SASUSERS

Second-level memberships: PUBLIC

User is a direct member of two user-defined groups (GroupA and GroupB), and one of those groups is a member of a third group (GroupA is a member of the Report Users group). Primary identity: self

First-level memberships: GroupA, GroupB

Second-level memberships: Report Users

Third-level memberships: SASUSERS

Fourth-level memberships: PUBLIC

The following figure illustrates the examples from the preceding table:

Examples of Identity Hierarchies

[Examples of Identity Hierarchies]

Note:   To avoid introducing unnecessary complexity, don't make PUBLIC or SASUSERS a member of another group. For example, if you make PUBLIC a member of GroupA, then a user who is an indirect member of GroupA (through his automatic membership in PUBLIC) has GroupA as his lowest precedence membership. This contradicts the usual expectation that every user's lowest precedence membership is PUBLIC. This is not an issue for roles.  [cautionend]

See Also

Inheritance Paths

Authorization Decisions

Previous Page | Next Page | Top of Page