In the previous blog post, I explained some of the background behind OBIEE 11g's security changes, and how 11g leverages Oracle Fusion Middleware's Oracle Platform Security Services to provide direct access to LDAP servers, and new features such as application roles, application policies and policy stores. In this posting, I'm going to walk through some common admin tasks using what's called the Default Security Configuration, which provides access to users, groups and roles all stores in the WebLogic Server embedded LDAP Server. In the next posting in this series, I'll move beyond the default configuration and show how external directories such as Microsoft Active Directory can be incorporated into this setup.
So in this first scenario, I've got some regional managers from our company who I want to grant access to store data, but just for their region. I also want to set up a general administrator who can do anything, and a webcat administrator who can only manage the web catalog. To do this, I'll need to perform a number of tasks:
- Using Oracle Fusion Middleware Control, create application roles for each of the regions, and also another role for webcat administration.
- The regional application roles won't have application permissions assigned to them (they'll just be used to grant access to RPD and webcat objects), but I'll need to assign application permissions to the webcat administrator role, so that Oracle Platform Security Services will let them perform this function.
- I'll then go into the BI Administration tool and grant access to subject areas and table rows for the regional application roles.
- I'll do the same for BI objects in the web catalog, again based on application roles, and restrict access to
- Next I'll then create corresponding groups in the WLS LDAP server using WLS Admin Console, create the users and add them to the groups.
- Going back to FMW Control, I'll then assign the relevant roles to the groups, completing the process.
So the only real extra tasks in this are because of the indirection between groups and application roles, and the need to roll-my-own webcat admin application role that grants admin privileges but only to the webcat (not the RPD). So let's start by going into Fusion Middleware Control and set up the application roles and policy store permissions that we'll need for this arrangement.
I log in to FMW Control as weblogic/welcome1, then right-click on coreapplication and select Security > Application Roles.
The list of security roles that are initially shipped as part of the default security configuration are then shown on the screen. The list consists of one designed for system tasks (BISystem) plus three for providing varying degrees of access to OBIEE (BIConsumer, BIAuthor and BIAdministrator).
Notice also the details of the Policy Store Provider above the roles, which shows that we're using the built-in XML provider that comes with WebLogic Server.
So now I've got two tasks to perform. One is to create new application roles for the regional managers (North SF, Central SF, Other USA etc) that won't have any application permissions associated with them, but will be used to grant access to RPD objects and webcat objects. The other is to create a cut-down version of the BIAdministrator application role that only grants admin rights on the web catalog. For all of these, I use the Create... button above the list of existing application roles to create the set of new ones. Pressing this button brings up a dialog where I can name the new role, and at this point I don't map any existing groups or other roles to it.
Once complete, my extended list of roles looks like this:
Now whilst the regional manager roles won't have application permissions assigned to them, the new BIWebCatAdministrator will need a subset of the full admin permissions given to it. To specify these, I navigate to the coreapplication entry on the left-hand side of the screen and this time right-click and select Security > Application Policies.
Bringing up this option shows us the permissions assigned to each of the application roles (in other words, the application policies for each of the roles).
If you look at the permissions granted to the BIAdministrator role, you'll see a couple that related to the RPD and webcat:
- resourceType=oracle.bi.server.permission,resourceName=oracle.bi.server.manageRepositories
- resourceType=oracle.bi.presentation.catalogmanager.permission,resourceName=oracle.bi.presentation.catalogmanager.manageCatalog
The first one governs access to the RPD administration functions, whilst the second is the same, but for the web catalog. So my plan now is to grant the same set of permissions to the new BIWebCatAdministrator role, and then remove the oracle.bi.server.manageRepositories one to restrict administration to just the RPD.
To do this, I select the BIAdministrator principal and then press the Create Like... button, like this:
When the Create Application Grant Like dialog is then shown, I highlight the RPD permission and press the Delete button to remove it from the grant.
I then navigate down to the Add Application Role button below the list of permissions, and press it, in order that I can select the BIWebCatAdministrator role.
Pressing this button brings up the Add Application Role dialog, which I use to select the BIWebCatAdministrator role.
I now press OK, and then OK again, and I can then see the new role with its permissions that are a subset of the BIAdministrator's privileges.
So if you take a look through the sets of permissions that are assigned to each of the groups, you'll see that for the java components within OBIEE (BI Publisher, RTD, some Hyperion products such as the Calc Manager) there are fairly granular permissions such as being able to run a report, develop a report, deploy a report and so on.
For the system components such as the BI Presentation Server and BI Server the permissions are limited to administrators and are all about editing the RPD and catalog, which means that for more granular control over these areas, you'll need to use the BI Administration tool and the Presentation Server administration web pages. This is because these permissions really only work in a java context and the only real limitation they can put on more traditional aspects of OBIEE are to grant the ability to edit the RPD and catalog, and OBIEE then falls back on the traditional permissions maintained in the BI Admin tool and the webcat admin page (shown below) to grant the ability to run reports, access answers, create charts and so on.
So now that the roles are now created, it'd be worthwhile checking in the BI Administration tool to make sure they are working. Before they'll show up in the tool though, you'll need to bounce the BI Server, so keeping within Fusion Middleware Control navigate to the Capacity Management > Availability tab, highlight the BI Servers line and press the Restart Selected button.
Then to view the new roles in the BI Administration tool, select Start > Programs > Oracle Business Intelligence > BI Administration, then select File > Open > Online..., then enter the RPD credentials, then select Manage > Identity... When the Security Manager dialog is shown, switch to the Application Roles tab on the right-hand panel and you'll see the new roles available, like this:
So now I've got some application roles, let's do something with them. I'll start by restricting my Sales - Store Quality subject area to just my regional managers and administrators, stopping just general users from viewing it. To do this, I double-click on the Sales - Store Quality subject area in the Presentation Layer, like this:
When the Properties dialog is then shown (after checking out the objects from the RPD), locate the Permissions button and press it.
When the Permissions dialog is shown, tick the Show all users/application roles tickbox, and then set the permissions so that BIConsumer role no longer has read/write access but the new regional manager roles do, like this:
Press OK to save the object permissions. Then, from the application menu select Manage > Identity... again, click on the Application Roles tab, and double-click on the BINorthSFManager role to bring up its properties. When the properties dialog is shown, press the Permissions... button again to display the User/Application Role Permissions dialog, like this:
The dialog by default shows the object permissions granted to this role, and it shows the access settings we just defined a moment ago. To create a filter so that this particular regional manager role only sees quality scores for their own region, click on the Data Filters tab and then press the Add button, like this:
When the Browse... dialog is then shown, I leave the Presentation tab selected (so I only restrict access to store data when viewing QA data), locate the Dim Stores logical table and double-click on it, like this:
This then takes me back to the User / Application Role Permissions dialog, with the Dim Stores presentation table selected, like this:
Next, I click in the Data Filter column for this permission entry, and then press the calculator (Edit Expression) button. Using the Expression Builder dialog, I create a filter that restricts the query to just store rows that have North SF as the region.
I finally press OK, OK and then save and close my repository to complete this step. In reality, I'd repeat this step for all of the other regional manager roles that I've created, and probably apply similar row-level security to the other subject area as well.
So now that I've set up the application roles, assigned permissions to create a policy and used these roles to secure access to RPD objects, I can head over to the WebLogic Server Admin Console to create the actual users and groups. After I've done that I'll go back to Fusion Middleware Control, assign these roles to the new LDAP groups and test it all out.
I navigate to the WebLogic Admin Server Console, log in as weblogic/weblogic, and then locate the Security Realms entry under the bifoundation_domain entry in the Domain Structure list, like this:
Security Realms are an Oracle Platform Security Services concept and bring together sets of users, groups, providers and so on for a WebLogic domain. Only one security realm can be active at any one time, and the default one that is set up for OBIEE 11g and which provides the default security configuration is called myrealm. When the list of realms are displayed, as in the screenshot below, I select myrealm to proceed to its administration screen.
The WebLogic Server Admin Console then displays the settings for this realm, broken down into users, groups, providers and the like. By default, the users, groups and other details of this realm are stored in files on the WebLogic Server, but using the RDBMS Security Store option I've highlighted below, I can persist this information in a relational database instead.
For now though I'm going to start by clicking on the Users and Groups tab, and then selecting the Groups sub-tab. This displays a list of the groups set up as part of the default security configuration.
In the default security configuration, groups are set up to match the application roles but with their names set as plural (BIConsumers vs. BIConsumer, for example.) I therefore create six new groups, five for the new regional manager groups and one for webcat administrators.
To do this, I press the New button and create the first of the groups:
Notice the group name being plural, and the (authentication) Provider being set to DefaultAuthenticator, in other words the built-in WLS LDAP Server. If I had another, external directory set as the primary authentication provider then I wouldn't be able to create new groups here, I'd have to do it in the Active Directory Management Console, or the equivalent for OID, or whatever. I create the rest of the groups and my listing now looks like this:
I then switch to the Users tab and create two users, one, "w_c_admin" being a web catalog administrator, and another, "nsf_manager" being a North SF regional manager.
I then click on the nsf_manager user to display the user properties dialog. I switch to the Groups tab, and select the BINorthSFManagers group for him.
I don't need to additionally assign the BIConsumers group to this user as I'll ensure the BINorthSFManager application role (to which this group will be mapped) includes the BIConsumer application role later on.
I do the same for the w_c_admin user, assigning it to the BIWebCatAdministrators group.
Unlike new or changed application roles and policies, new users you create in the WebLogic Server LDAP Server will appear automatically in the BI Administration tool. To check this, I log out and log into my online repository, select Manage > Identity and view the new users visible in the Security Manager dialog.
So far so good. Out of curiosity, I double-click on the nsf_manager user to see what application roles have been assigned to him (I'm assuming, none). Interestingly, the BIConsumer application role has been assigned. So why is this then?
Well not having the BINorthSFManager role is understandable, as I haven't yet granted this to the BINorthSFManagers LDAP group yet (I'll do that in a moment). But given that I've not done any mapping at all, why has the user got the BIConsumer role (and therefore can log in, run reports and so on)?
To find out, I switch back to Fusion Middleware Control to do the last task in the set, to map the new LDAP groups to the new application roles and also find out why new users can automatically log in and run reports. To do this, I log in as weblogic/welcome1, right-click on coreapplication and select Security > Application Roles.
Well there's the answer to the question. The BIConsumer application role has been granted to the authenticated-user group, which is a catch-all group in OPPS that includes all users that manage to log in successfully. As such, any WLS LDAP user that authenticates will be able to access OBIEE and run unsecured reports, and to remove this feature you'd need to remove the authenticated-user group from the list of groups given the BIConsumer application role.
Assuming that this loophole might get removed in your company, it's probably good practice then to grant the new regional manager groups the BIConsumer role, so that they'll be able to get basic access if it's removed. To do this, I select the BIConsumer role, click Edit... and then add the regional manager groups to the role (granting them the role).
I now need to map the various regional manager LDAP groups to the corresponding application roles. To do this, I start first with the BICentralSFManager application role, select it in the application role list and click Edit... I then add the BICentralSFManagers group to this role, creating the mapping between the role and the group.
I then repeat this for the other regional manager application roles, and the webcat administrator role, so that my list of application roles looks like this in the end:
Finally, I add the BIWebCatAdministrator application role to the BIAuthor application role, so that this new administration role inherits all of the permissions of the roles underneath it.
So now we're good to go. To make sure all the changes are picked up I go and restart all system components, and then I close the web browser and go over to the BI Administration tool's Security Manager dialog. Taking a look at the w_c_admin user, I can see it's now been granted the right application roles.
If I try and log into the BI Administration tool as this user, access is denied. If I try and log into Presentation Services though, I can get in and create and view reports. If I log in to Presentation Services as the nsf_manager user though, whilst I can run reports I can't create new ones (I've not been granted the BIAuthor role), and if I run reports that include the Dim Stores table, results are filtered so that only North SF branches are shown.
So there you go. That's how the default security configuration works, and how you add new users, groups and application roles to Oracle Platform Security Services. In the final posting in this series, I'll look at how you can connect all of this to Microsoft Active Directory, using OBIEE's new ability to connect directly to Active Directory through OPSS.