Secutiry Overview on OBIEE 11g

11g Security Overview:--

If you’re evaluating OBIEE 11g and working through the long list of new features, one of the topics that’s potentially most confusing is the new security setup. Whilst basic concepts such as object-level and data-level security are the same in 11g as in 10g, Oracle Fusion Middleware now comes into the picture and security is now much more aligned with the rest of the Oracle middleware stack. So what are the important things to know, how do we now administer users and groups, and how do we perform tasks such as linking security to Microsoft Active Directory?
As a starting point, let’s have a think about what we mean by security, and what tasks we want to manage as part of security. How about:

• Users logging in and out
• Lists of users and groups
• Connections through to external directories containing lists of users, groups and password
• Administration of all of this
• Application roles, and rights and permissions we assign to these roles
• Permissions on BI objects (subject areas, tables, columns, reports, dashboards etc)
• Permissions to use features such as Answers, Actions, Briefing Books and so on
• Being able to report against, and audit, security settings

Looking away from OBIEE specifically for the moment, in general terms security is considered to be made up of three topic areas:

1. Authentication – checking passwords and other tokens against user lists, to “authenticate” a user and check that they are who they say they are
2. Authorization – once we know who they are, what are we going to “authorize” them to do on our system.
3. Administration – how do we administer these lists of users, groups and permissions, plus connections to external directories and applications

To address these three requirements, OBIEE 11g has three security “providers” which are used together with various administration screens in the BI Administration tool, in the Presentation Server administration pages, in Fusion Middleware Control and in the WebLogic Server Admin Console. Overall, OBIEE 11g uses a feature of Oracle Fusion Middleware 11g called Oracle Platform Security Services (OPSS), the underlying security platform that provides security to Oracle Fusion MIddleware. OBIEE 11g delegates security to OPSS which uses features such as the Credential Store Framework, and the WLS LDAP Server to provide security for your BI system.
OBIEE Security Providers
So, where do we start with all this? Well, to take OBIEE 11g as a whole, this new releases relies on three “security providers”:

• An Authentication Provider, that provides the list of users and groups and authenticates their passwords. In 11g, by default this is provided by the WebLogic Server LDAP Server, but you can change it to use Microsoft Active Directory, Oracle Internet Directory or other third-party directory servers.
• A Policy Store Provider, again by default set to WebLogic Server, that provides a list of Application Roles and Application Policies. It’s these that are used in 11g to provide access to BI objects in the RPD and webcat, and provide access to tasks such as browse the RPD or execute agents.
• A Credential Store Provider, used for storing securely passwords and user details that are needed to secure interactions between components such as the BI Presentation Server and the Action Framework. In 10g, you used the credstore and cryptotools for this, in 11g it’s built into OPSS and WLS.

Most of the old 10g features for security are still there, so that you can, for example, use the BI Administration tool to link the repository to an LDAP server, and get hold of users and groups through Init Blocks and DBMS_LDAP. But users and groups themselves have moved out of the repository to the WLS LDAP Server, and the recommendation is to try and migrate old settings to the new setup, or at least use the new setup for new implementations.
The diagram below shows a schematic for Oracle Platform Security Services:

OPSS has a number of concepts and components that are worth being aware of:

• An Identity Store (by default, the WLS LDAP Server) contains the list of users and groups accessing your system
• A Policy Store contains the list of application roles, and application policies, specifying who can do what (fairly granular for java components, high-level for system components)
• A Credential Store contains securely stored usernames and passwords used for inter-application authentication
• All of the above can be handled internally in WLS, or “outsourced” to directories such as AD or OID

• Application Roles are the FMW11g way that we group sets of permissions which are then granted to users or groups
• Application Policies are the sets of permissions assigned to application roles
• The Embedded WLS LDAP Server replaces the list of users and groups in the 10g RPD

