Tag Archives: Security

OBIEE 10g and 11g: Comparing Repository And Catalog Security Models And Changes With Upgrade

Applies to:

Business Intelligence Suite Enterprise Edition – Version: 10.1.3.2 to 11.1.1.5.0 [1308] – Release: 10g to 11g
Business Intelligence Suite Enterprise Edition – Version: 10.1.3.2 to 11.1.1.5.0 [1308]   [Release: 10g to 11g]
Information in this document applies to any platform.

Purpose

This document highlights the security features in Oracle Business Intelligence Enterprise Edition (OBIEE) and compares and contrasts features found in OBIEE 10g and 11g.

Questions and Answers

What documentation describes the security model for the Repository (RPD) and Catalog in OBIEE 10g?

OBIEE 10g security and repository access control are described in the Oracle Business Intelligence Server Administration Guide.

Web Catalog security and access control is described in the Oracle Business Intelligence Presentation Services Administration Guide.

What documentation describes the security model for the RPD and catalog  in OBIEE 11g?

OBIEE 11g security is described primarily in two places:

How are security settings enabled / controlled in OBIEE 10g and 11g?

In OBIEE 10g, security is controlled at the following points: permissions on the OBIEE Presentation catalog, via the repository (users and passwords) and optionally via an external LDAP, or external tables.

In OBIEE 11g, the security policy is split across the OBIEE presentation catalog, repository and default 11g identity store (embedded WLS LDAP), or external LDAP (i.e. OID or other if used).


What are the primary differences between the OBIEE 10g and 11g security models and what happens during upgrade?

Security Task/Object OBIEE 10g OBIEE 11g What happens during 10g upgrade to 11g?
Define Users and Groups in RPD file using OBIEE Admin Tool Default N/A. By default, users are defined in embedded WLS LDAP via FMW EM Console, or alternatively, in external LDAP. By default, existing users and groups migrated to embedded WLS LDAP. Existing groups are automatically mapped to an Application role.
Defining security policies Policies in the catalog and repository can be defined to reference groups within a directory Policies are defined in terms of application roles, which map to users and groups in a directory. 10g catalog groups are automatically migrated in the upgraded catalog and assigned the same privileges, access, and membership.
“Administrator” user Unique user with full administrative privileges No single user named for full administrative privileges. Administration can be performed by any user who is member of BIAdministrators group. “Administrator” user automatically added as member of “BIAdministrators” group in embedded WLS LDAP and granted Administrator role. The user specified during OBIEE 11g installation (i.e. “weblogic”, “biadmin”) is also a member of the BIAdministrators group.
Repository encryption Available on sensitive elements only – i.e. user passwords, connection pool passwords, etc. Entire RPD encrypted via a password. Prompted to set a repository password while running the upgrade assistant. Do not lose this password as there is no feature to recover a lost password.
External Authentication and OBIEE Initialization (Init) Blocks Init blocks are required for external LDAP or external table authentication. Init blocks not required for WLS embedded LDAP. Init blocks are required for external LDAP or external table authentication. Upgraded RPD will continue to point to 10g LDAP or external tables. Initblocks may need to be modified to ensure that deprecated, or reserved word, variable names are renamed.
NOTE: If you intend to use another LDAP server, such as Oracle Identity Management (OID), then you must upgrade to the embedded LDAP server first, then
migrate to the production LDAP server. Please see Upgrade Guide for further details.
Catalog Groups Defined in Presentation Server Administration link Available for backward compatibility. Use of Application Roles in FMW EM Console recommended. Existing groups will be migrated. Recommendation is to use application roles instead. Privileges on catalog objects may be granted to an application role via BI Presentation server Administration link.
SA System Subject Area Optional Available for backward compatibility and requires init blocks and external tables. Use of Embedded LDAP is recommended. Upgraded 10g RPD will point to external tables. Initblocks may need to be modified to ensure that deprecated, or reserved word, variable names are renamed.
“Everyone” Presentation Server Group Default Replaced with AuthenticatedUser role “Everyone” group migrated to AuthenticatedUser role.

Show Related Information Related

Accessing Groups in LDAP for use in Oracle Business Intelligence

This one is useful if you’re trying to set-up BI to work with LDAP

