Role Based Access (RBAC)
Restricted and Unrestricted Datasets
For restricted datasets Role Based Access Control determines which data is provided by the [Reporting].[usp_GetDataSet]. Each row in result dataset is checked against 3 conditions, before access is permitted.
- Username
- Dataset Type
- Organization Unit
Data is provided only when execution meets all three conditions.
Some of the datasets are unrestricted, this means that they return data independent from the user permissions.
Dataset permission type
There are 3 reporting supervisor permission types, which user may be assigned per the Organization Unit. This permission types correspond to dataset permission types.
Dataset Permission Type | Description |
---|---|
Agent | Permission to see data using Agent datasets, filtered by the agent organization unit |
Service | Permission to see Service datasets, filtered by the Service organization unit |
Customer | Permission to see Customer datasets, filtered by the Service organization unit |
Username
For restricted datasets on [Reporting].[usp_GetDataSet] execution login is extracted from a SQL Server connection. In order to get data, this login must match one of the supervisors, with reporting permissions. A match considers one of two fields: Username or User Principal Name.
- In case an extracted login is a SQL account (without domain) it will be matched to part before @ of Username
- In case an extracted login is a windows account (with domain) it will be matched to complete User Principal Name.
“Available” organization units list is created at the beginning of the dataset execution and applied to all reporting data. Only permitted rows are returned into result dataset.
Organization Unit Binding
Organization Units (OU) are a hierarchy which describe a company structure. Each row of restricted dataset is bound with one Organization unit, this OU is considered on RBAC filtering. Deleted dimension members persistently stay with the OU, assigned during delete.
Acted principal OU binding
Organization unit may be assigned to dataset member through acted principal: Service or Agent. In that case Service or Agent organization unit is considered for RBAC filtering.
There are two approaches for acted principal OU binding in case principal OU is changed:
- Current OU – consider OU, assigned to the principal on report runtime.
- Historical OU – consider OU, assigned to the principal on the time of reported event.
Some of the datasets consider current OU approach, other datasets consider historical OU approach.
- The "Current" OU approach is working for all dimension datasets and Service Task fact datasets.
- The "Historical" approach is working for Agent Task and Agent State fact datasets.
Direct / Indirect OU binding
Direct OU is assigned to the entity in the configuration.
Indirect OU is different from directly assigned to the entity in the configuration, but is associated with it by one of the rules. When indirect OU binding is applied, additional dataset rows may be shown to user, despite the fact that user has no permission on the directly assigned OU.
Parent OU access (version 3.3.1 and newer)
The idea of Parent OU access is that some entities may be owned by parent OU but used by child OU principals. For example:
- Task Completion Code (TCC)
- Cross Selling code(CSC)
- Not Ready Reason (NRR)
- Survey Question (SQ)
For such datasets members are provided by [Reporting].[usp_GetDataSet] despite user has not permitted to see directly assigned OU. User see Dimension members from OU's up by hierarchy from OU's that user has access.
An Example OU structure with Task Completion Codes:
Company (TCC1)
Europe (TCC2) < - Supervisor EU
Sales EU
USA (TCC 3) < - Supervisor US
Sales US
Results:
- Both Supervisor 1 and Supervisor 2 will get “TCC1”
- TCC2 is shown only to Supervisor EU
- TCC3 is shown only to supervisor US
Deleted children OU access
If organization unit is deleted there is no longer possibility grant permission from configuration. However dataset members, bound to deleted OUs are provided by Reporting].[usp_GetDataSet] to users with permissions on not deleted parent OU.
For Example:
Company (TCC1)
Europe (TCC2) < - Supervisor EU
Sales EU * - DELETED
USA (TCC 3) < - Supervisor US
Sales US
Result:
Sales EU is deleted, but it will be shown to Supervisor EU.
Secondary UPN
Secondary UPN allows to configure an additional login for PowerBI Server/PowerBI.com for users that do not have appropriate reporting supervisor permission types.
In case when users’ E-Mail or Primary UPN is not matching the required login, they can be added as Secondary UPN to a user with configured supervisor permission types and recorded in etl.[RlsSupervisorEmail].
In this case the user takes over the supervisor’s rights.
The system is not supported a case when two supervisors have each other’s Primary UPN configured as Secondary UPN.