Permission Grants and Inheritance
BI Publisher provides application-specific permissions for accessing different features.
BI Publisher permissions are typically granted by becoming a member in an application role. Permissions can be granted two ways: through membership in an application role (direct) and through group and role hierarchies (inheritance). Application role membership can be inherited by nature of the application role hierarchy. In the default security configuration, each application role is preconfigured to grant a predefined set of permissions. Groups are mapped to an application role. The mapping of a group to a role conveys the role's permissions to all members of the group. In short, permissions are granted in BI Publisher by establishing the following relationships:
-
A group defines a set of users having similar system access requirements. Users are added as members to one or more groups according to the level of access required.
-
Application roles are defined to represent the role a user typically performs when using BI Publisher. The default security configuration provides the following preconfigured application roles: BIServiceAdministrator (an administrator), BIContentAuthor (an author of content), and BIConsumer (a consumer of content).
-
The groups of users are mapped to one or more application roles that match the type of access required by the population.
-
Application policies are created and BI Publisher permissions are mapped that grant a set of access rights corresponding to role type.
-
An application role is mapped to the application policy that grants the set of permissions required by the role type (an administrator, an author, a consumer).
-
Group membership can be inherited by nature of the group hierarchy. Application roles mapped to inherited groups are also inherited, and those permissions are likewise conveyed to the members.
How a user's permissions are determined by the system is as follows:
-
A user enters credentials into a Web browser at login. The user credentials are authenticated by the authentication provider against data contained in the identity store.
-
After successful authentication, a Java subject and principal combination is issued, which is populated with the user name and the user's groups.
-
A list of the user's groups is generated and checked against the application roles. A list is created of the application roles that are mapped to each of the user's groups.
-
A user's permission grants are determined from knowing which application roles the user is a member of. The list of groups is generated only to determine what roles a user has, and is not used for any other purpose.
A user can also be granted permissions if they inherit other application roles. Members of application roles can include other groups and application roles. The result is a hierarchical role structure where permissions can be inherited in addition to being explicitly granted. This hierarchy provides that a group is granted the permissions of the application role for which it is a member, and the permissions granted by all roles descended from that role.
For example, the default security configuration includes several predefined groups and application roles. The default BIServiceAdministrator application role includes the BIAdministrators group, the BIContentAuthor application role includes the BIAuthors group, and the BIConsumer application role includes the BIConsumers group. The default BIServiceAdministrator application role is a member of the BIContentAuthor application role, and the BIContentAuthor application role is a member of the BIConsumer application role. The members of these application roles inherit permissions as follows. Members of the BIAdministrators group are granted all the permissions of the BIServiceAdministrator role, the BIContentAuthor role, and the BIConsumer role. By nature of this role hierarchy, the user who is a member of a particular group is granted permissions both explicitly and through inheritance. For more information about the default application roles and groups, see Default Application Roles and Permissions.
Note:
By themselves, groups and group hierarchies do not enable any privilege to access resources controlled by an application. Privileges are conveyed by the permission grants defined in an application policy. A user, group, or application role becomes a Grantee of the application policy. The application policy Grantee conveys the permissions and this is done by direct association (user) or by becoming a member of the Grantee (group or application role).
The figure below shows these relationships between the default groups and application roles.
The table below summarizes how permissions are granted explicitly or are inherited in the previous example and figure.
| User Name | Group Membership: Explicit/Inherited | Application Role Membership: Explicit/Inherited | Permission Grants: Explicit/Inherited |
|---|---|---|---|
|
User1, User2, User3 |
BIConsumers: Explicit |
BIConsumer: Explicit |
Permission A: Explicit |
|
User4, User5 |
BIAuthors: Explicit BIConsumers: Inherited |
BIContentAuthor: Explicit BIConsumer: Inherited |
Permission B: Explicit Permission A: Inherited |
|
User6, User7 |
BIAdministrators: Explicit BIAuthors: Inherited BIConsumers: Inherited |
BIServiceAdministrator: Explicit BIContentAuthor: Inherited BIConsumer: Inherited |
Permission C: Explicit Permission B: Inherited Permission A: Inherited |