Skip navigation.

Security Blogs

OBIEE Authentication Using the Oracle E-Business Suite

There are two primary options for sharing authentication solutions with the Oracle E-Business Suite. The Oracle E-Business Suite and OBIEE both can take advantage of Oracle’s Single Sign-On (SSO) solutions. If SSO is used, both OBIEE and the E-Business Suite would be subscribing applications.

The other option is for OBIEE to use the Oracle E-Business Suite for authentication. This solution requires that users first log into the E-Business Suite and from there exercise (click-on) a menu function to bring them into OBIEE without having to type a user name or password.

OBIEE and Oracle E-Business Suite Integration

Configuring OBIEE to use the Oracle E-Business Suite for authentication is straight forward and can be completed in a test environment with only a small amount of effort.  It is technically accomplished through the sharing of the E-Business Suite session cookie.

Further documentation on the specific steps to configure OBIEE to use the E-Business Suite for authentication can be found on Metalink as well as in the OBIEE documentation.  A high level summary is as follows:

  1. Using the BI Admin client tool, modify the RPD file to add a connection to the E-Business Suite database.
  2. Add an initialization block to the RPD file that calls the E-Business Suite API APP_SESSION.validate_icx_session and then call FND_GLOBAL to collect the variables resp_id, resp_appl_id, security_group_id, resp_name, user_id, employee_id and user_name.
  3. Edit the OBIEE configuration files authenicationschema.xml and instanceconfig.xml
  4. Create a menu function to launch OBIEE. You must use the SSWA OracleOasis.jsp$mode=OBIEE
  5. Populate the system profile option ‘FND: Oracle Business Intelligence Suite EE base URL’ with the url for OBIEE. For example: http://theobieeserver.yourcompany.com:9704
  6. Upload the modified RPD file using Enterprise Manager and bounce all OBIEE services
Technical Summary

Authentication integration between OBIEE and the E-Business Suite is through a combination of a shared session cookie and a dynamic URL. The key to making it work are edits to OBIEE’s instanceconfig.xml configuration file. It is in this file that OBIEE instructed is to look for the E-Business Suite session cookie.

 

If you have questions, please contact us at info@integrigy.com

 -Michael Miller, CISSP-ISSMP

References Tags: Oracle E-Business SuiteOracle Business Intelligence (OBIEE)Security Resource
Categories: APPS Blogs, Security Blogs

OBIEE Security: Questions IT Security and Audit Should Ask

This blog series so far has reviewed the basics of OBIEE security, the following questions should be included in any discussion of about the security of an OBIEE implementation.

How are Security Configurations Migrated?

Creation of non-production instances is a regular occurrence for enterprise software. To migrate security configurations among non-production instances as well as from non-production to production, OBIEE requires specific steps to be taken for Identity, Policy and Credential Stores as well as for the migration of Repositories. Some migration steps are done through the WebLogic, others by WLST. Performing migrations by copying directories among different servers and/or environments should be flagged and investigated.

Ask for Permission Reports

Prior to 11g OBIEE did not have an option to report on security permissions and rules defined within the RPD. With 11g permission reports are able to be generated for presentation layer objects. These reports are able to be exported as CSV files and are of great value to understanding security within an OBIEE application.

Are WiteBacks being Used?

OBIEE has an advanced feature which allows for data to be written (created or updated) back to the database. This feature is referred to as ‘Write Back’.  The connection pool needs to be configured to allow for write back as well as the physical layer needs to flag each table to be updated as ‘uncacheable’. The granting of write back privileges is then given to users within the Presentation Layer.

An example of WriteBack could be variables to assist with “what-if” modeling. The security risks if not set properly include data integrity if for example a user were to update their own salary.

Are Time Limits being Used?

OBIEE, besides being able to set query limits for the number of rows to be returned, can also set limits for when a particular user or role can use OBIEE.  For example, it is possible to define a rule to only allow a specific user or an application role to use the RPD during first shift and/or only Monday through Friday. Such rules may help build a more secure implementation.

Navigation: => Open identity manager within the RPD => Select role or user => Click on permissions => Click on query limits => Click on restrict

 

Is Direct SQL Access Allowed?

OBIEE allows for Direct SQL access to the repository database (data sources). While this can be invaluable for testing it can also be a large security risk, especially if full Data Manipulation Language (DML) is allowed. Direct SQL access can be globally enabled or disabled as well as set at a role or individual level.

