2 Configuring Oracle Fusion Middleware Security Model
It includes the following topics:
Understanding the Security Model
The Oracle Fusion Middleware security model is built upon the Oracle Fusion Middleware platform, which incorporates the Java security model.
The Java model is a role-based, declarative model that employs container-managed security where resources are protected by roles that are assigned to users. However, extensive knowledge of the Java-based architecture is unnecessary when using the Oracle Fusion Middleware Security model. When using this security model, BI Publisher can furnish uniform security and identity management across the enterprise.
After installation BI Publisher is automatically installed into an Oracle WebLogic Server domain, which is a logically related group of WebLogic Server resources that are managed as a unit. After a Simple installation type the WebLogic Server domain that is created is named bifoundation_domain. This name might vary depending upon the installation type performed. One instance of WebLogic Server in each domain is configured as an Administration Server. The Administration Server provides a central point for managing a WebLogic Server domain. The Administration Server hosts the Administration Console, which is a Web application accessible from any supported Web browser with network access to the Administration Server. BI Publisher is part of the active security realm configured for the Oracle WebLogic Server domain into which it is installed.
See Securing Applications with Oracle Platform Security Services. For more information about managing the Oracle WebLogic Server domain and security realm, see Understanding Security for Oracle WebLogic Server and Administering Security for Oracle WebLogic Server.
Key Security Elements
The Oracle Fusion Middleware security model depends upon key elements to provide uniform security and identity management across the enterprise
These key elements include:
-
Application policy
BI Publisher permissions are granted to members of its application roles. In the default security configuration, each application role conveys a predefined set of permissions. Permission grants are defined and managed in an application policy. After an application role is associated with an application policy, that role becomes a Grantee of the policy. An application policy is specific to a particular application.
-
Application role
After permission grants are defined in an application policy, an application role can be mapped to that policy, and the application role then becomes the mechanism to convey the permissions. In this manner an application role becomes the container that grants permissions to its members. The permissions become associated with the application role through the relationship between policy and role. After groups are mapped to an application role, the corresponding permissions are granted to all members equally. Membership is defined in the application role definition. Application roles are assigned in accordance with specific conditions and are granted dynamically based on the conditions present at the time authentication occurs. More than one user or group can be members of the same application role.
-
Authentication provider
An authentication provider is used to access user and group information and is responsible for authenticating users. The default authentication provider that BI Publisher uses during a Simple or Enterprise installation is named DefaultAuthenticator. This is the same default authenticator used by a basic Oracle WebLogic Server installation. An Oracle WebLogic Server authentication provider enables you to manage users and groups in one place.
An identity store contains user name, password, and group membership information. An authentication provider accesses the data in the identity store and authenticates against it. For example, when a user name and password combination is entered at log in, the authentication provider searches the identity store to verify the credentials provided. The BI Publisher default authentication provider authenticates against Oracle WebLogic Server embedded directory server.
-
Users and groups
A user is an entity that can be authenticated. A user can be a person, such as an application user, or a software entity, such as a client application. Every user is given a unique identifier.
Groups are organized collections of users that have something in common. Users should be organized into groups with similar access needs to facilitate efficient security management.
-
Security realm
During installation an Oracle WebLogic Server domain is created and BI Publisher is installed into that domain. BI Publisher security is managed within the security realm for this Oracle WebLogic Server domain. A security realm acts as a scoping mechanism. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. Only one security realm can be active for the domain. BI Publisher authentication is performed by the authentication provider configured for the default security realm for the WebLogic Server domain in which it is installed. Oracle WebLogic Server Administration Console is the administration tool used for managing an Oracle WebLogic Server domain.
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 |
Default Security Configuration
Access control of system resources is achieved by requiring users to authenticate at login and by restricting users to only those resources for which they are authorized.
A default security configuration is available for immediate use after BI Publisher is installed and is configured to use the Oracle Fusion Middleware security model. BI Publisher is installed into the Oracle WebLogic Server domain and uses its security realm. The default configuration includes three predefined security stores available for managing user identities, credentials, and BI Publisher-specific permission grants. Users can be added to predefined groups that are mapped to preconfigured application roles. Each application role is preconfigured to grant specific BI Publisher permissions.
The BI Publisher default security stores are configured as described in the table below during installation.
| Store Name | Purpose | Default Provider | Options |
|---|---|---|---|
|
Identity store |
|
|
BI Publisher can be configured to use alternative authentication providers. For a complete list, see System Requirements and Certification. |
|
Policy store |
|
|
BI Publisher can be configured to use Oracle Internet Directory as the policy store provider. |
|
Credential store |
Stores the passwords and other security-related credentials either supplied or system-generated. |
|
BI Publisher can be configured to use Oracle Internet Directory as the credential store provider. |
Default Users and Groups
Default user and group names can be changed to different values and new names can be added by an administrative user using Oracle WebLogic Server Administration Console.
The table below lists the default user names and passwords added to the BI Publisher identity store provider after installation.
| Default User Name and Password | Purpose | Description |
|---|---|---|
|
Name: administrator user Password: user supplied |
Is the administrative user. |
This user name is entered by the person performing the installation, it can be any desired name, and does not need to be named Administrator. The password entered during installation can be changed later using the administration interface for the identity store provider. This single administrative user is shared by BI Publisher and Oracle WebLogic Server. This user is automatically made a member of the Oracle WebLogic Server default Administrators group after installation. This enables this user to perform all Oracle WebLogic Server administration tasks, including the ability to manage Oracle WebLogic Server's embedded directory server. |
No default groups are created during the installation of BI Publisher.
Default Application Roles and Permissions
Permissions in BI Publisher are granted by specific roles. Permissions can also be inherited from group and application role hierarchies.
The table below lists the BI Publisher permissions and the application role that grants these permissions. This mapping exists in the default policy store.
The table also lists the permissions explicitly granted by membership in the corresponding default application role. Permissions can also be inherited from group and application role hierarchies. For more information about permission inheritance, see Permission Grants and Inheritance.
| BI Publisher Permission | Description | Default Application Role Granting Permission Explicitly |
|---|---|---|
|
oracle.bi.publisher.administerServer |
Enables the Administration link to access the Administration page and grants permission to set any of the system settings. Important: See Granting the BIServiceAdministrator Role Catalog Permissions for additional steps required to grant the BIServiceAdministrator permissions on Shared Folders. |
BIServiceAdministrator |
|
oracle.bi.publisher.developDataModel |
Grants permission to create or edit data models. |
BIContentAuthor |
|
oracle.bi.publisher.developReport |
Grants permission to create or edit reports, style templates, and sub templates. This permission also enables connection to the BI Publisher server from the Template Builder. |
BIContentAuthor |
|
oracle.bi.publisher.runReportOnline |
Grants permission to open (execute) reports and view the generated document in the report viewer. |
BIConsumer |
|
oracle.bi.publisher.scheduleReport |
Grants permission to create or edit jobs and also to manage and browse jobs. |
BIConsumer |
|
oracle.bi.publisher.accessReportOutput |
Grants permission to browse and manage job history and output. |
BIConsumer |
|
BIConsumer permissions granted implicitly |
The authenticated role is a member of the BIConsumer role by default and, as such, all authenticated role members are granted the permissions of the BIConsumer role implicitly. |
Authenticated Role |
The authenticated role is a special application role provided by the Oracle Fusion Middleware security model and is made available to any application deploying this security model. BI Publisher uses the authenticated application role to grant permissions implicitly derived by the role and group hierarchy of which the authenticated role is a member. The authenticated role is a member of the BIConsumer role by default and, as such, all authenticated role members are granted the permissions of the BIConsumer role implicitly. By default, every authenticated user is automatically added to the BIConsumers group. The authenticated role is not stored in the obi application stripe and is not searchable in the BI Publisher policy store. However, the authenticated role is displayed in the administrative interface for the policy store, is available in application role lists, and can be added as a member of another application role. You can map the authenticated role to another user, group, or application role, but you cannot remove the authenticated role itself. Removal of the authenticated role would result in the inability to log in to the system and this right would need to be granted explicitly.
For more information about the Oracle Fusion Middleware security model and the authenticated role, see Securing Applications with Oracle Platform Security Services.
Granting the BIServiceAdministrator Role Catalog Permissions
The BIServiceAdministrator role is granted only Read permissions on the catalog by default.
This means that before a BIServiceAdministrator can manage Shared Folders the BIServiceAdministrator role must be granted Write and Delete permissions on the Shared Folders node. See Granting Catalog Permissions for a detailed description of granting permissions in the catalog.
Managing Authentication
Authentication is the process of verifying identity by confirming the user is who he claims to be. Oracle WebLogic Server embedded directory server is the authentication provider for the default security configuration.
Users, groups, and passwords are managed using Oracle WebLogic Server Administration Console. It is fine to use the default authentication provider for a development or test environment. In a production environment, best practice is to use a full featured authentication provider.
Note:
Refer to the system requirements and certification documentation for information about hardware and software requirements, platforms, databases, and other information. These documents are available on Oracle Technology Network (OTN).
During installation an Oracle WebLogic Server domain is created. BI Publisher is installed into that domain and uses the Oracle WebLogic Server security realm. The security realm can have multiple authentication providers configured but only one provider can be active at a time. The order of providers in the list determines priority. The effect of having multiple authentication providers defined in a security realm is not cumulative; rather, the first provider in list is the source for all user and password data needed during authentication. This enables you to switch between authentication providers as needed. For example, if you have separate LDAP servers for your development and production environments, you can change which directory server is used for authentication by re-ordering them in the Administration Console. For information about how to configure a different authentication provider, see Configuring a New Authentication Provider.
Detailed information about managing an authentication provider in Oracle WebLogic Server is available in its online help. For more information, log in to Oracle WebLogic Server Administration Console and launch Oracle WebLogic Server Administration Console Online Help.
Accessing Oracle WebLogic Server Administration Console
Oracle WebLogic Server is automatically installed and serves as the default administration server.
The Administration Console is browser-based and is used to manage the embedded directory server that is configured as the default authenticator. It is launched by entering its URL into a web browser. The default URL takes the following form: http://hostname:port_number/console. The port number is the number of the administration server. By default, the port number is 7001.
To launch the Oracle WebLogic Server Administration Console:
- Log in to Oracle WebLogic Server by entering its URL into a Web browser.
For example,
http://hostname:7001/console.The Administration Console login page displays, as shown the figure below. - Log in using the BI Publisher administrative user and password and click Login.
The password is the one you supplied during the installation of BI Publisher. If these values have been changed, then use the current administrative user name and password combination.
The Administration Console displays, as shown the figure below.
Managing Users and Groups Using the Default Authentication Provider
Managing a group is more efficient than managing a large number of users individually. Best practice is to first organize all BI Publisher users into groups that have similar system access requirements.
These groups can then be mapped to application roles that provide the correct level of access. If system access requires change, then you need only modify the permissions granted by the application roles, or create a new application role with appropriate permissions. Once your groups are established, continue to add or remove users directly in the identity store using its administration interface as you normally would.
To create a user in the default directory server:
-
If needed, launch Oracle WebLogic Server Administration Console.
See Accessing Oracle WebLogic Server Administration Console.
-
Log in as an administrative user.
-
In the Administration Console, select Security Realms from the left pane and click the realm you are configuring. For example, myrealm.
-
Select Users and Groups tab (shown below), then Users. Click New.
-
In the Create a New User page (shown below) provide the following information:
-
Name: Enter the name of the user. See online help for a list of invalid characters.
-
(Optional) Description: Enter a description.
-
Provider: Select the authentication provider from the list that corresponds to where the user information is contained. DefaultAuthenticator is the name for the default authentication provider.
-
Password: Enter a password for the user that is at least 8 characters long.
-
Confirm Password: Re-enter the user password.
-
-
Click OK.
The user name is added to the User table.
To create a group in the default directory server:
-
If needed, launch Oracle WebLogic Server Administration Console.
See Accessing Oracle WebLogic Server Administration Console.
-
Log in as an administrative user.
-
In the Administration Console, select Security Realm from the left pane and click the realm you are configuring. For example, myrealm.
-
Select Users and Groups tab, then Groups. Click New.
-
In the Create a New Group page provide the following information:
-
Name: Enter the name of the Group. Group names are case insensitive but must be unique. See the online help for a list of invalid characters.
-
(Optional) Description: Enter a description.
-
Provider: Select the authentication provider from the list that corresponds to where the group information is contained. DefaultAuthenticator is the name for the default authentication provider.
-
-
Click OK.
The group name is added to the Group table.
To add a user to a group in the default directory server:
-
If needed, launch Oracle WebLogic Server Administration Console.
See Accessing Oracle WebLogic Server Administration Console.
-
Log in as an administrative user.
-
In the Administration Console, select Security Realm from the left pane and click the realm you are configuring. For example, myrealm.
-
Select Users and Groups tab, then Users, as shown in the figure below. Select the user from Name.
-
From the Settings page, select the Groups tab to display the list of available groups.
-
Select one or more groups from the Available list and use the shuttle controls to move them to the Chosen list, as shown below.
-
Click Save.
The user is added to the group.
To change a user password in the default directory server:
- In the Users table select the user you want to change the password for.
The settings page for the user displays, as shown below.
Managing Authorization
After a user is authenticated, further access to BI Publisher resources is controlled by the granting of permissions, also known as authorization.
The policy store contains the system and application-specific policies and roles required for BI Publisher. A policy store can be file-based or LDAP-based and holds the mapping definitions between the default BI Publisher application roles, permissions, users and groups. BI Publisher permissions are granted by mapping users and groups from the identity store to application roles and permission grants located in the policy store. These mapping definitions between users and groups (identity store) and the application roles (policy store) are also kept in the policy store.
Note:
Best practice is to map groups instead of individual users to application roles. Controlling membership in a group reduces the complexity of tracking access rights for multiple individual users. Group membership is controlled in the identity store.
The system-jazn-data.xml file is installed and configured as the default policy store. You can continue to use the default store and modify it as needed for your environment, or you can migrate its data to an LDAP-based provider. Oracle Internet Directory is the supported LDAP server in this release.
The policy store and credential store must be of the same type in your environment. That is, both must be either file-based or LDAP-based.
Permissions must be defined in a manner that BI Publisher understands. All valid BI Publisher permissions are premapped to application policies, which are in turn premapped to the default application roles. You cannot create new permissions in the policy store. However, you can customize the default application policy permission grants and application role mappings and you can create your own.
For more information about the default BI Publisher permissions grants, see Default Application Roles and Permissions. For more information about customizing application roles and permission grants, see Customizing the Policy Store.
Accessing Oracle Enterprise Manager Fusion Middleware Control
Fusion Middleware Control is a Web browser-based, graphical user interface that you can use to monitor and administer a farm.
A farm is a collection of components managed by Fusion Middleware Control. It can contain Oracle WebLogic Server domains, one Administration Server, one or more Managed Servers, clusters, and the Oracle Fusion Middleware components that are installed, configured, and running in the domain. During installation an Oracle WebLogic domain is created and BI Publisher is installed into that domain. If you performed a Simple or Enterprise installation type, this domain is named bifoundation_domain and is located within the WebLogic Domain in the Fusion Middleware Control target navigation pane.
Launch Fusion Middleware Control by entering its URL into a Web browser. The URL includes the name of the host and the administration port number assigned during the installation. This URL takes the following form: http://hostname:port_number/em. The default port is 7001. For more information about using Fusion Middleware Control, see Administering Oracle Fusion Middleware.
To display the Security menu in Fusion Middleware Control:
Managing the Policy Store Using Fusion Middleware Control
Use Fusion Middleware Control to manage the BI Publisher application policies and application roles maintained in the policy store whether it is file-based or LDAP-based.
For more information about configuring an LDAP-based policy store, see Configuring a New Policy Store and Credential Store Provider.
Caution:
Oracle recommends you make a copy of the original system-jazn-data.xml policy file and place it in a safe location. Use the copy of the original file to restore the default policy store configuration, if needed. Changes to the default security configuration might lead to an unwanted state. The default installation location is MW_HOME/user_projects/domain/your_domain/config/fmwconfig.
The following are common policy store management tasks:
-
Modifying the membership of an application role. See Modifying Membership in an Application Role.
-
Modifying the permission grants for an application role. See Changing Permission Grants for an Application Policy.
-
Creating a new application role from the beginning. See Creating Application Roles Using Fusion Middleware Control.
-
Creating a new application role based on an existing application role. See Creating Application Roles Using Fusion Middleware Control.
Modifying Application Roles Using Fusion Middleware Control
Members can be added or deleted from an application role using Fusion Middleware Control.
You must perform these tasks while in the WebLogic Domain that BI Publisher is installed in. For example, bifoundation_domain.
Caution:
Be very careful when changing the permission grants and membership for the default application roles. Changes could result in an unusable system.
Modifying Membership in an Application Role
Valid members of an application role are users, groups, or other application roles.
The process of becoming a member of an application role is called mapping. That is, being mapped to an application role is to become a member of an application role. Best practice is to map groups instead of individual users to application roles for easier maintenance.
To add or remove members from an application role:
Managing Credentials
Credentials used by the system are stored in a single secure credential store. Oracle Wallet is the default credential store file (cwallet.sso).
The credential store alternatively can be LDAP-based, and Oracle Internet Directory is the supported LDAP server in this release. You can configure and administer LDAP-based credential stores using Oracle Enterprise Manager Fusion Middleware Control or WLST commands.
Each credential is uniquely identified by a map name and a key name. Each map contains a series of keys, and each key is a credential. The combination of map name and key name must be unique for all credential store entries.
BI Publisher supports the following credential maps:
-
oracle.bi.system: Contains the credentials that span the entire BI Publisher platform.
-
oracle.bi.publisher: Contains the credentials used by only BI Publisher.
BI Publisher supports the following credential types:
-
Password: Encapsulates a user name and a password.
-
Generic: Encapsulates any customized data or arbitrary token, such as public key certificates.
To help you get started with your development environment, default credentials are added to the file-based credential store during installation. Note that BI Publisher credentials such as user passwords are stored in the identity store and managed with its corresponding administrative interface.
Managing BI System User Credentials
If using Oracle Business Intelligence as a data store, BI Publisher establishes system communication with it as BI system user.
Oracle Business Intelligence uses BI system user for trusted system communication. To change the password of BI system user in the credential store (oracle.bi.system credential map), see Security Guide for Oracle Business Intelligence Enterprise Edition.
Customizing the Default Security Configuration
You can customize the default security configuration in various ways.
-
Configure a new authentication provider. See Configuring a New Authentication Provider.
-
Configure new policy store and credential store providers. See Configuring a New Policy Store and Credential Store Provider.
-
Migrate policies and credentials from one store to another. See Reassociating the Policy Store and Credential Store.
-
Create new application roles. See Creating Application Roles Using Fusion Middleware Control.
-
Create new application policies. See Creating Application Policies Using Fusion Middleware Control.
-
Modify the permission grants for an application policy. See Changing Permission Grants for an Application Policy.
Configuring a New Authentication Provider
You can configure another supported LDAP server to be the authentication provider.
Configuring BI Publisher to use an alternative external identity store is performed using the Oracle WebLogic Server Administration Console. BI Publisher delegates authentication and user population management to the authentication provider and identity store configured for the domain it is a part of. For example, if configured to use Oracle WebLogic Server's default authentication provider, then management is performed in the Oracle WebLogic Server Administration Console. If configured to use Oracle Internet Directory (OID), then the OID management user interface is used, and so on.
If using an authentication provider other than the one installed as part of the default security configuration, the default users and groups that are discussed in Default Users and Groups are not automatically present. You can create users and groups with names of your own choosing or re-create the default user and group names if the authentication provider supports this. After this work is completed, you must map the default BI Publisher application roles to different groups again. For example, if the corporate LDAP server is being used as the identity store and you are unable to re-create the BI Publisher default users and groups in it, you must map the default application roles to different groups specific to the corporate LDAP server. Use Fusion Middleware Control to map the groups to application roles.
For information about how to configure a different authentication provider, see Oracle WebLogic Server Administration Console Online Help and Administering Security for Oracle WebLogic Server.
Configuring a New Policy Store and Credential Store Provider
The policy store and credential store can be file-based or LDAP-based.
The supported LDAP server for both stores in this release is Oracle Internet Directory. The pre-requisites for using an LDAP-based store are the same as for both the policy store and credential store. See Securing Applications with Oracle Platform Security Services.
Reassociating the Policy Store and Credential Store
Migrating policies and credentials from one security store to another is called reassociation.
Both policy store and credential store data can be reassociated (migrated) from a file-based store to an LDAP-based store, or from an LDAP-based store to another LDAP-based store.
Because the credential store and the policy store must both be of the same type, when reassociating one store you must reassociate the other.
See Securing Applications with Oracle Platform Security Services.
Customizing the Policy Store
The Fusion Middleware Security model can be customized for your environment by creating your own application policies and application roles.
Existing application roles can be modified by adding or removing members as needed. Existing application policies can be modified by adding or removing permission grants. For more information about managing application policies and application roles, see Securing Applications with Oracle Platform Security Services.
Note:
Before creating a new application policy or application role and adding it to the default BI Publisher security configuration, familiarize yourself with how permission and group inheritance works. It is important when constructing a role hierarchy that circular dependencies are not introduced. Best practice is to leave the default security configuration in place and first incorporate your customized application policies and application roles in a test environment. For more information, see Permission Grants and Inheritance.
Creating Application Roles Using Fusion Middleware Control
You can create a new application role or copy from an existing role using Fusion Middleware Control.
Creating Application Roles
There are two methods for creating a new application role.
-
Create New — Creates new application role. You can add members when you create the new role, or you can save the new role after naming it and later add members.
-
Copy Existing — Creates a new application role by copying an existing application role. The copy contains the same members as the original, and the new role will be Grantee of the same application policy. You can modify the copy as required when you create the new role.
Creating a New Application Role
-
Log into Fusion Middleware Control, navigate to Security, and select Application Roles to display the Application Roles page.
For information, see Accessing Oracle Enterprise Manager Fusion Middleware Control.
-
Choose obi from Application Stripe list. Click the search icon next to Role Name.
You can view the BI Publisher application roles.
-
Click Create to display the Create Application Role page. You can enter all information at once or you can enter a Role Name, save it, and complete the remaining fields later. Complete the fields as follows:
In the General section:
-
Role Name — Enter the name of the application role.
-
(Optional) Display Name — Enter the display name for the application role.
-
(Optional) Description — Enter a description for the application role.
-
-
In the Members section, Click Add to select the users, groups, or application roles you want to map to the applications role.
-
From the Type list, select Application Role, User, or Role you want to map to the application role.
-
Optionally, you can specify the criteria for Principal Name and Display Name.
-
Click the search icon next to Display Name.
-
Select the principals from the Searched Principals table.
-
Click OK.
-
-
Click OK to return to the Application Roles page.
The table at the bottom of the page displays the new application role.
Creating an Application Role Based on an Existing role
- Complete the Role Name, Display Name, and Description fields.
For example, the figure below shows the MyNewRole application role based on the BIContentAuthor role.
- Use Add and Delete to modify the members as appropriate and click OK.
The table at the bottom of the page displays the newly created application role. For example, the figure below shows the MyNewRole based on the default BIContentAuthor application role.
Creating Application Policies Using Fusion Middleware Control
All BI Publisher permissions are provided and you cannot create new permissions. Permission grants are controlled in the Fusion Middleware Control Application Policies page.
Creating Application Policies
The permission grants are defined in an application policy. An application role, user, or group, is then mapped to an application policy. This process makes the application role, user, or group a Grantee of the application policy.
There are two methods for creating a new application policy:
-
Create New — Creates a new application policy and adds permissions to it.
-
Copy Existing — Creates a new application policy by copying an existing application policy. You can name the copy, remove existing permissions, or add new permissions as required.
Creating a New Application Policy
-
Log in to Fusion Middleware Control, navigate to Security, and select Application Policies to display the Application Policies page.
For information, see Accessing Oracle Enterprise Manager Fusion Middleware Control.
-
Choose obi from Application Stripe list. Click the search icon next to Principal Name.
You can view the BI Publisher application policies. The Principal column displays the name of the policy Grantee.
-
Click Create to display the Create Application Grant page.
-
To add permissions to the policy being created, click Add in the Permissions area to display the Add Permission dialog.
-
Complete the Search section, and click the search icon next to the Resource Name field.
All permissions located in the obi application stripe are displayed. For information about the BI Publisher permissions, see Default Application Roles and Permissions.
-
Select the desired BI Publisher permissions, and click Continue. Selecting non-BI Publisher permissions has no effect in the policy.
-
If required, customize the permission and click Select.
The Permissions section display the selected permissions.
-
-
To add an application role, user, or group to the policy being created, click Add in the Grantee section..
In the Add Principal dialog, do the following:
-
Complete the Search section, and click the search icon next to the Display Name field.
-
Select the required principals from the Searched Principals list.
-
Click OK.
-
-
Click OK to return to the Application Policies page. You can view the Principal (Grantee) and Permissions of the new policy in the table.
Creating an Application Policy Based on an Existing Policy
- Select an existing policy from the table.
For example, the figure below shows the selected BIServiceAdministrator Principal (Grantee) selected and the activated Create Like button.
The Application Policies page displays the Principal and Permissions of the policy.