The relationship between a principal (user, role or group) and the members of a dimension/group are classified into three groups:
A principal can have its own allowed/denied set and inherit the allowed/denied sets from its parent roles or groups. The parent allowed/denied sets will be calculated first and it is a recursive process.
The following are the detailed working logic:
Here is the priority order:
Denied Set > Allowed Set > Inherited Denied Set > Inherited Allowed Set > Unspecified (no matter whether it is allowed or denied).
See the diagram below:
The final result of the members of a dimension/group that a principal is allowed to access will be:
({Allowed Set} - {Denied Set}) U
(({Inherited Allowed Set from parent 1} U {Inherited Allowed Set from parent 2} U ...) - ({Inherited Denied Set from parent 1} U {Inherited Denied Set from parent 2} U ...)) U
{Unspecified if allowed}
The final set of the unspecified will be:
{All} - ({Allowed Set} U {Denied Set} U {Inherited Allowed Set from parent 1} U {Inherited Denied Set from parent 1} U {Inherited Allowed Set from parent 2} U ...)
For a user, the member-level security in a business/report cube or business view would be like this:
{Accessible members of dimension/group1} And {Accessible members of dimension/group1} And...
Note: If all members are denied in one dimension/group regardless of whether it is set to a principal directly or to the parents indirectly, no data will be retrieved from this business/report cube or business view to the principal.
We will take some examples to further demontrate the relationship between a principal and the dimension/group members.
Example 1
Here we use a simple sample to describe a case when a user belongs to multiple roles.
Assume there is a dimension Order ID={1,2,3,4,5,6,7,8,9}, and we set member-level security on this dimension for a user (user1) and two roles (role1, role2) separately.
Belong to | Allowed Set | Denied Set | |
---|---|---|---|
user1 | role1, role2 | 1 | |
role1 | 2,3 | 4,5 | |
role2 | 3,4,5 | 1,2 |
The unspecified members will be {1,2,3,4,5,6,7,8,9} - ({1}U{2,3}U{4,5}U{3,4,5}U{1,2}) = {6,7,8,9}.
Assume we set the property "Allow Unspecified Members" to true, which means the unspecified members {6,7,8,9} are allowed to the user.
The final result that user1 can see when only this member-level security is taking effect will be:
{1} U ( ({2,3}U{3,4,5}) - ({4,5}U{1,2}) ) U {6,7,8,9}={1,3,6,7,8,9}
Example 2
This example is more complex. It contains four properties of the member-level security setting.
Assume there is a summary table with three groups and summary.
Region | Country | City | Summary (the count of Order_ID) |
---|---|---|---|
APAC | 41 | ||
Australia | 20 | ||
Sydney | 20 | ||
China | 21 | ||
Beijing | 9 | ||
Hongkong | 4 | ||
Shanghai | 8 |
And in below table, we list the member-level security setting in the left cells, and the final result a user will get are listed in the right cells.
Member-level security specified as below | User will get such result | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||
|
|