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.

(info) 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:

  1. Task Completion Code (TCC)
  2. Cross Selling code(CSC)
  3. Not Ready Reason (NRR)
  4. 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.

(info) The system is not supported a case when two supervisors have each other’s Primary UPN configured as Secondary UPN.