Permission logic

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
Dimension Allowed Set Denied Set Allow Unspecified Members
Region <empty> <empty> True
Country <empty> {China} True
City <empty> <empty> True
Region Country City Summary (count Order_ID)
APAC 20
Australia 20
Sydney 20
Dimension Allowed Set Denied Set Allow Unspecified Members
Region <empty> <empty> True
Country {China} <empty> False
City <empty> {Beijing,Shanghai} True
Region Country City Summary (count Order_ID)
APAC 4
China 4
Hongkong 4
Dimension Allowed Set Denied Set Allow Unspecified Members
Region <empty> <empty> True
Country {China} <empty> False
City <empty> {Beijing,Shanghai} False
Region Country City Summary (count Order_ID)
0