Any security assessment of OBIEE needs to review the usage of Direct SQL Access. The risks of allowing Direct SQL include:

  • Confidentiality –  bypassing data (object) level security defined within the repository (RPD)
  • Integrity – modifying or deleting data
  • Availability – overloading database with inordinate requests

To restrict access to direct SQL:

  • Global: => Settings => Administration => Manage Privilege
  • Role or User:  => Open identity manager within the RPD => Select role or user => Click on permissions => Click on query limits => Select Allow, Disallow or Ignore for Execute direct database requests

Example of Direct SQL

Is Go URL SQL Access Allowed and Secured?

The Oracle BI Presentation Services Go URL can be used to incorporate specific Oracle Business Intelligence results into external portals or applications. It has a number of optional parameters and arguments. It can also set session variables. More importantly, it can also issue SQL and return tabular results. For these two reasons alone, how the Go URL is being used should be kept in mind during a security assessment.

For example:

http://testobiee:9704/analytics/saw.dll?Go&SQL=select+Region,Dollars+fro... where the FROM clause is the name of the Subject Area to query

Alternatively, the command IssueRawSQL can be used to bypass the Web processing and issue SQL directly against the BI Server.

Who Can Act-As and Who can Impersonate?

OBIEE allows for two options for a user to assume the identity of another user. This functionality exists for several reasons, including testing, end-user support and system integration.  Any security assessment of OBIEE needs to identify all users and systems able to act-as or impersonate another user.

  • Impersonation - exists more for integration, is less secure than ‘Act-As’ and from a security perspective is a ‘backdoor’ risk. The default OBIEE user, BISystem comes out-of-the-box with Impersonation enabled. IT security should be consulted if this is enabled.
  • Act-As – is the better choice to use support. It is more secure and is fully integrated into the user interface as standard functionality.

To check the Act-As and Impersonation settings, look at the system session variables PROXY and PROXYLEVEL.

 

Act-As

Impersonate

Level of access

Full or read-only access, on a single user

Full access

Users whose identity can be assumed by the proxy user

Defined list of users

Any and all users, anytime

Access method

Standard functionality of UI

Construct URL manually

How to know if being used

Both proxy and Target are shown in the UI

No indication given

Security risk

Little to none

Credentials exposed in plain text when URL submitted

 

An example URL for impersonation is below. Please note, too, that the URL were exercised, the security risks could be increased because the user name password will then be captured and stored in the Apache log files.

http://server_name_or_ip_address/analytics/saw.dll?Go&NQuser=xxx&NQPassword=xxx

Are Virtual Private Databases (VPD) Being Used?

If a Virtual Private Database (VPD) is being used with an OBIEE connection, two things MUST be done. First, for the database connect, set the flag for Virtual Private Database to “Yes”. Second, all variables supporting the security rules must be set to ‘Security Sensitive’. Failing to properly set up VPD with OBIEE can result in VPD policies being bypassed due to the OBIEE cache incorrectly sharing result sets already in memory.

 VPD Checkbox

What Is Used for Source Code Control?

New with OBIEE 11g is the feature to store Repositories using a XML file format instead of the single RPD file. This allows for better support of source code control. Each component of the RPD file has its own XML file such that source code control tools such as Subversion can be used to check in or out each component. Best practice for development and security is to use source code control whenever possible.

 

If you have questions, please contact us at info@integrigy.com

 -Michael Miller, CISSP-ISSMP

References Tags: ReferenceOracle Business Intelligence (OBIEE)Security Resource
Categories: APPS Blogs, Security Blogs

OBIEE Security: Catalogs, Access Control Lists and Permission Reports

The presentation catalog (Web Catalog) stores the content that users create within OBIEE. While the Catalog uses the presentation layer objects, do not confuse the presentation layer within the RPD with the presentation catalog. The presentation catalog includes objects such as folders, shortcuts, filters, KPIs and dashboards. These objects are built using the presentation layer within the RPD.

The difference between RPD and Catalog security is that Repository level restrictions give the most flexibility as they can be either course-grained or fine-grained based on the data. Catalog level restrictions are more course-grained as they are applied to entire subject areas and/or objects.

To access an object in the catalog users must have security and can use either the BI client or web user interface. The BI client for the Web Catalog is installed along with the BI Admin client.

