This chapter describes how to configure Oracle Business Intelligence components to communicate over the Secure Socket Layer (SSL).
See Process for Setting Up Security in Oracle Business Intelligence.
The SSL Everywhere feature of Oracle Business Intelligence enables secure communications between the components. You can configure SSL communication between the Oracle Business Intelligence components and between Oracle WebLogic Server for secure HTTP communication across your deployment. This section does not cover configuring secure communications to external services, such as databases and web servers. See SSL Configuration in Oracle Fusion Middleware in Administering Oracle Fusion Middleware.
This chapter contains the following sections:
SSL is a cryptographic protocol that enables secure communication between applications across a network.
Enabling SSL communication provides several benefits, including message encryption, data integrity, and authentication. An encrypted message ensures confidentiality in that only authorized users have access to it. Data integrity ensures that a message is received intact without any tampering. Authentication guarantees that the person sending the message is who he or she claims to be.
SSL requires that the server possess a public key and a private key for session negotiation. The public key is made available through a server certificate signed by a certificate authority. The certificate also contains information that identifies the server. The private key is protected by the server.
See How SSL Works in Administering Oracle Fusion Middleware.
Using SSL in Oracle Business Intelligence
Oracle Business Intelligence components communicate with each other using TCP/IP by default. Configuring SSL between the Oracle Business Intelligence components enables secured network communication.
Oracle Business Intelligence components can communicate only through one protocol at a time. It is not possible to use SSL between some components, while using simple TCP/IP communications between others. You must configure the following components to enable secure communication over SSL:
Oracle BI Server
Oracle BI Presentation Services
Oracle BI JavaHost
Oracle BI Scheduler
Oracle BI Job Manager
Oracle BI Cluster Controller
Oracle BI Server Clients, such as Oracle BI ODBC Client
SSL is configured throughout the Oracle Business Intelligence installation from a single centralized point. Certificates are created for you and every Oracle Business Intelligence component (except Essbase) is configured to use SSL. The following default security level is configured by SSL:
SSL encryption is enabled.
Mutual SSL authentication is not enabled. Since mutual SSL authentication is not enabled, clients do not need their own private SSL keys.
The default cipher suites are used. See Manually Configuring SSL Cipher Suite.
When scaling out, the centrally managed SSL configuration is automatically propagated to any new components that are added.
If a higher level of security is required, manual configuration might be used to augment or replace the SSL central configuration. This is considerably more complex. For more information about how to configure SSL manually, contact Oracle Support.
Creating Certificates and Keys in Oracle Business Intelligence
Secure communication over SSL requires certificates signed by a certificate authority (CA). For internal communication, the SSL Everywhere feature creates both a private certificate authority and the certificates for you. The internal certificates cannot be used for the outward facing web server because user web browsers are not aware of the private certificate authority. The web server must therefore be provided with a web server certificate signed by an externally recognized certificate authority.
Scaling Out an SSL-Enabled System
To scale out a system that has internal SSL enabled, see Adding New Computers in System Administrator's Guide for Oracle Business Intelligence Enterprise Edition, where the necessary ssl.sh
bindchannelcerts
call is made.
To achieve end to end SSL you need to configure both internal BIEE SSL and WebLogic SSL. The internal SSL configuration is highly automated whereas the WebLogic SSL configuration requires multiple manual steps. The two are entirely independent, so can be performed in either order. Since the WebLogic configuration requires manual steps Oracle advises doing that first.
Note:
This section does not include configuring SSL for Essbase.
Perform the following steps. Confirmation steps are highlighted:
This section explains how to configure a standard non-SSL Oracle Business Intelligence system.
Install Oracle BI EE.
Confirm the system is operational.
Check you can login over HTTP to use:
Analytics
- http://<Host>:<ManagedServerPort>/analytics
Fusion Middleware Control
- http://<Host>:< AdminPort>/em
WebLogic Admin Console
- http://<Host>:<AdminPort>/console
These steps configure WebLogic using the provided demo certificates. These are not secure.
Do not use these tasks in a production environment. Using the demo certificates can help you understand how to configure your environment with real certificates.
To configure with a secure certificate signed by a real Certificate Authority see WebLogic documentation. The certificate authority should return the signed server certificate, and provide a corresponding root CA certificate. Where demoCA is mentioned in task steps replace demoCA with your real CA certificate.
This section contains the following topics:
Starting up just the Administration Server rather than starting everything avoids the need to stop everything while the admin connection properties are in a state of flux, which confuses the stop everything script.
If you have configured an external Identity Store, you can skip performing this step. Perform this task if using WebLogic Server LDAP, and the virtualize
property is not set to true.
You can configure an external identity store to use a secure connection. To use an external identity store, you must change the URL in the internal LDAP ID store.
Open <DomainHome>/config/fmwconfig/ovd/default/adapters.os_xml
In the <ldap>
section of this file, insert the following SSL cipher suites:
<ldap id="DefaultAuthenticator" version="0"> <ssl> <protocols>TLSv1.2,TLSv1.1</protocols> <cipherSuites> <cipher>SSL_RSA_WITH_AES_128_CBC_SHA</cipher> <cipher>SSL_ECDHE_ECDSA_WITH_AES_128_CBC_SHA</cipher> <cipher>SSL_ECDH_ECDSA_WITH_AES_128_GCM_SHA256</cipher> </cipherSuites> </ssl> </ldap>
You must now provide a trust keystore.
See One-way SSL in a Multi-LDAP Scenario in Securing Applications with Oracle Platform Security Services
Note:
This section only applies when using WebLogic Server LDAP and when virtualize=true
is set, as you are explicitly pointing the Administration Server.
In a terminal window set the ORACLE_HOME and WL_HOME environment variables .
For example, on Linux:
setenv ORACLE_HOME <OracleHome>
setenv WL_HOME <OracleHome>/wlserver/
Ensure that both your path and JAVA_HOME point to the JDK 8 installation.
setenv JAVA_HOME <path_to_your_jdk8>
setenv PATH $JAVA_HOME/bin
Check the Java version by running:
java -version
Run (without the line breaks):
<OracleHome>/oracle_common/bin/libovdconfig.sh
-host <Host>
-port <AdminServerNonSSLPort>
-userName <AdminUserName>
-domainPath <DomainHome>
-createKeystore
When prompted enter the existing password for<AdminUserName>.
When prompted for the OVD Keystore password, choose a new password.
For example:
oracle_common/bin/libovdconfig.sh -host myhost -port 9500 -userName weblogic -domainPath /OracleHome/user_projects/domains/bi -createKeystore Enter AdminServer password: Enter OVD Keystore password: OVD config files already exist for context: default CSF credential creation successful Permission grant already available for context: default OVD MBeans already configured for context: default Successfully created OVD keystore.
The -port <AdminServerNonSSL>
command does not work against the Admin server non-SSL port when it has been disabled. If you enable SSL and then configure LDAPs you would need to temporarily re-enable the non-SSL port on the Administration Server.
Check the resultant keystore exists, and see its initial contents, by running:
keytool -list -keystore <DomainHome>/config/fmwconfig/ovd/default/keystores/adapters.jks
We now need to export the demo certificate in a suitable format to import into the above keystore.
In Fusion Middleware Control:
If using the demo WebLogic certificate you can get the required root CA from the system keystore using Fusion Middleware Control.
Select WebLogicDomain, Security, Keystore.
Expand System.
Select Trust.
Click Manage.
Select democa, not olddemoca.
Click Export.
Select export certificate.
Choose a file name.
For example, demotrust.pem
If not using the demo WebLogic certificate then you will need to obtain the root CA of the CA which singed your secure server certificate.
Now import into the just created keystore:
keytool -importcert -keystore <DomainHome>/config/fmwconfig/ovd/default/keystores/adapters.jks -alias localldap -file <DemoTrustFile>
When prompted enter the keystore password you chose earlier, and confirm that the certificate is to be trusted.
If you repeat the keystore -list
command you should see a new entry under localldap
, for example:
localldap, Jul 8, 2015, trustedCertEntry,
Certificate fingerprint (SHA1):
CA:61:71:5B:64:6B:02:63:C6:FB:83:B1:71:F0:99:D3:54:6A:F7:C8
After securing the system to use HTTPS, you must also disable HTTP to fully secure the environment.
Login to WebLogic Administration console.
Click Lock & Edit.
Select environment, servers.
For each server:
Display the Configuration tab
Clear Listen Port Enabled.
Click Save.
Click Activate Changes.
Now you must restart Oracle Business Intelligence.
You cannot login through Analytics since Oracle Web Service Manager (OWSM) is using the disabled HTTP port.
Only the HTTPs one should work.
HTTP should quickly display an error similar to Unable to connect error. Do not to mix the protocols and ports. The browser can hang when attempting to connect to a running port with the wrong protocol.
stop.sh
script located in <DomainHome>/bitools/bin/stop.sh
script.start.sh
script located in <DomainHome>/bitools/bin/start.sh
script.You must now change the Oracle Web Services Manager (OWSM) configuration to use the HTTPs port.
The HTTP(s) OWSM link is not used when using a local OWSM.
Follow these steps to enable SSL on internal communication links.
You must run commands from the master host. Oracle Business Intelligence must have been configured by the BI configuration assistant, WebLogic managed servers must have been created, and any scaling out must be complete. Only use this procedure if you have configured security using the configuration assistant.
If you used the Configuration Template for SSL, see Enabling SSL in a Configuration Template Configured System.
You can configure the following advance options:
Enable server checking of client certificates.
Specify cipher suite to use.
Post conditions:
Post-conditions
WebLogic servers:
Have HTTPS listener enabled on internal channels.
The external port configuration is unaltered. See Enabling End-to-End SSL for how to enable SSL on the external ports as well.
There is a separate internal identity (key/certificate pair) for each listener address. The certificate has a common name matching the listening address, which is compatible with standard HTTPS practice. The certificates are signed by the internal certificate authority.
System components, other than Essbase Studio:
Enable an HTTPS listener on internal channels.
The external port configuration is unaltered.
There is a separate internal identity (key or certificate pair) for each listener address. The certificate has a common name matching the listening address, which is compatible with standard HTTPS practice. The certificates are signed by the internal certificate authority.
Essbase Studio:
No change. Continues with existing connectivity.
Use this task to disable Oracle BI EE SSL on internal communication links.
You must run commands from the master host. To use this option, you configured Oracle Business Intelligence using the configuration assistant, the WebLogic managed servers have been created, and scaling out is complete.
Post conditions:
WebLogic servers:
Have https listener disabled on internal channels.
The external port configuration is unaltered.
System components, other than Essbase Studio:
Only listens on non SSL. SSL connections are not accepted.
Essbase Studio:
No change. Continues with existing connectivity.
You can provide the keys and certificates required to allow Oracle BI EE clients, for example, the Administration Tool, and Job Manager to connect to SSL-enabled servers.
Assumptions:
You run commands from master host.
You can complete this operation online and offline.
Prerequisites
Certificates are created using either the configuration assistant or by running ./ssl.sh
regenerate command.
SSL on WebLogic is enabled.
You can perform this task with the system stopped or running.
Use the following command to export client identity and trust to mydir:
./ssl.sh exportclientcerts mydir
Certificates and the zip file are generated.
Post conditions:
Mydir contains clientcerts.zip file.
Mydir also contains expanded content of the zip file for immediate use:
clientcert.pem
clientkey.pem
identity.jks
internaltrust.jks
internaltrust/internalca.pem
internaltrust/<hashed form of above>
Java clients such as Job Manager can successfully connect with secure option verify server certificate set using identity.jks
to define identity, and internaltrust.jks for their trust.
OpenSSL clients such as the Administration Tool can successfully connect with secure option verify peer set using clientcert.pem
and clientkey.pem
to define their identity, and internalca.pem
as the trust file.
Use these topics to configure SSL for clients.
You must configure clients accessing the BIEE components to use BIEE certificates. You must export the certificates by running the following command:
<DomainHome>/bitools/bin/ssl.sh exportclientcerts <exportDir>
This section explains how to configure SSL for clients, and contains the following topics:
Use these steps to create the passphrase for use when exporting client certificates.
The passphrase is used to protect the export certificates. You must remember this passphrase for use when configuring each client.
The command exports Java keystores for use by Java clients, and individual certificate files for use non Java clients. To make moving the certificates to a remote machine more convenient, the export also packages all the files into a single zip file.
When the BI Scheduler is enabled for communication over SSL, you can invoke the BI Scheduler using the SASchInvoke command line utility.
The SASchInvoke
tool is a command line job invocation tool which allows you to run pre-existing Oracle BI Scheduler jobs. For information about the Oracle BI Scheduler, see Introducing Oracle BI Scheduler.
To successfully connect to BI Scheduler that has been enabled for SSL, Oracle BI Job Manager must also be configured to communicate over SSL.
Oracle BI Job Manager is a Java based component and the keys and certificates that it uses must be stored in a Java keystore database. See Exporting Client Certificates.
From the File menu, select Oracle BI Job Manager, then select Open Scheduler Connection.
In the Secure Socket Layer section, select the SSL check box.
If the server setting verify client certificates is false (one way SSL) then you can leave Key Store and Key Store Password blank. This is the default setting.
If the server setting verify client certificates is true (two way SSL) then you must set Key Store and Key Store Password as follows:
Key Store=<exportclientcerts_directory>\identity.jks
Key Store Password =
passphrase.
To provide a secure link you should select the verify server certificate. Without verification the connection works, but a person in the middle attack which impersonates the server is not detectable.
Select the Verify Server Certificate check box. When this is checked, the trust store file must be specified. This trust store contains the CA that verifies the Scheduler server certificate.
In the Trust Store text box, set the trust store to:
<exportclientcerts_directory>\internaltrust.jks
Set the Trust Store Password to the passphrase.
For the online Catalog Manager to connect to Oracle BI Presentation Services, you might need to import the SSL server certificate or CA certificate.
The online Catalog Manager might fail to connect to Oracle BI Presentation Services when the HTTP web server for Oracle Business Intelligence is enabled for SSL. You must import the SSL server certificate or CA certificate from the web server into the Java Keystore of the JVM that is specified by the system JAVA_HOME variable.
The default password for the Java trust store is changeit.
To successfully connect to an Oracle BI Server configured to use SSL, you must also configure the Oracle BI Administration Tool to communicate over SSL.
The data source name (DSN) for the BI Server data source is required.
You can create an ODBC DSN for the BI Server to enable remote client access.
To enable SSL communication for an ODBC DSN, see Integrating Other Clients with Oracle Business Intelligence in Integrator's Guide for Oracle Business Intelligence Enterprise Edition.
You can configure Oracle BI Publisher to communicate securely over the internet using SSL.
See Configuring BI Publisher for Secure Socket Layer (SSL) Communication in the Administrator's Guide for Oracle Business Intelligence Publisher.
If BI Publisher does not work after configuring SSL, you might need to reconfigure the HTTPs protocol, and SSL Port. See Configuring Integration with Oracle BI Presentation Services in Administrator's Guide for Oracle Business Intelligence Publisher.
This task provides a warning if certificates are expired or about to expire.
You must run commands from the master host with the system running or stopped.
Post conditions:
Detailed expiry information on certificate authority and server certificates is listed.
The ssl.sh
command returns the following status:
13 – if certificates expired.
14 – if certificates are due to expire in less than 30 days.
0 – if certificates have more than 30 days life remaining.
Certificate replacement allows replacement of all certificates by new ones.
You may want to do this because:
The existing certificates have expired, or are about to expire.
Both server certificates and CA (trust) certificates have defined life spans. Once they expire connections using those certificates do not work.
Your organization has a policy requiring a different certificate expiry from the default provided by the BI configuration assistant.
The security of the existing certificates and keys has been compromised.
Assumptions:
You run commands from the master host.
This is an offline operation.
Post conditions
The domain now runs with SSL, and uses the new certificates. Servers will not connect to a WebLogic instance using the old trust.
You can run the ssl.sh expiry
command to list the new certificates with the new expiry date.
You can update certificates following a change of listener address, for example by setting an explicit listener address in WebLogic console to replace the default (blank).
The ssl.sh scan command shows errors due to incorrect certificate common names. Connections to servers whose certificates do not match their listening addresses will be rejected.
Assumptions:
You run commands from the master host.
This is an offline operation.
Post conditions
The domain now runs with SSL, and uses the new certificates. The new certificates have the same expiry as existing certificates. The certificates are signed by the existing internal certificate authority so previously exported client trust remains valid.
You can run the ssl.sh expiry
command to list the new certificates with the new expiry date.
Follow these steps to achieve the same internal SSL configuration for a new server.
Assumptions:
You run commands from the master host.
This is an offline operation.
One or more new servers have been created, either by cloning an existing server or creating from scratch.
Post conditions
The domain now runs with SSL, with all WebLogic managed servers using the internal SSL. If the servers were cloned, the cloned internal channel port has been replaced by the port given by the channel command. If the servers were created from scratch the internal channel has been created and configured to use SSL.
This task provides the same SSL internal channel configuration as provided by the BI configuration assistant for systems configured using WLST or by direct application of configuration templates in the WebLogic configuration assistant.
Assumptions:
You run commands from the master host.
This is an offline operation.
Post conditions
The domain runs with SSL and all the WebLogic managed servers using the internal SSL.
To support SSL on the external ports without using SSL internally you must decouple the internal communications by creating internal channels. Use the steps in this task to create the internal channels configured to use HTTP.
Oracle Business Intelligence has system components that need to communicate with Java components running inside WebLogic managed servers, for example at login an Oracle BI Server process calls the BI security service. In a default configuration template configured system, the communication links use the external WebLogic ports. You can configure Oracle WebLogic Server to use HTTPS for its external ports.
If you configure WebLogic to use HTTPS for external ports, the internal components attempt to connect to the HTTPS port without the necessary trust setup. To avoid this problem, you need to configure private channels. These private channels are independent of the external WebLogic ports, with their own ports and their own protocol configuration.
Assumptions:
Option A, run the following commands:
<domain_home>/bitools/bin/ssl.sh regenerate <days>
Regenerate the certificates to allow the subsequent channel commands to work. The certificates aren't used unless you subsequently change your mind and enable internal SSL.
<domain_home>/bitools/bin/ssl.sh targetapps bi_cluster
For each new server run the following using an unused port:
./ssl.sh channel <new_bi_server> <port>
./ssl.sh internalssl false
Option B, repeat running the following command using the internalssl
error checking to prompt you to resolve issues.
./ssl.sh internalssl false
Run the other commands as indicated in the internalssl
command's error messages.
The default SSL configuration uses default cipher suite negotiation. You can configure the system to use a different cipher suite if your organization's security standards do not allow for the default choice. You can view the default choice in the output from the SSL status report.
This advanced option involves editing a configuration file. Be careful to observe the syntactic conventions of this file type.
A manually configured SSL environment can coexist with a default SSL configuration.
See Starting and Stopping Oracle Business Intelligence System Components in System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Use these links to see topics about configuring SSL connections to external systems:
You must obtain the SMTP server certificate to complete this task.
If you are configuring multiple authenticators, and have configured an additional LDAP Authenticator to communicate over SSL (one-way SSL only), you need to put the corresponding LDAP server's root certificate in an additional keystore used by the virtualization (libOVD) functionality.
In the following procedure you set the values for your environment variables: ORACLE_HOME, WL_HOME and JAVA_HOME.
For example on UNIX:
set ORACLE_HOME= orahome
set WL_HOME=orahome/wlserver
set JAVA_HOME=orahome/oracle_common/jdk
The createKeystore
command creates a OVD Keystore password. You have to type a value for the OVD Keystore password.
See Starting and Stopping Components in System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Before completing this task, you must configure the custom property, called virtualize
, and set the property’s value to true
, see Configuring Identity Store Virtualization Using Fusion Middleware Control.
You should see two new credentials in the Credential Store and a new Keystore file, called adapters.jks
in the following location, <OracleHome>/user_projects/domains/bi/config/fmwconfig/ovd/default
.