2 Configuring Oracle Fusion Middleware Security Model

This chapter describes how to configure Oracle Fusion Middleware security model for BI Publisher.

It includes the following topics:

2.1 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.

For more information about the Oracle Fusion Middleware platform and the common security framework, see Oracle Fusion Middleware Application Security Guide. For more information about managing the Oracle WebLogic Server domain and security realm, see Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server and Oracle Fusion Middleware Securing Oracle WebLogic Server.

2.2 Key Security Elements

The Oracle Fusion Middleware security model depends upon the following key elements to provide uniform security and identity management across the enterprise:

  • 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.

2.3 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: BIAdministrator (an administrator), BIAuthor (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:

  1. 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.

  2. After successful authentication, a Java subject and principal combination is issued, which is populated with the user name and the user's groups.

  3. 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.

  4. 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 BIAdministrator application role includes the BIAdministrators group, the BIAuthor application role includes the BIAuthors group, and the BIConsumer application role includes the BIConsumers group. The default BIAdministrator application role is a member the BIAuthor application role, and the BIAuthor 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 BIAdministrator role, the BIAuthor 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 Section 2.4.2, "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).

Figure 2-1 shows these relationships between the default groups and application roles.

Figure 2-1 Relationships Between Default Groups and Application Roles

Description of Figure 2-1 follows
Description of "Figure 2-1 Relationships Between Default Groups and Application Roles"

Table 2-1 summarizes how permissions are granted explicitly or are inherited in the previous example and figure.

Table 2-1 Permissions Granted by the Role Hierarchy Example

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

BIAuthor: Explicit BIConsumer: Inherited

Permission B: Explicit Permission A: Inherited

User6, User7

BIAdministrators: Explicit BIAuthors: Inherited BIConsumers: Inherited

BIAdministrator: Explicit BIAuthor: Inherited BIConsumer: Inherited

Permission C: Explicit Permission B: Inherited Permission A: Inherited


2.4 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 Table 2-2 during installation.

Table 2-2 BI Publisher Default Security Stores

Store Name Purpose Default Provider Options

Identity store

  • Used to control authentication.

  • Stores the users and groups, and the users group for Oracle WebLogic Server embedded directory server.

  • Oracle WebLogic Server embedded directory server.

  • Managed with Oracle WebLogic Server Administration Console.

BI Publisher can be configured to use alternative authentication providers. For a complete list, see System Requirements and Certification.

Policy store

  • Used to control authorization.

  • Stores the application role definitions and the mapping definitions between groups and application roles.

  • system.jazn-data.xml file. Default installation location is MW_HOME/user_projects/domain/your_domain/config/fmwconfig

  • Managed with Oracle Enterprise Manager Fusion Middleware Control.

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.

  • cwallet.sso file.

  • Managed using Fusion Middleware Control.

BI Publisher can be configured to use Oracle Internet Directory as the credential store provider.


2.4.1 Default Users and Groups

Table 2-3 lists the default user names and passwords added to the BI Publisher identity store provider after installation. These defaults can be changed to different values and additional users can be added to the identity store by an administrative user using Oracle WebLogic Server Administration Console.

Table 2-3 Default Names and Passwords

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.

Name:

BISystemUser

Password:

system generated

A fixed user created during installation for trusted communication between components when using Oracle BI Analysis as a data source for your BI Publisher Data Model.

If you are integrating BI Publisher with Oracle Business Intelligence Enterprise Edition, the recommendation is to use this default user name for trusted communication with Oracle BI Presentation Services. This is the default configuration automatically configured during installation.

Important: This is a highly privileged user whose credentials should be protected from non-administrative users.

Using a separate trusted system account for secure inter-component communication enables you to change the password for the system administrator account without affecting communication between components.

The name of this user can be changed or a different user can be created for the purpose of inter-component communication.


Table 2-4 lists the default group names and group members added to the identity store provider during installation. These defaults can be changed to different values and additional group names can be added by an administrative user using Oracle WebLogic Server Administration Console.

Table 2-4 Default Group Names and Members

Default Group Name and Members Purpose Description

Name: BIAdministrators

Members: Any administrator user

Contains the BI Publisher administrative users.

Members of the BIAdministrators group are granted administrative permissions because this group is mapped to the BIAdministrator application role at installation.

All users requiring administrative permissions should be added to the BIAdministrators group when using the default security configuration.

Name: BIAuthors

Members: BIAdministrators group

Contains the BI Publisher authors.

Members of the BIAuthors group have the permissions necessary to create content for other users to use, or to consume.

Name: BIConsumers

Members: BIAuthors group and Oracle WebLogic Server LDAP server users group.

Contains the BI Publisher consumers.

Members of the BIConsumers group have the permissions necessary to use, or consume, content created by other users.

The BIConsumers group represents all users that have been authenticated by BI Publisher. By default, every authenticated user is automatically added to this group.

Oracle WebLogic Server LDAP server users group members have the permissions necessary to log in to and use Oracle WebLogic Server Administration Console.


2.4.2 Default Application Roles and Permissions

Table 2-5 lists the BI Publisher permissions and the application role that grants these permissions. This mapping exists in the default policy store.

Table 2-5 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 Section 2.3, "Permission Grants and Inheritance."

Table 2-5 BI Publisher Permissions and Application Roles

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 Section 2.4.2.1, "Granting the BIAdministrator Role Catalog Permissions" for additional steps required to grant the BIAdministrator permissions on Shared Folders.

BIAdministrator

oracle.bi.publisher.developDataModel

Grants permission to create or edit data models.

BIAuthor

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.

BIAuthor

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

oracle.bi.publisher.accessExcelReportAnalyzer

Grants permission to download the Analyzer for Excel and to download data from a report to Excel using the Analyzer for Excel. Note that to enable a user to upload an Analyzer for Excel template back to the report definition, the permission oracle.bi.publisher.developReport must also be granted.

BIConsumer

oracle.bi.publisher.accessOnlineReportAnalyzer

Grants permission to launch the Analyzer and manipulate the data. Note that to save an Analyzer template to a report definition, the permission oracle.bi.publisher.developReport must also be granted.

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 Oracle Fusion Middleware Application Security Guide.

2.4.2.1 Granting the BIAdministrator Role Catalog Permissions

The BIAdministrator role is granted only Read permissions on the catalog by default. This means that before a BIAdministrator can manage Shared Folders the BIAdministrator role must be granted Write and Delete permissions on the Shared Folders node. See Section 3.8.3, "Granting Catalog Permissions" for a detailed description of granting permissions in the catalog.

2.5 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 Section 2.8.1, "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 Fusion Middleware Oracle WebLogic Server Administration Console Online Help.

2.5.1 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:

  1. 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 in Figure 2-2.

    Figure 2-2 Administration Console Login Page

    Description of Figure 2-2 follows
    Description of "Figure 2-2 Administration Console Login Page"

  2. 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 in Figure 2-3.

    Figure 2-3 Administration Console

    Description of Figure 2-3 follows
    Description of "Figure 2-3 Administration Console"

2.5.2 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 requirements change, then you need only modify the permissions granted by the application roles, or create a new application roles 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:

  1. If needed, launch Oracle WebLogic Server Administration Console.

    For more information, see Section 2.5.1, "Accessing Oracle WebLogic Server Administration Console."

  2. Log in as an administrative user.

  3. In the Administration Console, select Security Realms from the left pane and click the realm you are configuring. For example, myrealm.

  4. Select Users and Groups tab (shown in Figure 2-4), then Users. Click New.

    Figure 2-4 Users and Groups tab

    Description of Figure 2-4 follows
    Description of "Figure 2-4 Users and Groups tab"

  5. In the Create a New User page (shown in Figure 2-5) 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.

    Figure 2-5 Create a New User Page

    Description of Figure 2-5 follows
    Description of "Figure 2-5 Create a New User Page"

  6. Click OK.

    The user name is added to the User table.

To create a group in the default directory server:

  1. If needed, launch Oracle WebLogic Server Administration Console.

    For more information, see Section 2.5.1, "Accessing Oracle WebLogic Server Administration Console."

  2. Log in as an administrative user.

  3. In the Administration Console, select Security Realm from the left pane and click the realm you are configuring. For example, myrealm.

  4. Select Users and Groups tab, then Groups. Click New.

  5. 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.

  6. Click OK.

    The group name is added to the Group table.

To add a user to a group in the default directory server:

  1. If needed, launch Oracle WebLogic Server Administration Console.

    For more information, see Section 2.5.1, "Accessing Oracle WebLogic Server Administration Console."

  2. Log in as an administrative user.

  3. In the Administration Console, select Security Realm from the left pane and click the realm you are configuring. For example, myrealm.

  4. Select Users and Groups tab, then Users, as shown in Figure 2-6. Select the user from Name.

  5. From the Settings page, select the Groups tab to display the list of available groups.

  6. Select one or more groups from the Available list and use the shuttle controls to move them to the Chosen list, as shown in Figure 2-7.

    Figure 2-7 Available List and Chosen List

    Description of Figure 2-7 follows
    Description of "Figure 2-7 Available List and Chosen List"

  7. Click Save.

    The user is added to the group.

To change a user password in the default directory server:

  1. If needed, launch Oracle WebLogic Server Administration Console.

    For more information, see Section 2.5.1, "Accessing Oracle WebLogic Server Administration Console."

  2. Log in as an administrative user.

  3. In the Administration Console, select Security Realms from the left pane and click the realm you are configuring. For example, myrealm.

  4. Select Users and Groups tab, then Users.

  5. In the Users table select the user you want to change the password for.

    The settings page for the user displays, as shown in Figure 2-8.

  6. Select the Passwords tab and enter the password in the New Password and Confirm Password fields.

  7. Click Save.

2.6 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 Section 2.4.2, "Default Application Roles and Permissions." For more information about customizing application roles and permission grants, see Section 2.8.3, "Customizing the Policy Store."

2.6.1 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 Oracle Fusion Middleware Administrator's Guide.

To display the Security menu in Fusion Middleware Control:

  1. Log into Oracle Enterprise Manager Fusion Middleware Control by entering the URL in a Web browser.

    For example, http://hostname:7001/em.

    The Fusion Middleware Control login page displays, as shown in Figure 2-9.

    Figure 2-9 Fusion MIddleware Control Login Page

    Description of Figure 2-9 follows
    Description of "Figure 2-9 Fusion MIddleware Control Login Page"

  2. Enter the BI Publisher administrative user name 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.

  3. From the target navigation pane, open WebLogic Domain to display bifoundation_domain. Display the Security menu by selecting one of the following methods:

2.6.2 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 Section 2.8.2, "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:

2.6.3 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.

2.6.4 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:

  1. Log into Fusion Middleware Control, navigate to Security, then select Application Roles to display the Application Roles page.

    For information about navigating to the Security menu, see Section 2.6.1, "Accessing Oracle Enterprise Manager Fusion Middleware Control."

  2. Choose Select Application Stripe to Search, then select the obi from the list. Click the search icon next to Role Name, as shown in Figure 2-12.

    The BI Publisher application roles are displayed. Figure 2-13 shows the default application roles.

    Figure 2-13 Default Application Roles

    Description of Figure 2-13 follows
    Description of "Figure 2-13 Default Application Roles"

  3. Select the cell next to the application role name and click Edit to display the Edit Application Role page. In Figure 2-14, the BIAuthor application role has been selected.

    Figure 2-14 BIAuthor Application Role

    Description of Figure 2-14 follows
    Description of "Figure 2-14 BIAuthor Application Role"

    You can add or delete members from the Edit Application Role page. Valid members are application roles, groups, and users.

  4. Select from the following options:

    • To delete a member: From Members, select from Name the member to activate the Delete button. Click Delete.

    • To add a member: Click the Add button that corresponds to the member type being added. Select from Add Application Role, Add Group, and Add User.

  5. If adding a member, complete Search and select from the available list. Use the shuttle controls to move the member to the selected field. Click OK.

    For example, Figure 2-15 shows the Add Group dialog after the Report_Dev group has been selected.

    Figure 2-15 Add Group Dialog

    Description of Figure 2-15 follows
    Description of "Figure 2-15 Add Group Dialog"

    The added member displays in the Members column corresponding to the application role modified in the Application Roles page.

2.7 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. LDAP-based credential stores are configured and administered 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. The following credential maps are used by BI Publisher:

  • oracle.bi.system: Contains the credentials that span the entire BI Publisher platform.

  • oracle.bi.publisher: Contains the credentials used by only BI Publisher.

The following two credential types are supported:

  • Password: Encapsulates a user name and a password.

  • Generic: Encapsulates any customized data or arbitrary token, such as public key certificates.

To facilitate getting started with your development environment, default credentials are inserted into the file-based credential store during installation. Be aware that BI Publisher credentials such as user passwords are stored in the identity store and managed with its corresponding administrative interface.

2.7.1 Managing the Credential Store

Credentials can be managed either in Fusion Middleware Control or using WLST command. For more information about both methods, see "Managing the Domain Credential Store" in Oracle Fusion Middleware Application Security Guide.

2.7.2 Managing BISystemUser Credentials

If using Oracle Business Intelligence as a data store, BI Publisher establishes system communication with it as BISystemUser. If you change the BISystemUser password in the identity store administrative interface, you also must change the password in the credential store (oracle.bi.system credential map). This applies if you have created a custom application role to take the place of the default BISystemUser. Components cannot communicate with each other if the credentials are out-of-sync. For more information about how Oracle Business Intelligence uses BISystemUser for trusted system communication, see Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.

2.8 Customizing the Default Security Configuration

You can customize the default security configuration in the following ways:

2.8.1 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 Section 2.4.1, "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 Fusion Middleware Oracle WebLogic Server Administration Console Online Help and Oracle Fusion Middleware Securing Oracle WebLogic Server.

2.8.2 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. For more information, see "Configuring LDAP-Based Policy and Credential Stores" in Oracle Fusion Middleware Application Security Guide.

2.8.2.1 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.

For more information about reassociation and the steps required to migrate credential store and policy store data to Oracle Internet Directory, see "Reassociating with Fusion Middleware Control" in Oracle Fusion Middleware Application Security Guide.

2.8.3 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 Oracle Fusion Middleware Application Security Guide.

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 Section 2.3, "Permission Grants and Inheritance.".

2.8.3.1 Creating Application Roles Using Fusion Middleware Control

There are two methods for creating a new application role:

  • Create New — A new application role is created. Members can be added at the same time or you can save the new role after naming it and add members later.

  • Copy Existing — A new application role is created by copying an existing application role. The copy contains the same members as the original, and is made a Grantee of the same application policy. You can modify the copy as needed to finish creating the new role.

To create a new application role:

  1. Log into Fusion Middleware Control, navigate to Security, then select Application Roles to display the Application Roles page.

    For information, see Section 2.6.1, "Accessing Oracle Enterprise Manager Fusion Middleware Control."

  2. Choose Select Application Stripe to Search, then select obi from the list. Click the search icon next to Role Name.

    The BI Publisher application roles display.

  3. 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, select the users, groups, or application roles to be mapped to the application role, Select Add Application Role or Add Group or Add Users accordingly. To search in the dialog box that displays:

    • Enter a name in Name field and click the blue button to search.

    • Select from the results returned in the Available box.

    • Use the shuttle controls to move the desired name to the Selected box.

    • Click OK to return to the Create Application Role page.

    • Repeat the steps until all members are added to the application role.

  4. Click OK to return to the Application Roles page.

    The application role just created displays in the table at the bottom of the page.

To create an application role based on an existing one:

  1. Log into Fusion Middleware Control, navigate to Security, then select Application Roles to display the Application Roles page.

    For information, see Section 2.6.1, "Accessing Oracle Enterprise Manager Fusion Middleware Control."

  2. Choose Select Application Stripe to Search, then select the obi from the list. Click the search icon next to Role Name.

    The BI Publisher application roles display.

  3. Select an application role from the list to enable the action buttons.

  4. Click Create Like to display the Create Application Role Like page.

    The Members section is completed with the same application roles, groups, or users that are mapped to the original role.

  5. Complete the Role Name, Display Name, and Description fields.

    Figure 2-16 shows an application role based upon BIAuthor after being named MyNewRole, as an example.

    Figure 2-16 Role Based on BIAuthor

    Description of Figure 2-16 follows
    Description of "Figure 2-16 Role Based on BIAuthor"

  6. Use Add and Delete to modify the members as appropriate and click OK.

    The just created application role displays in the table at the bottom of the page. Figure 2-17 shows the example MyNewRole that is based upon the default BIAuthor application role.

    Figure 2-17 MyNewRole Based on Default BIAuthor Role

    Description of Figure 2-17 follows
    Description of "Figure 2-17 MyNewRole Based on Default BIAuthor Role"

2.8.3.2 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. 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 — A new application policy is created and permissions are added to it.

  • Copy Existing — A new application policy is created by copying an existing application policy. The copy is named and existing permissions are removed or permissions are added as needed.

To create a new application policy:

  1. Log into Fusion Middleware Control, navigate to Security, then select Application Policies to display the Application Policies page.

    For information, see Section 2.6.1, "Accessing Oracle Enterprise Manager Fusion Middleware Control."

  2. Choose Select Application Stripe to Search, then select the obi from the list. Click the search icon next to Permission.

    The BI Publisher application policies are displayed. The Principal column displays the name of the policy Grantee.

  3. Click Create to display the Create Application Grant page.

  4. To add permissions to the policy being created, click Add in the Permissions area to display the Add Permission dialog.

    • Complete the Search area and click the blue search button next to the Resource Name field.

      All permissions located in the obi application stripe are displayed. For information about the BI Publisher permissions, see Section 2.4.2, "Default Application Roles and Permissions."

    • Select the desired BI Publisher permission and click OK. Repeat until all desired permissions are selected. Selecting non-BI Publisher permissions has no effect in the policy.

    • To remove any items, select it and click Delete.

    You are returned to the Create Application Grant page. The selected permissions display in the Permissions area.

  5. To add an application role to the policy being created, click Add Application Role in the Grantee area to display the Add Application Role dialog.

    • Complete the Search area and click the blue search button next to the Resource Name field.

    • Select from the Available Roles list and use the shuttle controls to move it to Selected Roles.

    • Click OK.

    You are returned to the Application Policies page. The Principal (Grantee) and Permissions of the policy just created are displayed in the table.

To create an application policy based on an existing one:

  1. Log into Fusion Middleware Control navigate to Security, then select Application Policies to display the Application Policies page.

    For information, see Section 2.6.1, "Accessing Oracle Enterprise Manager Fusion Middleware Control."

  2. Choose Select Application Stripe to Search, then select obi from the list. Click the search icon next to Permission.

    The BI Publisher application policies are displayed. The Principal column displays the name of the policy Grantee.

  3. Select an existing policy from the table.

    For example, Figure 2-18 shows the BIAuthor Principal (Grantee) selected and the Create Like button activated.

    Figure 2-18 BIAuthor Principal (Grantee)

    Description of Figure 2-18 follows
    Description of "Figure 2-18 BIAuthor Principal (Grantee)"

  4. Click Create Like to display the Create Application Grant Like page. The Permissions table displays the names of the permissions granted by the policy selected.

  5. To remove any items, select it and click Delete.

  6. To add application roles to the policy, click Add Application Role in the Grantee area to display the Add Application Role dialog.

    The following figures use the MyNewRole application role as an example.

You are returned to the Application Policies page. The Principal and Permissions of the policy created are displayed in the table, as shown in Figure 2-21.

Figure 2-21 Principal and Permissions of Policy

Description of Figure 2-21 follows
Description of "Figure 2-21 Principal and Permissions of Policy"

2.8.3.3 Changing Permission Grants for an Application Policy

You can change one or more permissions granted by an application policy.

To add or remove permission grants from an application policy:

  1. Log into Fusion Middleware Control, navigate to Security, then select Application Policies to display the Application Policies page.

    For information, see Section 2.6.1, "Accessing Oracle Enterprise Manager Fusion Middleware Control."

  2. Choose Select Application Stripe to Search, then select obi from the list. Click the search icon next to Role Name.

    The BI Publisher application policies are displayed. The Principal column displays the name of the policy Grantee.

  3. Select the name of the application role from the Principal column and click Edit.

  4. Add or delete permissions from the Edit Application Grant view and click OK to save the changes.