OBIEE 11g also comes with what’s termed the Default Security Configuration. This is the pre-built set of users, groups, application roles and application policies that are set up during install for new installations of OBIEE, and it means for example that to set up new users and groups you go to the WebLogic Server Admin Console where you’ll see them listed, like this:

Notice the “DefaultAuthenticator” entry under the Provider column in the user listing? That means that the WLS LDAP Server (the “DefaultAuthenticator” as set up in OPSS) is providing details of that user. If I connected ActiveDirectory or OID to OPSS, you’d see other authentication providers listed here, and you’d only be able to create new users when working with the WLS LDAP Server, using the external directory’s admin pages to set up users and groups for them.
This addresses the requirement for an authentication provider, and the default configuration also provides a default policy store provider, which is accessed through Fusion Middleware Control and allows us to create and maintain application roles, assign policies to the roles and then map our LDAP groups to these roles.

The Default Security Configuration provides a number of pre-set users, groups and application roles to get you started. Instead of a user called “Administrator” who belongs to the “Administrators” group as you got with 10g, you now have a user that is typically called “weblogic” (it’s actually the WLS admin username you specified during system install) that belongs to a group called “BIAdministrators” and which has the BIAdministrator application role granted to it. There are also groups called BIAuthors and BIConsumers which have the BIAuthor and BIConsumer application roles granted, and you can add new users, groups and application roles using the above two tools.

These particular roles in the policy store are recursive so that, for example, the BIAdministrator role is also granted the BIAuthor role, and the BIAuthor role is granted the BIConsumer role. So what then is an application role, and what is an application policy, and how do these relate to the RPD groups and webcat groups that you used to get in OBIEE 10g?
Application roles and policies are I guess the big new thing in OBIEE 11g security. Instead of defining security in terms of groups in the RPD or an LDAP server, OBIEE 11g uses a role-based approach to which permissions and privileges are assigned. Application roles represent a functional role (such as Marketing Analyst, Northern User) which a user has, which gives them the privileges to do that role. Creating this abstraction layer away from the physical groups that are found in an LDAP server gives you a number of advantages:

• You don’t have to grant BI access permissions based on whatever groups just happen to be your LDAP server,
• or more likely, find these are irrelevant to BI and therefore you have to roll-your-own groups, typically held externally in a set of database tables
• Also, you can bundle up these application roles and policies and export them as artifacts between different environments (dev and test, for example)

So what typically happens when you create users and groups, and assign them to application roles, is as follows:

1. Beforehand, you need to review the application roles you’ve got, and potentially create more appropriate ones that make use of the shipped application policies (to create webcat admins, for example, who can’t then go on to edit the RPD)
2. Either create your users and group in the WLS LDAP Server, or add a new authentication provider (and possibly, policy store provider and credential store provider) to connect to the users and groups in your corporate directory
3. Create mapping between your LDAP groups and your application roles, typically granting application roles to your LDAP groups
4. Manually add users to other application roles you’ve created, if your LDAP server doesn’t have appropriate or granular-enough groups
5. Go to the BI Administration tool and use these application roles to grant access to subject areas, and associate row-level filters to these roles
6. Go to the BI Presentation Server admin screen and grant permissions on BI objects, and on BI Presentation Server functionality, to these roles

What you don’t need to do anymore is have some init block system using DBMS_LDAP to go and retrieve group memberships from your LDAP server, as OBIEE 11g now has direct access to the server (through OPSS) and you’ll automatically see details of users, plus their application roles, in the Identity Manager within the 11g BI Administration tool, like this:

You also don’t need to create matching webcat groups for your RPD groups as these are now replaced by application roles, though catalog groups are still supported for backwards compatibility. For now though, that’s an overview of OBIEE 11g security, and I’ll follow this up over the next few days with two more postings; one on working with the default security configuration that ships with OBIEE 11g, and another on connecting OBIEE 11g and OPSS to Microsoft Active Directory, probably the most common post-install security task for 11g.