Key Security Changes for Release 11g:
Some of the key changes in OBIEE security in 11g are
1. User and Groups are no longer defined in RPD
2. User Profile is derived from LDAP server
3. RPD is protected by RPD Password
4. RPD is encrypted
5. Introduction of Applications Roles
6. User Administrator and Group Administrators not hard-coded in RPD
7. Administrator user not used for Inter-Process Communication (component to component)
8. Credential Store storage mechanism
OBIEE 11g provides a scalable default security
mechanism available for immediate implementation after installation. The
default security mechanism provides controls to manage users and
groups, permission grants and credential store. Following are the
security controls that are available after the installation.
1. An embedded LDAP server in WebLogic available to store users and groups known as “Identity Store”
2. A file to store the permission grants information known as the “Policy Store”
3. A file to store user and system credentials for inter process communication known as the “Credential Store”.
Let’s look at the differences based on some of the common security concepts, Authentication and Authorization.
Authentication:
In 10g default
Authentication is RPD based. In 11g, the user and group definitions are
moved to a LDAP server embedded with WebLogic server known as the “Identity Store”.
Users and Groups can no longer be created in the RPD. Creation of Users
and Groups and the association of members to groups are managed in the
WebLogic administration console. WebLogic provides the default
authentication provider for OBIEE 11g. Users are authenticated by the
WebLogic server based on the credentials in the embedded WebLogic LDAP
server. The embedded LDAP server is default Authentication provider for
WebLogic and hence OBIEE.
OBIEE 11g gets user,
groups and other user attributes from the WebLogic LDAP server. This
also eliminates the limitation we had with previous versions of OBIEE
where only one Group for a user can be read directly from an LDAP
server.
The following screenshot shows the default Authentication provider.
WebLogic supports
integration with commercial identity management products (also known as
Authentication providers). The screenshot below lists some of the
Authentication Providers. OBIEE 11g certification matrix provides a list
of all supported Authentication Providers.
At this time, the following Authentication providers are supported by OBIEE 11g.
· Active Directory 2003, 2008
· SiteMinder 6
· OpenLDAP 2.2.x
· Sun Java System Directory Server version 6.3
· eDirectory 8.8
The
following screenshot shows the users created in the WebLogic
administration console. By default users and groups are created using
Oracle WebLogic Server Administration Console.
The following screenshot shows the groups created using WebLogic administration console
The following screenshot shows the groups created using WebLogic administration console.
The following screenshot shows the members associated to the groups in the WebLogic administration console.
The users and groups created in the
WebLogic administration console can be viewed in the OBIEE
administration console. Before looking at the users in the RPD, since we
are discussing about the changes in Authentication, I would like to
cover the RPD password. In OBIEE 11g, every RPD is protected by an RPD
password. Remember, there are no “Administrator” user and
“Administrators” group in OBIEE 11g. Look at the RPD creation screenshot
below. The RPD creation utility, requests a password to protect the
RPD. The same password is also used to encrypt the password. In 10g only
a few critical elements in the RPD were encrypted. In 11g, the entire
RPD is encrypted.
Let’s take a look at the users that were created in the WebLogic
admin console in OBIEE administration console. Note that the menu item
“Security” in 10g got changed to “Identity” in 11g.
In
the screenshot below, we see that the users created using the WebLogic
administration console and stored in the WebLogic embedded LDAP server
is being displayed by the OBIEE administration console.
Note
that there is no option to create a user or a group in the menu from
the screenshot below. The OBIEE administration tool only displays users
defined in the WebLogic embedded LDAP server. There is a new menu item
“Application Roles”. I will cover this when discussing the changes in
Authorization.
Even
though the underlying embedded WebLogic identity store is a LDAP
server, OBIEE server does not use the “Authentication” initialization
block for the default LDAP server embedded within the WebLogic server.
The default WebLogic authenticator is a replacement for the OBIEE
authentication for users defined in the RPD in 10g. This gives us two
options to integrate an external LDAP server with OBIEE for
authentication. The external LDAP server can be integrated with WebLogic
server as an additional authentication provider or by integrating the
LDAP server with OBIEE like in 10g by registering the LDAP server in the
RPD and creating an “Authentication” initialization block based on the
registered LDAP server. The recommended approach going forward is to
integrate all authentication providers at the WebLogic level.
In
my next blog entry I will discuss about the changes to “Authorization”
in OBIEE 11g, the applications roles, policy store and the credential
store.
Authorization:
Authorization
in 10g was achieved using a combination of Users, Groups and
association of privileges and object permissions to users and Groups.
Two keys changes to Authorization in OBIEE 11g are:
- Application Roles
- Policies / Permission Groups
Application Roles are
introduced in OBIEE 11g. An application role is specific to the
application. They can be mapped to other application roles defined in
the same application scope and also to enterprise users or groups, and
they are used in authorization decisions. Application roles in 11g take the place of Groups in
10g within OBIEE application. In OBIEE 10g, any changes to corporate
LDAP groups require a corresponding change to Groups and their
permission assignment. In OBIEE 11g, Application roles provide
insulation between permission definitions and corporate LDAP Groups.
Permissions are defined at Application Role level and changes to LDAP
groups just require a reassignment of the Group to the Application
Roles.
Permissions and privileges are assigned to Application Roles and users in OBIEE 11g compared to
Groups and Users
in 10g. The diagram below shows the relationship between users, groups
and application roles. Note that the Groups shown in the diagram refer
to LDAP Groups (WebLogic Groups by default) and not OBIEE application
Groups.
The following
screenshot compares the permission windows from Admin tool in 10g vs
11g. Note that the Groups in the OBIEE 10g are replaced with Application
Roles in OBIEE 11g. The same is applicable to OBIEE web catalog
objects.
The default Application Roles available after OBIEE 11g installation are BIAdministrator, BISystem, BIConsumer and BIAuthor.
Application policies are
the authorization policies that an application relies upon for
controlling access to its resources. An Application Role is defined by
the Application Policy. The following screenshot shows the policies
defined for BIAdministrator and BISystem Roles.
Note that the permission for impersonation is
granted to BISystem Role. In OBIEE 10g, the permission to manage
repositories and Impersonation were assigned to “Administrators” group
with no control to separate these permissions in the Administrators
group. Hence user “Administrator” also had the permission to
impersonate. In OBI11g, BIAdministrator does not have the permission to
impersonate. This gives more flexibility to have multiple users perform
different administrative functions.
Application Roles, Policies, association of
Policies to application roles and association of users and groups to
application roles are managed using Fusion Middleware Enterprise Manager
(FMW EM). They reside in the policy store, identified by the system-jazn-data.xml file. The screenshots below show where they are created and managed in FMW EM.
The following screenshot shows the assignment of WebLogic Groups to Application Roles.
The following screenshot shows the assignment of Permissions to Application Roles (Application Policies).
Note: Object
level permission association to Applications Roles resides in the RPD
for repository objects. Permissions and Privilege for web catalog
objects resides in the OBIEE Web Catalog. Wherever Groups were used in
the web catalog and RPD has been replaced with Application roles in
OBIEE 11g.
Following are the tools used in OBIEE 11g Security Administration:
·
Users and Groups are managed in Oracle WebLogic Administration console
(by default). If WebLogic is integrated with other LDAP products, then
Users and Groups needs to managed using the interface provide by the
respective LDAP vendor – New in OBIEE 11g
· Application Roles and Application Policies are managed in Oracle Enterprise Manager - Fusion Middleware Control – New in OBIEE 11g
· Repository object permissions are managed in OBIEE Administration tool – Same as 10g but the assignment is to Application Roles instead of Groups
· Presentation Services Catalog Permissions and Privileges are managed in OBI Application administration page - Same as 10g but the assignment is to Application Roles instead of Groups
Credential Store: Credential Store is a single consolidated service provider to store and manage the application credentials securely. The
credential store contains credentials that either user supplied or
system generated. Credential store in OBIEE 10g is file based and is
managed using cryptotools utility. In 11g, Credential store can be
managed directly from the FMW Enterprise Manager and is stored in cwallet.sso file.
By default, the Credential Store stores password for deployed RPDs, BI
Publisher data sources and BISystem user. In addition, Credential store
can be LDAP based but only Oracle Internet Directory is supported right
now.
As you can see OBIEE security is integrated with
Oracle Fusion Middleware security architecture. This provides a common
security framework for all components of Business Intelligence and
Fusion Middleware applications.
