OBIEE Security Examined: WebLogic Security

As the first post in Integrigy’s blog series on OBIEE security, it makes sense to first look at WebLogic. As a Fusion Middleware 11g product, OBIEE 11g uses Oracle WebLogic for centralized common services, including a common security model. WebLogic itself is a scalable, enterprise-ready Java Platform, Enterprise Edition (Java EE) application server. The WebLogic Server infrastructure is based on a Service Oriented Architecture (SOA) which allows it to be the foundation for many different types of applications.  Oracle Corporation describes the WebLogic Server security architecture as “providing a comprehensive, flexible security infrastructure designed to address the security challenges of making applications available on the Web.”

Our webinar on 19-March will review OBIEE security, please register through the link below if you are interested.

When considering WebLogic security, the following points should be kept in mind:

Network

Before installing WebLogic, have an expert review network services to ensure that a malicious attacker cannot access the operating system or system-level commands. Use a DMZ if exposing OBIEE functionality on the Internet. Also use SSL to protect client communications and configure all Fusion Middleware Applications to use SSL.  The OHS web services commonly use 4443 (not 7777) on the firewall and 9704 internally for OBIEE reporting services.

Many OBIEE implementations take advantage of mobile access outside the firewall (e.g. iPad or tablets). The OBIEE mobile interface uses the same authentication within WebLogic. No additional authentication configurations are required.

Operating System Accounts

WebLogic should be installed and started by a single operating user purposely created to support WebLogic. If possible avoid choosing an obvious name for this user. Do not use demo or sample user accounts and passwords.

As a security best practice, WebLogic must not be run as a privileged user or as root. For UNIX installations this requires additional steps to be taken because with UNIX, only processes that run under a privileged user account (usually root) can bind to ports lower than 1024.  Because WebLogic, as an Application Server is a long running process that needs to communicate on lower ports such as 80 or 443, there are two commonly used options:

• Start WebLogic under the privileged user account, bind to the privileged ports, and then change its user ID to a non-privileged account
• Start WebLogic using a non-privileged account and configure the firewall to use Network Address Translation (NAT) software to map protected ports to unprotected ones

File Permissions

Only install WebLogic on a host that can prevent unauthorized access to protected resources. For example, on a Windows computer, use only NTFS. Access to the WebLogic configuration files must be carefully restricted to the WebLogic administrators, ideally on an as needed basis only. No other operating system user should have read, write, or execute access to WebLogic Server product files or domain files.

The file permissions for the following directories are critical for securing WebLogic. These directories should be appropriately restricted:

• Middleware Home directory
• WebLogic Server product installation directory
• WebLogic domain directories
• Persistence Store

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

 -Michael Miller, CISSP-ISSMP

Please Note:

• Register for March 19^th Webinar: OBIEE Security Examined
• Collaborate 2014 session OAUG – #14366 OBIEE Security Examined, Friday, April 11, 12:15pm