Granting Permissions To Users Using Groups and Application Roles
The default Oracle Business Intelligence security configuration provides preconfigured permission sets that group together related permissions.
If you import the sample or starter application into your service instance the preconfigured permission sets are granted to the application roles included in the sample and starter applications. If you import the empty BAR file into your service instance, you must use WLST commands to assign permission sets to the application roles that you create. Application roles have groups as members, and permissions are inherited by users through their membership in groups. A group assigned to an application role conveys the role's permissions to all members of the group.
You grant permissions through Oracle Business Intelligence application roles by establishing the following relationships:
-
A group defines a set of users having similar system access requirements. Users are added as members of one or more groups according to the level of access required.
-
An application role defines the role a user typically performs when using Oracle Business Intelligence. The security policy in the Sample Application provides the following roles: administrator (BIServiceAdministrator), author (BIContentAuthor), and consumer (BIConsumer).
-
A group is assigned to one or more application roles that match the type of access required by each group.
-
An application policy defines Oracle Business Intelligence permissions that grant a set of access rights corresponding to each role type.
-
An application role is assigned to an application policy that grants the set of permissions required by the role type, for example administrator, author, consumer. Once configured, the application role is the grantee of the application policy.
-
Group membership can be inherited by nature of the group hierarchy. Application roles assigned to inherited groups are also inherited, and their permissions are likewise conveyed.
How the system determines a user's permissions:
-
A user enters credentials into a web browser at login. The user credentials are authenticated by the authentication provider against data contained 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 checked against the application roles. A list is created of the application roles that are assigned 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.
For example, the ability to open a repository file in online mode from the Oracle BI Administration Tool requires the relevant permission, the oracle.bi.repository resource type with a resource scope of * and an action of manage. In the sample and starter application security policies, permission is granted by membership in the BIServiceAdministrator application role. The BIServiceAdministrator application policy contains the actual permission grant definitions. The BIServiceAdministrator application policy contains the permission set grant that includes the relevant permission. The Oracle Business Intelligence installation does not automatically create any (LDAP) groups. To convey this permission set to a user in your environment, create a suitable group such as a BIAdministrators group in the WebLogic LDAP or the Identity Store that you have configured Oracle Business Intelligence against if any, add that user to the BIServiceAdministrators group, then use EM FMW control or WLST to map the BIServiceAdministrators group to the BIServiceAdministrator application role. Every user who needs to manage a repository in online mode should be added to this group (for example, BIServiceAdministrators) instead of granting the required permission to each user individually. If a user no longer requires the manage repository permission, you then remove the user from the BIServiceAdministrators group. After removal from the BIServiceAdministrators group, the user no longer has the BIServiceAdministrator application role or the manage repository permission granted by role membership.
Users can also obtain permissions by inheriting group membership and application roles. For an example of how this is accomplished, see Permission Inheritance and Role Hierarchy.
Permission Inheritance and Role Hierarchy
InOracle Business Intelligence the members of an application role can include groups and other application roles. The result is a hierarchical application role structure where permissions can be inherited in addition to being explicitly granted.
A group that is a member of an application role is granted both the permissions of the application role and the permissions for all application roles descended from that application role. It is important when constructing an application role hierarchy that circular dependencies are not introduced.
The diagram shows the relationship between application roles and how permissions are granted to members.
In the diagram, the role hierarchy grants permissions using several of the Oracle Business Intelligence default groups and application roles. In the Sample and Starter applications, the default BIServiceAdministrator role is a member the BIContentAuthor role, and BIContentAuthor role is a member of BIConsumer. The result is that members of the BIServiceAdministrator application role are granted all the permissions of the BIServiceAdministrator role, the BIContentAuthor role, and the BIConsumer role. So a user who is a member of a particular group mapped to an application role is granted both explicit permissions and any additional inherited permissions.
Note:
By themselves, groups and group hierarchies do not provide access rights to application resources. 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 (such as a user) or by becoming a member of the grantee (such as a group or application role).