Introduction
An application's users, roles, and groups can be members of one or more other roles and/or groups. Administrators can, therefore, nest groups and roles within each other so permissions and restrictions can be inherited and set in bulk.
This article covers:
- How memberships work.
- How security inheritance works.
- Inheriting data permissions.
- Inheriting page restrictions.
- Resources for further learning.
How memberships work
Before explaining how permissions and restrictions can be inherited through memberships, it's important to know how memberships themselves work.
The following memberships can exist:
- A user can be a member of one or more groups and roles.
- A group can be a member of one or more other groups and roles.
- A role can be a member of one or more other roles.
You can start to see how you can create membership hierarchies (e.g., roles as members of other roles) to pass down restrictions and permissions from the top down.
The Membership node has a Roles tab, where you can view where a role or group membership comes from by checking the values in the Inherit From column.
Tip: Refer to this article for further details on memberships.
How security inheritance works
A user’s, role's, or group's security configuration is the union of all their associated permissions and restrictions. These associated permissions and restrictions could have been assigned to the user themself or inherited from groups and roles they're a member of.
For example, let's take this scenario:
- A user is a member of role A.
- Role A is a member of role B.
The user would have its own permissions and restrictions AND the permissions and restrictions of role A and role B.
Tip: You cannot remove the assignment of the inherited role (A) from a user directly. It has to be removed from role (B).
Inheriting data permissions
To delve deeper into these concepts, let's look at an example of how security inheritance works when handling data permissions.
Consider a hypothetical case where two expense planning users need different permissions to read and write to the OPEX pages in an Integrated Financial Planning (IFP) app:
- An expense super planning user requires read/write permission to all of but only the Expense-Planning model.
- An expense USA planning user requires read/write permission to the United States dimension member in the Expense-Planning model.
Configurations
These are the users, roles, and their configurations that will be used in our examples in the following sections. Please refer back to these tables if necessary.
Tip: Users and roles can be a member of one or more other roles.
Users
| User | Member Of | Data Permissions |
|---|---|---|
| Kimberly Haze | Expense Planning Group |
Write permission to Expense-Planning model. Write permission to all members in the Entity dimension. |
| Albert Rivers | Expense USA |
Write permission to Expense-Planning model (inherited from Expense Planning Group). Write permission to United States member in the Entity dimension. |
Roles
| Role | Member Of | Data Permissions |
|---|---|---|
| Expense Planning Group | Write permission to Expense-Planning model. | |
| Expense USA | Expense Planning Group |
Write permission to Expense-Planning model (inherited from Expense Planning Group). Write permission to United States member in the Entity dimension. |
Note: Data permissions are configured at the role level.
Expense super planning user
An expense super planning user requires read/write permission to all of but only the Expense-Planning model.
In the Membership node, the user (Kimberly Haze) has been added to the role Expense Planning Group.
The role should have access only to expense-related data. In the Permission node, the role has been granted model permission to the Expense-Planning model.
When a member of the Expense Planning Group opens the IFP app, they have access to view and write to all the countries.
Expense USA planning user
An expense USA planning user requires read/write permission to the United States dimension member in the Expense-Planning model.
In the Membership node, the user (Albert Rivers) has been added to the Expense USA role. Because this role is a member of Expense Planning Group, the user has inherited membership to the latter.
In the Permission node, Expense USA has inherited the model permission to the Expense-Planning model by being a member of Expense Planning Group. This grants the role and its members access to the whole model, but they need to be limited to the USA dimension member. Therefore, a dimension permission to [Entity].[Entity].[United States] has been added.
When a member of Expense USA opens the IFP app, they have permission to view and write to only the United States.
Inheriting page restrictions
To delve deeper into these concepts, let's look at an example of how security inheritance works when handling page restrictions. In general, users should see only the relevant pages of an app, so administrators should add page restrictions for their roles.
Expense planning roles
For example, you would want to limit both expense planning users mentioned in the Data permission section to only the expense planning pages of the IFP app. Since both users need access to the same pages and the Expense USA role is a member of the Expense Planning Group role, we can add page restrictions just to the Expense Planning Group role.
Members of the two expense planning roles will see only OPEX in the header and the expense-related pages on the left navigation.
Super planning role
To provide a point of comparison, let's look at the page restrictions for a super planning role whose members need to have access to all pages in an app.
On the Page Restriction tab, you should explicitly add permission to all the pages.
When a member of the Super Planning Group role opens the IFP app, they have access to all the pages.