The identity hierarchy can affect authorization decisions
and login priority (in credential retrieval from the SAS metadata).
The identity hierarchy is not relevant for roles.
The identity hierarchy
establishes the following precedence ranking:
-
the user's individual identity, based on the user's
authenticated ID.
-
a group that has the user as a direct member. This
is a first-level group membership for the user.
-
a group that has another user group as a direct 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.
-
the SASUSERS implicit group, which includes everyone
who has an individual identity.
-
the PUBLIC implicit group, which includes everyone
who can access the metadata server (regardless of whether they have
an individual identity or not).
The following table
provides examples of the hierarchy:
Examples of Identity Hierarchies
|
|
User's Identity Hierarchy
|
User has no individual
identity.
|
|
User has an identity
and no explicit group memberships.
|
First-level memberships:
SASUSERS
Second-level memberships:
PUBLIC
|
User is a direct member
of GroupA and GroupB.
GroupA is a member of
the Report Users group.
|
First-level memberships:
GroupA, GroupB
Second-level memberships:
Report Users
Third-level memberships:
SASUSERS
Fourth-level memberships:
PUBLIC
|
Tip
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. It is not a problem for PUBLIC or SASUSERS to be a member
of a role.