Access Control Lists (ACL)

Access Control Lists (ACL) are defined for each object in the catalog. Within the file system the ACLs are stored in the *.ATR files which may be viewed through a HEX editor. A 16-digit binary representation is used similar to UNIX (e.g. 777). There are six different types of permissions for each object:

  • Full control
  • Modify
  • Open
  • Traverse
  • No Access
  • Custom

In 11g the catalog is located here:

$ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/catalog

  Catalog Permission Reports

From a security perspective, the permission reports that are able to be generated from the Web Catalog client tool are very valuable and can be exported to Excel for further analysis. For example, these reports can provide system generated reports for who can avoid OBIEE security and issue Direct SQL or has rights to Write-Back to the database.  The security ACL will report on who has such Administration privileges.

OBIEE Administration Privileges

BI Catalog Client

Catalog Report

 

If you have questions, please contact us at info@integrigy.com

 -Michael Miller, CISSP-ISSMP

References Tags: ReferenceOracle Business Intelligence (OBIEE)IT Security
Categories: APPS Blogs, Security Blogs

Oracle Security Loop hole from Steve Karam

Pete Finnigan - Tue, 2014-04-15 10:50

I just saw a link to a post by Steve Karam on an ISACA list and went for a look. The post is titled " Password Verification Security Loophole ". This is an interesting post discussing the fact that ALTER....[Read More]

Posted by Pete On 22/07/13 At 08:39 PM

Categories: Security Blogs

OBIEE Security: Usage Tracking, Logging and Auditing for SYSLOG or Splunk

Enabling OBIEE Usage Tracking and Logging is a key part of most any security strategy. More information on these topics can be found in the whitepaper references below. It is very easy to setup logging such that a centralized logging solution such as SYSLOG or Splunk can receive OBIEE activity.

Usage Tracking

Knowing who ran what report, when and with what parameters is helpful not only for performance tuning but also for security. OBIEE 11g provides a sample RPD with a Usage Tracking subject area. The subject area will report on configuration and changes to the RPD as well as configuration changes to Enterprise Manager.  To start using the functionality, one of the first steps is to copy the components from the sample RPD to the production RPD.

Usage tracking can also be redirected to log files. The STORAGE_DIRECTORY setting is in the NQSConfig.INI file. This can be set if OBIEE usage logs are being sent, for example, to a centralized SYSLOG database.

The User Tracking Sample RPD can be found here:

{OBIEE_11G_Instance}/bifoundation/OracleBIServerComponent/coreapplication_obis1/sample/usagetracking

Logging

OBIEE offers standard functionality for application level logging.  This logging should be considered as one component of the overall logging approach and strategy. The operating system and database(s) supporting OBIEE should be using a centralized logging solution (most likely syslog) and it is also possible to parse the OBIEE logs for syslog consolidation.

For further information on OBIEE logging refer to the Oracle Fusion Middleware System Administrator’s Guide for OBIEE 11g (part number E10541-02), chapter eight.

To configure OBIEE logging, the BI Admin client tool is used to set the overall default log level for the RPD as well as identify specific users to be logged. The log level can differ among users. No logging is possible for a role.

Logging Levels are set between zero and seven.

Level 0 - No logging

Level 1 - Logs the SQL statement issued from the client application.

Level 2 - All level 1 plus OBIEE infrastructure information and query statisics

Level 3 - All level 2 plus Cache information

Level 4 - All level 3 plus query plan execution

Level 5 - All level 4 plus intermediate row counts

Level 6 & 7 - not used

 

OBIEE log files

BI Component

Log File

Log File Directory

OPMN

debug.log

ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn

OPMN

opmn.log

ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn

BI Server

nqserver.log

ORACLE_INSTANCE/diagnostics/logs/
OracleBIServerComponent/coreapplication_obis1

BI Server Query

nquery<n>.log <n>=data and timestamp for example nqquery-20140109-2135.log

Oracle BI Server query Log

ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication

BI Cluster Controller

nqcluster.log

ORACLE_INSTANCE/diagnostics/logs/
OracleBIClusterControllerComponent/coreapplication_obiccs1

Oracle BI Scheduler

nqscheduler.log

ORACLE_INSTANCE/diagnostics/logs/
OracleBISchedulerComponent/coreapplication_obisch1

Useage Tracking

NQAcct.yyymmdd.hhmmss.log

