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:

OBIEE Security: Repositories and RPD File Security

The OBIEE repository database, known as a RPD file because of its file extension, defines the entire OBIEE application. It contains all the metadata, security rules, database connection information and SQL used by an OBIEE application. The RPD file is password protected and the whole file is encrypted. Only the Oracle BI Administration tool can create or open RPD files and BI Administration tool runs only on Windows.  To deploy an OBIEE application, the RPD file must be uploaded to Oracle Enterprise Manager.

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.

Oracle Business Intelligence Enterprise Edition (OBIEE) Security Examined

Oracle’s Business Intelligence Enterprise Edition (OBIEE) 11g is a powerful tool for accessing data, however this power means OBIEE security is imperative in order to protect the data. Throughout March and April 2014 Integrigy will be focusing our blog posts on the security of all layers of the OBIEE technology stack: the OBIEE application, the WebLogic application server, and the repository database. In addition, the topic of the monthly webinar for March will be OBIEE security.

Oracle E-Business Suite Logging and Auditing: Page Access Tracking

Sign-On Audit only logs professional forms activity – it does not log Oracle Applications Framework (OAF) user activity.  Page Access Tracking is required to log OAF activity.  Once enabled, the level of logging needs to be set as well as flagging those applications to be logged and has negligible overhead.

To configure Page Access Tracking, use the following navigation: System Administration -> Oracle Applications Manager -> Site Map > Monitoring > Applications Usage Reports > Page Access Tracking.

Oracle E-Business Logging and Auditing: PCI, SOX, HIPAA, 27001 and FISMA

Continuing this blog series on Oracle E-Business logging and auditing, Integrigy’s log and audit framework is based on our consulting experience. We have also based it on compliance and security standards such as Payment Card Industry (PCI-DSS), Sarbanes-Oxley (SOX), IT Security (ISO 27001), FISMA (NIST 800-53), and HIPAA.

Enabling Credit Card PCI Protection for the Oracle E-Business Suite

The real challenge for meeting PCI compliance is the secure management of all the components and parts of the Oracle E-Business Suite environment every day of year. While Release 12 of the Oracle E-Business Suite by default does not protect cardholder data, it can be enabled. The steps are rather straight forward and can easily be completed in a non-production instance for testing.  Future blog posts will review the daily, weekly, monthly and annual PCI requirements once these basic PCI setups have been completed.

Oracle E-Business Suite, PCI Compliance and the Secure Payments Repository

Continuing this blog series on PCI compliance and the Oracle E-Business Suite, this posting focuses on the Secure Payments Repository.  New with Release 12 of the E-Business Suite, credit card processing and data storage within Oracle Financials, for customer’s and vendor’s card data, is now done within the Secure Payment Data Repository within Oracle Payments.  It is through this new standard functionality built into the Secure Payment Data Repository that PCI DSS compliance can be met.

Pages

Subscribe to RSS

Add us to your favorite news reader.

Follow on Twitter

Get the latest updates.