OBIEE 11g Security Week : Managing Application Roles and Policies, and Managing Security Migrations and Deployments

In yesterdays blog post on OBIEE 11g security, we looked at OBIEE 11g's security architecture, and what's called the "Default Security Configuration". We looked at how new users were created and assigned to existing LDAP groups and application roles, and then left with three tasks that OBIEE 11g administrators would want to perform with this default configuration:

Creating new application roles, and assigning users and LDAP groups to them
Altering and creating new application policies (and understanding exactly what these are for)
Bundling up and migrating security settings across environments

Let's start with creating new application roles. In the second posting in this series, we looked at a couple of new application roles, QA Manager and HR Manager, that we then used to control access to subject areas within the catalog. These types of application roles, unlike the BIAdministrator, BIAuthor and BIConsumer application roles that come by default with OBIEE 11g, don't in themselves have privileges assigned to them, but we use them to grant access to subject areas, or do things like display sections of dashboards or provide access to catalog objects. To create such an application role, you'd need to:

Create the application role itself, using Enterprise Manager
Create the matching LDAP group, or identify which existing LDAP groups you want to map it the application role
Go back into Enterprise Manager and grant the role to these groups
Ensure your users are added to the relevant LDAP groups, and then
Go into the Oracle BI Administration tool, and refresh it's view of the current application roles in use.

So in this example, we'll create the two application roles that were used in the second posting, on subject-area and functional application security. The first role, QA Manager, will map back to a single LDAP group that we'll need to create for this purpose; the second role, HR Manager, will map to three separate existing HR manager LDAP groups that each will have this application role granted. This example was created using OBIEE 11.1.1.6, though the approach should work for all OBIEE 11g versions.

