Model roles
Semantic layer security
Semantic layer security is managed using model roles, which are defined as part of a data model and included in the Semantic layer when the model is processed.
A default model role, Application Users, is always included to guarantee that, by default, any user who can modify the data model can also view the associated Semantic Layer.
Use model roles to manage security
Once model roles using the appropriate groups are created in Data Hub, administrators need only manage the membership of the groups in the source system to control access to the Semantic Layer. The members of the groups in the Semantic Layer are then updated by Data Hub each time the data model is processed. A typical security regime may be achievable using five to ten roles.
Model roles are easily created and managed as part of a model. Each model role provides a defined level of access to the Semantic layer for a defined group of users. They consist of three parts:
Name: (and an optional description).
Role members: Role members may be a user, an Active Directory security group, a group in a source system, such as AX or CRM, or a Data Hub user via Active Directory, Azure AD, or ADFS authentication.
An All option is also provided to allow all users with access to Data Hub to access the Semantic Layer.
Permissions: Two types are available:
Permissions by Schema: permissions can be allowed or restricted by modules and pipelines.
Limitation of Data: For Dimensional Modeling only data can be limited by dimensions and measures.
An All option is also provided to allow access to the entire Semantic Layer.
Note
Data Hub model roles result in connections to SSAS using a role rather than a user ‒ meaning all SSAS cube roles are ignored. If you have built your own custom security roles in SSAS and want to use them instead of Data Hub model roles, you must delete all Data Hub model roles from your model.
Once this is done, Data Hub will connect to SSAS as a user, allowing SSAS cube roles to function normally.
Data Hub Users model role
The Data Hub Users model role is automatically created in all models created in Data Hub.
This model role is included to guarantee that, by default, any user who can modify the data model can also view the associated cube created from the model. Without this role, only administrators on the SSAS instance could view the corresponding cube.
The Data Hub Users model role is created with the Users with Access to Model group from the Data Hub Groups provider. This group allows all users who can view the data model to also view the cube. To view the model, users need the Administrator or Model Designer resource security role in Data Hub.
The model must also be in a folder that is accessible to the user. For example, a model designer user will not be able to view a model in another user's personal folder, and therefore will not be able to view the cube created from it.
A second group, All users for organization, is provided to give even wider access to a cube. It gives cube access to all users in the organization under which the model was created, regardless of user type, and whether or not they have access to the model itself.
This role's permissions are set so that there are no data limitations, therefore, it is all able to be viewed by users who have access to the cube.
Data Hub Users model role may be suitable for: a simple personal BI cube; one that is used by a single user; or a cube where security is not an issue.
For cubes created from Dynamics products or cubes that are used by many users, the Data Hub Users role can be replaced by multiple roles (that are tailored to the needs of the various users of the cube).
Set model role permissions
A model role PERMISSIONS subtab allows the use of permissions to control data available to model role members. You can specify individual modules or pipelines within the model role (using the Allow Schema area).
Once specified, only the data in these modules and pipelines will appear to users in the model role.
You can limit the available data based on specific dimensions, members, and named sets (using the Limit Data area).
Once these permissions are defined, the Dimension Tree for users/groups assigned to the model role is automatically filtered to only display the selected data.
View individual model role members and permissions
To view an existing model's role settings, click it on the model tab Roles list. When a model role is clicked, individual role information is displayed in a separate tab.
This tab displays the following information:
Role name and description.
MEMBERS subtab.
The currently selected users or groups appear in the Role Members list.
The Users with access-list shows the full list of users assigned to the role, including both individual users as well as all users in any selected group.
PERMISSIONS subtab
Allow Schema area. Displays both modules and individual (additional) pipelines that are accessible to assigned members of the current role.
Limit Data area. Displays any specified filtering within dimensions, and allows you to determine what is included in the Dimension Tree for the members assigned to this role.
Allow full access to the model role
To allow full access to users assigned to the current role, use the All check box in the Allow Schema area of the PERMISSIONS subtab.
Excluded model role permission Items
Once you add modules or pipelines to your model role, you can limit the data available from those specified items on a dimension-by-dimension basis by specifying a member or a named set. This is done using the Limit Data area on a model role's PERMISSIONS subtab.
Dynamic security
Process and implementation
Dynamic cube security streamlines the process of providing user-specific cube security. It is implemented by incorporating the new Current User Member function into a named set, which is added to a model role. The Current User Member function automatically matches the currently logged-on user's identity to an entry in a pipeline within the model, which may then be used to filter other pipelines as needed.
Prerequisites
For dynamic cube security to work, the following prerequisites must be in place:
A pipeline in the data model must contain each user whose access you wish to control. Users may be identified by email address (for example john@contoso.com), canonical name (for example contoso\john), or display name (for example John Muir).
A relationship must exist between the pipeline containing the users and any information you want to filter by user. This may be:
A direct relationship (e.g. example, having a userID column in the Sales pipeline).
An Indirect relationship. (e.g. including a BusinessUnitID column in the Users pipeline that maps users to business units, and also including the BusinessUnitID column in the Sales pipeline to allocate each sale to a business unit.
In the second case, dynamic cube security ensures each user only sees the sales for their business unit.
Note
In a complex cube, significant structural changes may be needed to provide a relationship between the Users pipeline and other pipelines that you wish to be filtered by the user.
Use the Run As feature to test cube security
You can use the Run As feature to test the cube security settings for a specific user. This feature allows you to temporarily view analyses, dashboards, and other resources populated with exactly the cube data that the selected user has access to.
The dimension tree is also filtered to display just the measures and dimensions from the cube that the user is permitted to access.
The feature is available from the Settings tab.
Note
This feature simulates cube security for the specified user. It does not simulate resource security (i.e. resources the user has access to).
Resource security settings may be verified as follows:
To verify who can see a given resource, view the Users with Access list on the resource's Properties page.
To view a given user's home folder, enable Show personal folders, then navigate to the user's folder under the Personal folder in the Resource Explorer.
To test what a given user will see when they log in, either log in as the user in a separate browser instance or have the user themselves log in and verify their access directly. If best practice is followed and role-based access control (AGDLP) is used, only one user in a group with the same privileges needs to be checked.
Important
You must be an administrator to access this feature.