1 Scope
The blog is only
relevant for Oracle® BI EE 11g versions (11.1.1.3.0, 11.1.1.5.0 and
11.1.1.6.0). The same security model is not applicable to any prior version of
Oracle® BI EE or Siebel Analytics.
2 Introduction To Security
The latest version of Oracle® Business
Intelligence Enterprise Edition (11.1.1.X.X) has come up with many new features
that were not even thinkable in its prior versions. Not only new reporting
features, it also managed to decouple its earlier security model to map into
the latest state of the art Fusion Middleware Security model that is the
standard across many other Oracle products. In this document we will revel step
by step all the critical components of this new security model so that reader
can themselves configure the security model as per their project need.
The security model of any application
normally spins across some basic concepts like –
1>
Authentication
2>
Authorization and
3>
Data Visibility
Therefore, before we go to the details of
the Oracle® BI EE 11g security model let us understand these basic concepts of
security in any software application. Then we will discuss in details how they
are implemented in Oracle® BI EE 11g.
2.1 Concept: Authentication
Authentication is a mechanism that ensures
that the user who is trying to access the application is a valid user of the
application. The basic approach of authentication involves checking the user
id/name along with his/her credentials with a set of reference user-credential
combinations pre-stored in the application domain. If the credentials provided
through the login page are valid then the user will be given the access to the
application. Otherwise the access will be denied.
The authentication might involve credential
token exchange through secure mediums like smart cards and stored certificates.
The details of such authentication are beyond the scope of this document.
2.2 Concept: Authorization
Authorization is a systematic approach to
determine the access of the user to a set of resources and functionalities to
accomplish their functional responsibilities.
For example in a CRM system there may be a
set of Operators who will access the CRM system to enter new customer or order
information, thus they need read write access to the components that involve
customer or order creation. But an Auditor of the same CRM system needs only
read access to the components so that he can validate the inserted information
with the references. Notice, here both the Operator and the Auditor are
authenticated user of the CRM System but they have different authorized
responsibilities.
2.3 Concept: Data Visibility
Data visibility is a more restrictive
approach of authorization where the user’s access is limited to a set of data.
Every incoming user will be assigned a token (some kind of ID) that will be
used to filter the data available to view or modify for that user. One very
good example of data visibility is corporate auto salary slip. The webpage that
generate the auto salary slip for an organisation is same for all the users,
but based on the employee number it shows only the information relevant to that
employee.
In the following sections we will discuss
how these above concepts are implemented and extended to provide a flexible and
reliable security model in Oracle® BI EE 11g.
3 Oracle BI EE Security Implementation
The three main security concepts that are
discussed in the previous section will be elaborated here with the reference of
Oracle® BI EE 11g and each of them will be discussed with their implementation
details in the remaining practice sections of this document. But before we
continue our journey to those details it will be better to understand the
security related changes that the Oracle BI EE 11g has over Oracle BI EE 10g.
Key changes in OBIEE security in 11g can be
listed as -
1. User
and Groups are no longer defined in RPD
2. User
Profile is derived from LDAP server (by default embedded in Weblogic Server)
3. RPD
is encrypted and protected by RPD Password, the password for default RPD is Admin123
4. Introduction
of Applications Roles
5. Any User having proper role can be an Administrator
6. Credential
Store storage mechanism, Oracle wallet
Oracle® BI EE as mentioned earlier has
extended the basic security concepts to cover many application specific areas.
The following is the general relation between the basic security concepts and
the Oracle® BI EE specific implementation steps.
Basic
Concept
|
Oracle
BI EE Implementation
|
Authentication
|
Authentication
(Weblogic embedded LDAP)
|
Authorization
|
Repository
Object Authorization
|
Webcatalog
Object Authorization
|
|
Application
Privileges and Permissions
|
|
Data
Visibility
|
Row
Level Security
|
Chart
3.0.1
But before we go into the details of each
of these concepts we have to understand the relationships between some security
elements of Oracle BI EE 11g which help us to implement the above requirements.
These elements are Resource Permissions, Application Policies, Application
Roles and Weblogic Groups (or LDAP Groups).
3.1 Application Policies
The grant of resource permissions to different
Application Roles or Weblogic (LDAP) Groups or Users is commonly known as
application policy. Resource permissions are fixed for Oracle BI EE application
and cannot be created for any custom Oracle BI EE implementation. But administrators
can arrange or assign them properly to create their custom Application Policy.
For example if administrators want to
create an Application Role ‘Impersonator’ and want all the member of this
Application Role to be able to impersonate other Oracle BI EE users then they
have to create an application policy for this Application Role and have to
assign oracle.bi.server.impersonateUser permission to this role. Once it is
done all the member of this Application Role will have impersonate privilege.
Image
3.1.1
3.2 Application Roles
Application Roles are similar in some sense
with its older version of Repository or Webcatalog groups. But the main
difference is that they are no longer defined in the Repository file or inside
the Webcatalog. They are defined in the Enterprise Management console (i.e.
/em) and accessed across Repository and Webcatalog to provide object access and
application privileges. In Oracle BI EE, Application Roles bridge the
permission link between the Weblogic Groups (or LDAP Groups) and Oracle BI
Objects. The application comes with four default Application Roles BISystem,
BIAdministrator, BIAuthor and BIConsumer. BIConsumer has minimum access
privilege and it can only access or view different Oracle BI components.
BIAuthor role provides access to create new BI objects like new analysis,
dashboards or reports. BIAdministrator manages the administrative
functionalities of the application whereas the last role BISystem is
responsible for impersonation and such other system privileges. Other than
these predefined Application Roles administrators may create as many
Application Roles to define and manage their own BI resources (like report,
catalog folder etc).
Image
3.2.1
3.3 Weblogic Groups
Oracle BI EE 11g comes with a default LDAP
server embedded in Weblogic Application Server 10.3.X. This LDAP server defines
and stores the set of users and groups for the application. The users are
assigned one or more groups and those groups are internally mapped to different
Application Roles in the Enterprise Manager. Just like default Application
Roles, the implementation comes with a set of default Weblogic Groups BISystem
BIConsumers, BIAuthors and BIAdministrators. These Weblogic Groups are directly
mapped to their corresponding application roles in em.
Image
3.3.1
3.4 Oracle BI EE Authentication
Oracle BI EE 11g is a part of Oracle Fusion
Middleware applications and thus its security mechanism is closely aligned to
the Fusion Middleware security principles. The heart of the authentication
mechanism is the Identity Store which is comprised of an LDAP server embedded
in the Weblogic Application Server. The
application server provides reliable access to the Identity Store using Oracle
Platform Security Services (OPSS).
Image
3.4.1
In this new version the end user connects
to the login page of the analytics application and the credentials are passed
from the login page to the BI Presentation Services, BI Presentation Service
then pass the credentials to the BI Server for validation. BI Server connects
to Oracle Identity Management deployed on Weblogic server and authenticates the
user.
If the users are defined in any other LDAP
server other than the default WLS LDAP server then the Administrator only have
to integrate that LDAP server in Weblogic server and users will be available to
access Oracle BI EE 11g. This is the recommended approach to implement any
non-default LDAP authentication.
3.5 Oracle BI EE Authorization
Oracle BI EE 11g has an implementation of
many fold authorization. To understand the concepts properly we will discuss
them in separate sections. We will also coven them in the practice sections
(Practice Section Five to Seven).
3.5.1Repository Object Authorization
Oracle BI EE 11g Repository has many
metadata objects that can be configured with access control. Subject Areas,
Presentation Tables, Presentation Columns are examples of that. If users go to
the ‘properties’ of these objects and click on the permissions button, it will
show them all the application roles defined in the ‘em’ console. They have to select
the proper privileges for these application roles as per their security
requirement to implement Repository Object Authorization.
The following image (3.5.1.1) shows the
implementation of Repository Object Authorization for a column. In the image we
have a security sensitive presentation column ‘Credit Rating’. The column has
read privilege only to BIAdministrator and BIAuthor application roles.
BIConsumer does not have any access to this security sensitive column. If users
select this column to an analysis along with other non-security sensitive
columns, this column will be visible to only the users having BIAdministrator or
BIAuthors as their Group. For the rest of the users this column will be hidden
but the other non-security sensitive columns will be visible.
Image
3.5.1.1
3.5.2Webcatalog Object Authorization
Just like Repository, every webcatalog
contains many reporting objects like Folders, Analysis, Dashboards, Filters etc
and each of them can be configured to have different security setup. If users
click on the ‘Catalog’ link it will
show them all the objects available. Under every such object they will find a ‘More’ link which will show a popup menu having
an option called ‘Permissions’. This option
will open a Permission dialog box where user can provided access rules.
Image
3.5.2.1
Available permissions for any webcatalog
objects are –
Full: Can
perform any operations on the contents
Read: Only
read the contents
Traverse:
Only traverse the folder but cannot read the contents
Write: Can
write to the contents
Delete: Can
delete the contents
Other permissions are Change Permissions,
Set Ownership, Run Publisher Report, Schedule Publisher Report
and View Publisher Output.
3.5.3Application Privileges and Permissions
Oracle BI EE Presentation Service hosts the
Webcatalog folder that is the source of all the report metadata present in the
application. These report metadata is used to build the actual reports at
runtime and we get different presentation functionalities like Dashboards,
KPIs, KPI Watch Lists, Score Cards and the ad hoc Analysis. But these different
functionalities are strictly controlled by the access control mechanism of the
tool that can be accessed through any Administrative user.
When an Administrator logs on to the web
portal ‘analytics’ he will have an additional link on top named ‘Administration’. This link open the
administrative page and you can modify the Application Role based Privileges
for different functional areas. Administrator can also assign User based
privileges but that is less flexible.
Note :
The Administrator can show/hide Subject Areas from this place as well. This
will only restrict the users to access those Subject Areas in Analysis. The
pre-build reports or dashboards from that subject area will still be visible to
that user groups.
Image
3.5.3.13.6 Row Level Security
In Oracle BI EE Data Visibility or Row
Level Security is done using column filters on Application Role. To set this
administrators have to open the Identity Manager and double click on any of the
available application roles.
Each Application Role has a permission
section where the column based filters can be defined. These filters will be
added to the Presentation or Logical tables every time they are accessed.
The dimension column based filter should be
applied on each of the security sensitive dimension and fact tables so that
even column selection from only that those fact tables always consider the
dimensional filters.
Based on security requirement filters can
be defined on presentation tables as well as on logical tables. If the same
filter is needed for more than one presentation table that are derived from single
logical table, then it is better to define them only once on logical table
rather than defining them for each presentation tables.
Image
3.6.1
4 Credential Storage
Oracle BI EE 11g does not use any file
based credential storage. It uses Oracle Wallet technique to store the application
credentials that are used across the application to inter application
communication and authentication. You have to setup the system.user key with proper
credential to facilitate inter process communication. Note that this user
should have ‘Impersonate’ permission to its policy.
Image
4.1
5 Oracle BI EE Security Migration
Oracle BI EE 11g Security information can
be migrated from one environment to another environment using some Fusion
Middleware migration strategies. In this section we will understand the details
of these migration strategies. If you remember from the earlier chapter OBI EE
11g has segregated its security management in mainly two parts. One part is
Identity Management via Oracle WebLogic Application Server administration
console and second part Policy Management via Oracle Enterprise Manager
Console. We will not consider the credential storage migration because in most
of the environments there credentials are different to maintain environment
specific securities.
5.1 Identity Store Migration
Oracle BI EE 11g uses Oracle WebLogic severs
security realm for user authentication and group management. The standard
process to migrate these details from one environment to another environment is
to export the identity information from one environment and import the same on
the other environment. The process is very simple and this can also be
automated through WLST scripts.
First login to Oracle WebLogic
Administration console and open the ‘Security Realms’.
There will be a default security realm already present. This is named as ‘myrealm’. Click on ‘myrealm’ and directly go to the ‘Migration’
tab. Click on the sub tab labelled ‘Export’.
Put a valid Export Directory on Server in
the available text box. Check the overwrite box. Press ‘Save’. This will save your WebLogic security realm details in a
set of files under that directory.
Image
4.1.1
DefaultAuthenticator.dat = WebLogic
Authentication Export File
DefaultCredentialMapper.dat = WebLogic
Credential Mapping Export File
XACMLAuthorizer.dat = WebLogic XACML Authorization
Export File
XACMLRoleMapper.dat = WebLogic XACML Role
Mapping Export File
exportIndex.dat = Contains details of the
exported files along with their format and realm details.
Ship these files to the target environment
and import them to the existing WebLogic security realm using the ‘Import’ sub tab from the same ‘Migration’ tab.
The migration will only import the new
users or groups that are defined in the exported file. It will not overwrite
any existing user or groups.
2.2 Policy Store Migration
Oracle BI EE 11g stores the application policies
in an XML file named ‘system-jazn-data.xml’.
This file is located at ‘DOMAIN_HOME/config/fmwconfig’
directory.
To start policy migration the first thing
you have to do is to create a policymigrate directory under your domain home.
This is not specified by Oracle but if you follow this it will be easier to
manage. Under this directory create four directories config, dev, original and
prod. Copy the production ‘system-jazn-data.xml’
file under original and prod directories. Copy the development ‘system-jazn-data.xml’ file under dev directory.
Copy the ‘jps-config.xml’ file under config directory
and rename it to ‘jps-config-policy.xml’.
Edit the ‘jps-config-policy.xml’ file as
follows –
Image
4.2.1
Set the PATH variable to add ‘FWM_HOME/Oracle_BI1/common/bin’ in it.
Run the following WLST command to migrate
development changes to the production environment.
For Linux
wlst.sh FWM_HOME/oracle_common/modules/oracle.jps_11.1.1/common/wlstscripts/migrateSecurityStore.py
-configFile Full_Path_of_jps-config-policy.xml -type policyStore -src
sourceFileStore -dst targetFileStore
Copy the updated ‘system-jazn-data.xml’
file from prod directory to ‘DOMAIN_HOME/config/fmwconfig’
directory and restart the Oracle BI EE Services along with Weblogic Servers.
No comments:
Post a Comment