OBIEE 11g Security Week : Understanding OBIEE 11g Security, Application Roles and Application Policies

This week, in preparation for the final, Security chapter of the book that I'm writing, I'm running through the key areas in OBIEE 11g and inviting feedback on what readers are encountering in the field. So far we've looked at row-level security and subject area/functional-area security, which are pretty-straightforward and haven't changed much since OBIEE 10g. Where things do start to get different, though, is when you start to look at where user details are stored, and how you administer the groups, or in OBIEE 11g application roles, that they are assigned to.

One of the biggest differences between OBIEE 10g security and OBIEE 11g security, is that users and groups are no longer held primarily in the repository; instead, these details are held by default in the WebLogic Server LDAP server, which gets installed alongside OBIEE when you install the product. Now, you create users and groups within this LDAP server, and administer these users and groups using the WebLogic Server Administration Console, shown below:

Within OBIEE itself, in common with all Oracle Fusion Middleware 11g-based products, you actually assign application permissions and privileges to application roles, not these LDAP groups. Behind the scenes, the LDAP groups and users in your WLS LDAP server are mapped to these application roles, allowing you to create simple 1:1 role to group mappings if you want, as shown in the diagram below:

or more complex, abstracted ones that give you the ability to map LDAP groups that don't necessarily map to the BI groups you'd like to use, to a set of application roles that do.

With OBIEE 10g, the security setup between the BI Presentation Server, BI Server and external LDAP directories and authenticators looked as in the diagram below, with the OC4J or other J2EE/IIS application server hosting the Analytics application and BI Publisher (amongst other front-end components), and the Presentation Server then authentication against the BI Server, which in turn may have contacted one or more external directories to provide authentication.

A credential-store was created, post-install, to hold the system user account details required to permit communication between BI Publisher, the Scheduler and BI Presentation Services, and all user accounts and groups were held in the BI Server, and replicated to the Presentation Server as users first logged in. Whilst this worked fairly well, the disadvantages were:

• The credential store was unmanaged, and held outside of the main server setup
• Options for connecting the BI Server to external directories, whilst simple, were limited compared to all the different types of authentication and authorisation mechanisms out there
• You either had to replicate all of your LDAP groups into the repository (and users, which could get unwieldy), or connect to an external LDAP server, accepting whatever group membership structure it presented to you, usually with the need for additional, external code to retrieve group details.

But at least, in hindsight, it has the virtue of simplicity.

OBIEE 11g, through its use of the Fusion Middleware platform, moves to an architecture where the BI Server no longer stores users and group details, no longer provides the actual authentication, but instead delegates this process to Fusion Middleware's Oracle Platform Security Services, so that the security architecture now looks like this:

The big difference here is that there's now a security abstraction layer within WebLogic Server (actually, within Fusion MIddleware 11g) called Oracle Platform Security Services, that provides three abstracted services for OBIEE, and for other Fusion Middleware-based applications:

• An Identity Store, which by default is set to use the embedded WebLogic Server LDAP server, but can be configured to connect to Microsoft Active Directory, for example,
• A Policy Store, containing details of application roles, application policies and the permissions that they use, that by default is stored in a file called system-jazn-data.xml but again can be redirected to an LDAP or file-based policy store, and
• A Credential Store, replacing the external one that OBIEE 10g used, which contains the usernames, passwords and other credentials that system services require, and again which can be externalised if required.

All of these services are registered through things called providers, and we'll look in more detail at providers and how you use them to link to Active Directory, for example, in tomorrow's post. For now though, just bear in mind that security has now moved to WebLogic and Fusion Middleware, and we're using the Fusion Middleware concept of application roles when we come to assign permissions and privileges to groups of users.

For now though, what does this mean in terms of setting up users, groups and these new application roles for an out-of-the-box installation of OBIEE11g? As shown in the diagram right at the start of this posting, an out-of-the-box installation of OBIEE comes with three main application roles that you can grant to individual users, or LDAP groups:

• 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

These roles correspond to a set of LDAP groups within the embedded WebLogic Server LDAP Server that have almost the same names (plural rather than singular) as these application roles:

• BIConsumers
• BIAuthors
• BIAdministrators

It's these LDAP groups that you assign users to, not application roles, with Fusion Middleware then mapping these LDAP groups into their corresponding application roles. Later on, we'll look at how and why you might want to create another LDAP group and corresponding application role like these, which we'll call BIAnalyst; for now though, let's look at how you create a new user and grant them one of the existing roles.

To create new users on an out-of-the-box OBIEE 11g system, you would use the Oracle WebLogic Server Administration Console, which can be accessed through your Web browser at http://[machine_name]:7001/console. The typical steps to create a new user, in this case called auser, are as follows:

1. Using your web browser, navigate to the Oracle WebLogic Server Administration Console, and log in as a user with administration privileges
2. When the Admin Console homage opens, click on the Security Realms menu item in the Domain Structure navigation tree menu.
3. When the Summary of Security Realms page is displayed, click on the myrealm link.
4. The Settings for myrealm screen will then be displayed. Click on the Users and Groups tab to start creating the new user.
5. Press the New button, and then enter the details for the new user, for example:
   
   Name : auser
   Description : Mr Andrew User
   Provider : Default Authenticator
   Password : welcome1
   Confirm Password : welcome1 
   
   
   Press OK once you're finished.
   
   
6. To add this user to one of the LDAP groups, and therefore grant them the corresponding application role, click on the user in the list of users that's displayed, and then click on the Groups tab.
   
   
7. Select an LDAP group, for example BIAuthors, from the Parent Groups Available pane, then move it across to the Chosen pane. Once done, press OK to complete the process.

So now you've created a new user and added them to the BIAuthors group; in the background - actually, in the policy store within Oracle Platform Security Services -  this ends up granting the user the BIAuthor application role as well, as this group has been granted this role in the OPSS policy store, which you can access in this way:

1. Using your Web browser, log into Enterprise Manager using the URL http://[machine_name]:7001/em, and enter the username and password of an administrative user.
   
   
2. When the Enterprise Manager homepage is displayed, navigate to the Business Intelligence > coreapplication menu item, then right-click on it. When the right-click menu is displayed, select Security > Application Roles.
   
   
3. The Application Roles page will then be displayed. Locate the BIAuthor application role in the list at the bottom of the page, click on it to select it and press the Edit button.
   
   
4. When the application role details are displayed, you will see two other objects that have been granted this role. One is the BIAuthors LDAP group, and the other is the BIAdministrator application role, so that this role inherits the permissions and privileges of this role.

So at this point, there are three administrative tasks that you might need to perform around the WebLogic LDAP server, and application roles and policies:

• You may have to create new application roles, and assign users to these, either through existing LDAP groups or by creating some new ones
• You may have to alter or create new application policies, and
• You may need to bundle up these application roles and policies, and other security settings, and migrate these to a new server.

We'll look at what's involved with these three tasks in tomorrow's posting.