Oracle BI allows for integration with LDAP servers for authentication and security
out-of-the-box. This document articulates the solution for retrieving Security Groups
defined within LDAP and reuses them within the context of Oracle BI repository
seamlessly. This document assumes that the users are using an Oracle Database and can
leverage the DBMS_LDAP package built into the Oracle Database for this
purpose.

Typically Organizations use LDAP servers as a central infrastructure for storing the
Users security credentials and use these servers to authenticate and authorize users
access to various applications within the organization. Tapping into this security
infrastructure helps the organization maintain its security in a central infrastructure.

Currently, OBI EE can connect to an LDAP server and authenticate a user with
user and password credentials, but it is limited in its ability to extract the groups
defined within the LDAP server and to leverage these groups in the repository.

Scope and Application

The work around suggested in this paper would allow the admin to reuse the
groups in the LDAP server using the DBMS_LDAP package available within the
Oracle Database.

Accessing Groups in LDAP for use in Oracle Business Intelligence

The goal is to allow access to the Users and Groups defined within LDAP Server,
without having to redefine these in a database. This allows the enterprise to
leverage a single common security infrastructure and allows OBI EE to plug into
this infrastructure.
The following are the high level steps to access the Groups defined within the
LDAP server.
1. Using the DBMS_LDAP package provided within the Oracle Database,
write a stored function to connect to the LDAP Server and expose the
Groups as a virtual table.
This PL/SQL package creates a virtual table within the database, which acts as
a gateway to LDAP server. It is now possible to write queries in standard SQL
form to this virtual table that would in turn be translated to the LDAP server.
2. Provide parameters needed to connect to LDAP for authentication. In
order to do this, open the Administration Tool used for managing the
OBI EE repository. From Manage -> Security -> LDAP Servers menu,
provide the necessary parameters needed to connect to the LDAP Server.
(for additional details follow the steps detailed in the Server Admin Guide
for OBI EE).

The above picture is a sample of properties required for connecting to a LDAP
server.
3. The next step is to create a Session Initialization Block within the OBI EE
Admin tool and wire the LDAP server property to this initialization block.
The user id defined in the LDAP server should be associated with the “USER”
session variable. USER is a system session variable within the Oracle BI stack
and is used to store the USER information entered during login from the
presentation server.

4. Next, create another initialization block within the OBI EE Admin tool to
store the Group information. The group information will be queried from
the Virtual Table (defined as part of stored procedure/function defined in
step 1) and to get the group information using row-wise initialization. This
Initialization block should be executed after the Initialization block
defined in the previous step.

The screen shot above shows an example of the SQL query being passed to
the Oracle DB where the PL/SQL stored procedure (from step 1) was created
and extracting the Group information stored in LDAP using row-wise
initialization.

How do you enable SSO for an embedded OBIEE Report in Hyperion Workspace 9.3.1?

OBI EE and Hyperion Workspace / Smartspace integration was only introduced in EPM 11.1.1 and OBI EE 10.1.3.4.

To be able to have a seemless integration (No OBI EE Login Screen) when navigating from Hyperion Workspace 9.3.1 to OBI EE 10.1.3.4 you have the following options which might meet your implementation requirement: –

1) Use the ‘&NQUser=uuu&NQPassword=ppp’ URL arguments.

These are detailed in the section ‘Incorporating Oracle Business Intelligence Results into External Portals or Applications Using the Go URL’ of the Presentation Server Guide.

2) Enable OBI EE to use SSO. We support any SSO Vendor (SiteMinder, ClearTrust, Oracle SSO, Java SSO, etc…) which supports either HTTP Headers, Server Variables or Cookies.

Please see Chapters 8 and 10 of the Deployment Guide for more information on this area of functionality.

Neither of these options have been designed specifically for Workspace, but they should give you a generic option to implement a solution where no login is required when navigating to OBI EE from Workspace.

3) Just create a custom Init Block and custom session variable. Make the session variable to be initialized with the password. The query for the password initialization would be

SELECT ‘:PASSWORD’ FROM DUAL

Now, go to answers and create a report which would generate the Smartcut link. To this link pass the username (through the USER system session variable) and the password (through the custom session variable above). This will enable seamless login.

4) Enable BI EE to use the Table Authentication method, where usernames and passwords are stored in a database table. Passwords would be stored in encrypted form using obfuscation packages provided with the database.

