OBIEE Security: User Authentication, WebLogic, OPSS, Application Roles and LDAP
Where and how are OBIEE users authenticated? A few options exists. A later blog post will review how to use the Oracle E-Business Suite to authenticate user connections and pass the E-Business Suite session cookie to OBIEE. Many if not most OBIEE users will though authenticate through WebLogic. For these users, they are defined and authenticated within WebLogic using it’s built in LDAP database or an external LDAP implementation. Once authenticated, the user’s LDAP group memberships are mapped to Applications roles that are shared by all Fusion Applications, OBIEE included.
WebLogic and Oracle Platform Security Services (OPSS)
As a Fusion Middleware 11g product, OBIEE 11g uses Oracle WebLogic for centralized common services, including a common security model. WebLogic Security Realms define the security configurations required to protect the application(s) deployed within WebLogic and consist of definitions of users, groups, security roles and polices.
If at all possible, Integrigy Corporation recommends using the default realm as a baseline to configure a new Realm for OBIEE. Integrigy Corporation highly recommends that each security realm attribute be thoroughly understood.
To implement Security Realm configurations, all Fusion Middleware applications use a security abstraction layer within WebLogic called the Oracle Platform Security Services (OPSS). OPSS is not the same as WebLogic security. WebLogic consumes OPSS services and frameworks (for example authentication). OPSS provides three key services:
- An Identity Store, to define and authenticate users
- A Credential Store, to hold the usernames, passwords and other credentials that system services require.
- A Policy Store, containing details of user groups and application roles, application policies and permissions. The policy store is used to authorize users (what can they do?) after they are authenticated.
Enterprise Manager and Application Roles
Application roles are new with OBIEE 11g and replace groups within OBIEE 10g. The migration of application roles out of OBIEE allows a common set of roles to be define across all Fusion Middleware products and applications.
Application roles and Application Policies are managed in Oracle Enterprise Manager - Fusion Middleware Control. This is where LDAP groups are mapped to application roles and detailed permissions are assigned to the application roles. The key concept is that LDAP groups can be assigned to both Fusion users and Fusion Application roles, LDAP users are never individually or directly assigned permissions and grants within OBIEE.
The out-of-the-box installation of OBIEE delivers three main application roles. These roles may be granted to individual users or to LDAP groups. During the implementation or at any time new roles can be created and existing roles changed.
|
Default OBIEE Application Roles |
||
|---|---|---|
|
Application Role |
LDAP Group* |
Description |
|
BIConsumer
|
BIConsumers |
Base-level role that grants the user access to OBIEE analyses, dashboards and agents. Allows user to run or schedule existing BI Publisher reports, but not create any new ones |
|
BIAuthor |
BIAuthors
|
All BIConsumer rights, grants and permissions but also allows users to create new analyses, dashboards and other BI objects |
|
BIAdministrator |
BIAdministrators
|
All BIAuthor rights, grants and permissions (and therefore BIConsumer) as well as allows the user to administer all parts of the system, including modifying catalog permissions and privileges |
*Note the naming convention difference of plural vs singular for Application Roles
If you have questions, please contact us at info@integrigy.com
-Michael Miller, CISSP-ISSMP
References
- Collaborate 2014 session OAUG – #14366 OBIEE Security Examined, Friday, April 11, 12:15pm
- OBIEE Security Examined - Webinar and Presentation: OBIEE Security Examined Webinar
- OBIEE Security Examined - Whitepaper: OBIEE Security Examined
