When an authorization decision is
made, a permission condition is applied only if it is on the explicit
control that is closest to the requesting user. Other conditions
that are relevant because of further-removed group memberships don't
provide additional, cumulative access.
If
there is an identity precedence tie between multiple groups at the
highest level of identity precedence, those tied conditions are combined
in a Boolean OR expression (any row that meets either condition is
returned). If the identity precedence tie includes an unconditional
grant, access is not limited by any conditions.
The following table
provides examples:
Precedence for Permission Conditions
|
|
|
If there are multiple
permission conditions that apply to a user because of the user's group
memberships, then the highest precedence identity controls the outcome.
|
A filter on InformationMapA
limits Read permission for GroupA.
Another filter on InformationMapA
limits Read permission for the SASUSERS group.
The user is a member
of both GroupA and SASUSERS.
|
The user can see only
the rows that GroupA is permitted to see. GroupA has higher identity
precedence than SASUSERS, so the filters that are assigned to GroupA
define the user's access.
|
If there are multiple
permission conditions at the highest level of identity precedence,
then any data that is allowed by any of the tied conditions is returned.
|
A filter on InformationMapA
limits Read permission for GroupA.
Another filter on InformationMapA
limits Read permission for GroupB.
The user is a direct
member of both GroupA and GroupB.
|
The user can see any
row that is permitted for either GroupA or GroupB.
|
If there is a permission
condition and an (unconditional) explicit grant at the highest level
of identity precedence, then all data is returned.
|
A filter on InformationMapA
limits Read permission for GroupA.
An explicit grant on
InformationMapA grants Read permission (unconditionally) for GroupB.
The user is a direct
member of both GroupA and GroupB.
|
The user can see all
rows.
|
The following example describes the
impact of identity precedence when a manager uses an information map
that includes both of the following filters for a SALARY table:
-
A permission condition that is
assigned to the SASUSERS group gives each user access to his or her
own salary information.
-
A permission condition that is
assigned to a Managers group enables each manager to see the salaries
of the employees that he or she manages.
When the manager accesses
the SALARY table, the filter that is assigned to the Managers group
is applied and the filter that is assigned to SASUSERS is ignored.
This is because the manager's direct membership in the Managers group
has higher identity precedence than the manager's implicit membership
in the SASUSERS group. To avoid a situation in which managers can
see their employees' salaries but each manager can't see his or her
own salary, you can use either of these approaches:
-
Assign the filters to two groups
that have the same identity precedence. For example, if you assign
the first filter to a general purpose user-defined group (rather than
to SASUSERS), and you make each manager a direct member of that group,
then managers will have an identity precedence tie between that group
and the Managers group. This situation causes the two filters to be
combined for members of the Managers group, enabling those users to
see any row that is permitted by either filter.
-
Define the Managers filter in a
way that encompasses all of the rows that the managers should be able
to see. In other words, combine (OR together) the SASUSERS filter
and the Managers filter.