I was creating a new user in OBIEE 11G and the security settings seems to be completly different from that of OBIEE 10g. Before setting the Security it is good to have a basic knowledge of the basics jargons in OBIEE 11G.
Basic Understanding of the Security settings of OBIEE 10g and OBIEE 11g
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.
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:
Comparison of security settings of 10g and 11g
Security Settings of 10g
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.
Security Settings in 11g
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
Its All About Data - By Jethin Abraham 