Then create a report which would generate the Smartcut link. To this link pass the username (through the USER system session variable) and the password (through EVALUATE and a reverse obfuscation package function which would return the password in clearcase) in the report.
Then just use this report in the dashboard for providing the link. This will provide a seamless login.

5) I believe Workspace supports Impersonation. Technical Support have not tested this but it should work if the impersonation is possible. Using the same report approach above pass the Administrator username and password in the URL (these would be static) and also pass the actual BI EE username as the impersonation user in the URL. Provider services and Essbase JAPI support impersonation. We assume Workspace should support that as well. But of course, if its not supported then this would not work. Please liaise with Hyperion Technical Support or a Consultancy Department like Expert Services to look into this option further.

The above options are only supplied as possible workarounds, but Technical Support highly recommends that you upgrade to Hyperion Workspace 11.1.1 so you can leverage the built-in integration functionality.

OBIEE and enterprise architecture.

Sometimes, the challenges get to us from where we don’t expect them to come from. Imagine, your OBIEE application has been developed and tested – and you’re ready for production. And this is definitely the area that your biggest challenge might come into play. I’ve worked on numerous OBIEE projects where security was a paramount priority for production servers. Deploying OBIEE was a big pain for various reasons, such as:

1. Restrictive access (or no access at all) to production server for OBIEE team. This is definitely a killer issue, since it’s inviting so many things to go wrong. You might not be able to troubleshoor repository, check DB connections, run various OBIEE scripts, and a lot more. Also, you need to train the infrastructure team on being OBIEE server admins, which is a challenge (unless you have a dedicated OBIEE team). A big risk factor is timing – your work might get delayed, because your request for services restart takes a few days to complete.

2. OS / Software / Platform issues. Your application might work fine on your test and development servers, however, in most cases you loose any control leverage once you move to the production. OS patches, Database patches, restrictive firewall policies might cause many things to break (some of the things I can think of – LDAP Authentication, Ibots). Worst thing is that you might not even be aware of any changes if you’re not on the technical infrastructure priority list. Usually, the server people are overworked – having to provide support to hundreds of web applications in a large enterprise, so you might want to develop good working relationship from the start.

3. Network connectivity. This might happen at large projects, as well as small ones. Due to today’s networking complexities and proliferation of cloud computing, your related servers (authentication, data-sources) might be located in a different building / state / country (I’m not joking). As such, the network lagging issue might be affecting your OBIEE application in the worst ways possible. Always check this immediately after deploying and make sure that you don’t see any increases in ping times.

This is it for today. Please come and read again

Strange Presentation Services behavior

While auditing our OBIEE security model We’ve stumbled into behavior that we think is a bug. If it’s not, then I hope it’s a feature that would be removed in the future. Here’s a description of how we get this particular Presentation services behavior:

1. Summary – Our goal is to be able to add new users in RPD in online mode, assign them to their respective repository security groups ( based on data-level and row-level security), and during their first login  have them automatically assigned to one of 2 appopriate Presentation catalog group (that is used for presentation security, such as prohibiting overwriting of shared reports). We use OS authentication model with Impersonator (OBIEE picks up and strips users’ OS username). However, the problem doesn’t seem to be SSO-related or OS-related.

These’re steps to reproduce:

a) create new user “test_user1″ in RPD “Business Intelligence” group (for Presentation group “Business Intelligence”). Check-in RPD and save it.

b)  login with the “test_user1″ first time to OBIEE

c) go to My Account. You can clearly see that “test_user1″ is a member of Presentation group “Business Intelligence” (which is good for us and correct at the same time)

d) log-out. close browser. clean cookies. log-in as an administrator (member of Presentation Services Admin). Go to Settings –> “Oracle BI Presentation Services Administration”–>”Manage Presentation Catalog Groups and Users”
Select Edit for the “Business Intelligence” group

as you can see – “test_user1″ isn’t there

e) If we click on “Add New Member”-> “Show Users and Groups” – there’ll be a red-stop symbol (padlock image)

We’ve filed an SR with Oracle Support, and still waiting for an answer. I personally think that in future OBIEE releases – the Presentation Services should be tied closer with BI server – maybe going as far as consolidating those 2 modules.

And have a nice work week!