Using Enterprise Manager (http://[machine_name]:7001/em), log in as an administrative user, and then select Business Intelligence > coreapplication from the navigation tree menu.
With coreapplication selected, right-click on it and select Security > Application Roles
You are now presented with a list of application roles. To create a new application role called QA Manager, press the Create… button.
The Create Application Role page will then be displayed. Enter a name and description for the application role, using the singular for the name (e.g. QA Manager) and then press OK to create it.
Now you can create the corresponding LDAP group, and assign any required users to the group. Navigate using your Web browser to the WebLogic Server Administration Console (http://[machine_name]:7001/console), log in as an administration user, and select Security Realms > myrealm from the application menu.
When the Settings for myrealm page is displayed, click on the Users and Groups tab, and then select the Groups sub-tab when it is displayed. Then, create the new group using the plural version of the application role name you used earlier, i.e. QA Managers. Finally, add any required users to this LDAP group, and then exit the WebLogic Server Admin Console.
Now log back into Enterprise Manager and bring up the Application Roles page again. Click on the new QA Manager application role, and press the Edit button. To grant this new application role to its corresponding LDAP group, within the Members section press the Add button, and then select the LDAP group from the Searched Principals group. Once complete, you should see the LDAP group listed as one of the members granted this application role.
Finally, to make this new application role available within the Oracle BI Administration tool, close Enterprise Manager and then log into the administration tool, opening your repository online.

Now, select Manage > Identity… to open the Identity Manager, and then select Action > Synchronize Application Roles. You should now see this new application role listed under the Application Roles tab in the Identity Manager dialog.

At this point, you could now repeat the process to create other, similar application roles which could, for example, map more than one LDAP group into the role. An example of this might be where a single application role, HR Manager, has three LDAP groups; Northern HR Managers, Western HR Managers and Central HR Managers, mapped to it within its Members listing. For now though, let's look at another situation, where we wish to add a new application role to add to the existing BIConsumer, BIAuthor and BIAdministrator default application roles.

By default, OBIEE 11g ships with three application roles that you assign to users of your system:

BIConsumer, the base-level role that grants the user access to existing analyses, dashboards and agents, allows them to run or schedule existing BI Publisher reports, but not create any new ones
BIAuthor, a role that is also recursively granted the BIConsumer role, that also allows users to create new analyses, dashboards and other BI objects
BIAdministrator, recursively granted the BIAuthor (and therefore BIConsumer) roles, that allows the user to administer all parts of the system, including modifying catalog permissions and privileges

In some cases, you might want to add another role to this list, to fit between the BIConsumer and BIAuthor roles; one called BIAnalyst, that allows users to create and edit analyses, but not create new dashboards.

This requirement often comes up when there is a need for users to be able to create new analyses, but someone else then publishes those to dashboards. To create and configure this application role, after first creating a matching LDAP group that you'll map to it, you'll need to do to three things:

Create the role, and reconfigure the inheritance hierarchy in the policy store so that it inherits the permissions of the BIConsumer role, and the BIAuthor role in turn inherits its permissions
Re-configure Presentation Server catalog privileges so that the new BIAnalyst role becomes the lowest-level role that can access the analysis editor, with the existing BIAuthor role then inheriting this privilege

To create this additional role, you can either create a new role from scratch, or base it on an existing one such as BIAuthor, as we'll do now:

Using Enterprise Manager, log on as an administrative user and select Business Intelligence > coreapplication > Security > Application Roles.
When the list of Application Roles is displayed, select the BIAuthor role and press the Create Like… button. When the Create Application Role Like page is displayed, enter the details for the new role, calling it BIAnalyst and entering a suitable description.
Within the Members section, remove the existing BIAuthors group from the member list, and replace it with the LDAP group that you created to map to this role, i.e. BIAnalysts. Then, remove the BIAdministrator role from the Members list, and replace it with the BIAuthor role, so that the correct role in the hierarchy inherits this new role's permissions and privileges.

Press OK to close the dialog and create the new application role.
Now, edit the BIConsumer application role, remove the BIAuthor role from its list of members, and replace it with the new BIAnalyst role. This action now places the new BIAnalyst role mid-way between the BIConsumer and BIAuthor roles, so that each role is granted the correct roles under it in the role hierarchy shown in the diagram before, which is important for when we come to assign catalog privileges in the next step.
At the moment, catalog privileges in Oracle BI Presentation Services are configured such that only user granted the BIAuthor role can create analyses. To alter this so that users granted this new BIAnalyst role can also create analyses, log on to the Oracle Business Intelligence website (http://[machine_name:9704/analytics, typically) as an administrative user, and click on the Administration link, and then the Manage Privileges link within the Administration page.

Then, within the Access category, locate the Access to Answers item, and click on the BI Author Role link next to it. When the Privilege : Access to Answers dialog is shown, remove the BI Author role that is currently listed and replace it with BI Analyst, which you should assign the Granted Permission.

Now, this new role has the right to use Answers (the legacy name for the analysis editor), and as the BIAuthor role inherits (has been granted) the BIAnalyst role, it gains this privilege as well.
Now you can test out the new role, by creating a user and assigning it to an LDAP group corresponding to the BIAnalyst role, and then logging in as that user. You should see that this user can now create new analyses, but cannot create dashboards or any other BI content.

So that takes us through looking at creating and working with application roles, but what about application polices, the other entry under the Security menu that you see when you right-click on coreapplication in Enterprise Manager, What are they?

You can access the existing list of application policies by logging into Enterprise Manager and selecting Business Intelligence > coreapplication, then right-clicking on it and selecting Security > Application Policies. After selecting obi as the application stripe and pressing the Search Application Security Grants button, you should see a list of the existing application policies in your policy store. Each one will, by default, be named after the application role to which they apply.

So what is an application policy? Select the BIAuthor principal and press the Edit… button to take a look.

Application policies are sets of java permissions that are associated with a principal, in this case an application role. The BIAuthor application policy, for example, allows the user to develop reports and data models with BI Publisher, access Essbase administration and calculation functions, and perform other report-authoring tasks. What application policy permission classes explicitly don't cover, though, is privileges such as being able to access the analysis editor, create dashboards, or use other areas of repository or Presentation Server functionality that are controlled by permissions set in the Oracle BI Administration tool, or the Administration page in Presentation Services.

As such then, functional area privileges and permissions in OBIEE 11g are controlled in two places:

For applications written in Java, such as BI Publisher, Financial Reporting and Real-Time Decisions, you control their use by using application policies, whilst
For the C++ "legacy" components such as the BI Server and BI Presentation Server, you control them by their own in-built privileges and permissions

So when do you use application policies? If truth be told, in all the years I've worked with OBIEE11g, I've never had to alter or create an application policy, as the permissions they work with are outside of the usual catalog and repository permissions, but one example might be where you want the BIAnalyst role that we created a moment ago to have the permissions to create BI Publisher reports and data models, but not have any of the Essbase permissions that would normally be associated with the BIAuthor role on which it was based. To set this up, you'd need to:

Create an application policy based on the BIAuthor one, and grant it to the BIAnalyst role
Remove the permission classes from this new application policy that relate to Essbase

To do this, follow these steps:

With the Application Policies page open in Enterprise Manager, select the BIAuthor principal and press the Create Like… button
On the Create Application Grant Like Grant To : BIAuthor page, press Add button within the Grantee section, and select the BIAnalyst role.
Within the Permissions area, select the following permission classes by Resource Name and press the Delete… button to remove them from this application policy:

EPM_Essbase_Administrator
EPM_Essbase_Calculate
EPM_Calc_Manager_Designer
oracle.epm.financialreporting.editBatch
oracle.epm.financialreporting.editBook
oracle.epm.financialreporting.editReport
oracle.epm.essbasestudio.cpadmin

Once complete, your application policy should look as in the screenshot below:

Press OK once you have finished.

Now, when users with this corresponding application role try to make use of Essbase administrative or authoring features, their use will be denied as per the application policy that you have assigned to this role.

So to wrap up this posting; what do you do with these settings, contained in your policy store, if you wish to migrate them, along with any LDAP user and group settings and provider configurations, to a new server?

To migrate security settings from one environment (server) to another, you've got to migrate across three main sets of configuration settings:

The Identity Store settings (users and groups in the WLS LDAP server)
The Policy Store settings (application roles and policies)
The Credential Store (containing all of the stored usernames and passwords used by the BI Server, and system accounts)

Migrating these settings is largely a manual process, and Venkat covered the process in three blog postings a while ago:

So with that task taken care of, there's one more major area relating to security which, to be honest, is the area that most developers think of as tricky - connecting OBIEE 11g to external directories and authenticators, such as Microsoft Active Directory and home-grown security systems. We'll take a look at this topic in tomorrow, final post in this series.