STORAGE_DIRECTORY parameter in the Usage Tracking section of the NQSConfig.INI file determines the location of usage tracking logs

Presentation Services

sawlog*.log (for example, sawlog0.log)

ORACLE_INSTANCE/diagnostics/logs/
OracleBIPresentationServicesComponent/
coreapplication_obips1

 

The configuration of this log (e.g. the writer setting to output to syslog or windows event log) is set in instanceconfig.xml

BI JavaHost

jh.log

ORACLE_INSTANCE/diagnostics/logs/
OracleBIJavaHostComponent/coreapplication_objh1

 

If you have questions, please contact us at info@integrigy.com

 -Michael Miller, CISSP-ISSMP

References

 

Tags: Oracle Business Intelligence (OBIEE)AuditorIT Security
Categories: APPS Blogs, Security Blogs

OpenSSL Heartbleed (CVE-2014-0160) and Oracle E-Business Suite Impact

Integrigy has completed an in-depth security analysis of the "Heartbleed" vulnerability in OpenSSL (CVE-2014-0160) and the impact on Oracle E-Business Suite 11i (11.5) and R12 (12.0, 12.1, and 12.2) environments.  The key issue is where in the environment is the SSL termination point both for internal and external communication between the client browser and application servers. 

1.  If the SSL termination point is the Oracle E-Business Suite application servers, then the environment is not vulnerable as stated in Oracle's guidance (Oracle Support Note ID 1645479.1 “OpenSSL Security Bug-Heartbleed” [support login required]).

2.  If the SSL termination point is a load balancer or reverse proxy, then the Oracle E-Business Suite environment MAY BE VULNERABLE to the Heartbleed vulnerability.  Environments using load balancers, like F5 Big-IP, or reverse proxies, such as Apache mod_proxy or BlueCoat, may be vulnerable depending on software versions.

Integrigy's detailed analysis of use of OpenSSL in Oracle E-Business Environments is available here -

OpenSSL Heartbleed (CVE-2014-0160) and the Oracle E-Business Suite Impact Analysis

Please let us know if you have any questions or need additional information at info@integrigy.com.

Tags: VulnerabilityOracle E-Business Suite
Categories: APPS Blogs, Security Blogs

Integrigy Collaborate 2014 Presentations

Integrigy had a great time at Collaborate 2014 last week in Las Vegas.  What did not stay in Las Vegas were many great sessions and a lot of good information on Oracle E-Business Suite 12.2, Oracle Security, and OBIEE.  Posted below are the links to the three papers that Integrigy presented.

If you have questions about our presentations, or any questions about OBIEE and E-Business Suite security, please contact us at info@integrigy.com

References Tags: Oracle DatabaseOracle E-Business SuiteOracle Business Intelligence (OBIEE)
Categories: APPS Blogs, Security Blogs

OBIEE Security: Repositories and Three Layers of Security

This blog series reviewing OBIEE security has to this point identified how users are defined and authenticated within WebLogic, the major security concerns with WebLogic and how application roles are defined and mapped to LDAP groups within Enterprise Manager. We will now review OBIEE authorization, how OBIEE determines what data users can see after they login. 

The OBIEE Repository is comprised of three layers. A very simplistic summary is below:

  • Physical layer: Defines all database or data source connections (user id and passwords are entered and stored here), the physical table and columns, primary and foreign key relationships.  
  • Business Model Mapping layer (BMM):  Referencing the physical layer, here is where logical structures are built and aggregation rules are defined.  The BMM is really the heart of an OBIEE application
  • Presentation layer:  Referencing the BMM, this layer presents the tables and columns to end users. For example, remove unwanted columns or rename awkwardly named columns.
Object and Data Level Security

Object (Physical layer) and Data (BMM) level security is defined within the identity manager in the Repository. Object security can be set to either allow or deny access to a physical table or column. Data security allows rules to be applied to logical tables or columns (BMM layer). These rules can use static values as well as session variables.

Navigation:  Open identity manager within the RPD -> select user or role -> click on permissions

Identity Manager

Data Filter

 

Object Filter

Presentation Layer Security Rule

If you have questions, please contact us at info@integrigy.com

 -Michael Miller, CISSP-ISSMP

References Tags: ReferenceOracle Business Intelligence (OBIEE)Security Resource
Categories: APPS Blogs, Security Blogs