Skip Headers

Contents

2 Hardening Backchannel Network and Services

This chapter contains the following:

Network Security: Overview

Network Security in Oracle Fusion Applications Enterprise Deployments: Explained

Network Security on Transactional Database Access: Critical Choices

Network Security on Oracle Fusion Applications Search: Points to Consider

Locking Down Web Services: Points to Consider

Network Security: Overview

The enterprise deployment guidelines stipulate a network configuration discipline to ensure security at all needed levels.

The following reasons may prevent you from matching the topology and network arrangements described in the enterprise deployment guidelines.

You need to leverage an existing network arrangement and do not have the flexibility to make topology changes.
You have higher levels of risk aversion due to compliance requirements such as for government or defense, or your industry segment requires special regulatory compliance and audit considerations.

For these reasons and given your deployment scenario you may not find it prudent for back-channel communications to occur in the "clear." As an alternative, you can implement SSL-based network encryption.

Note

SSL-based network encryption introduces greater complexity to your enterprise deployment, which affects performance.

Deployment administrators secure back-channel networks by choosing SSL where necessary and also tightening the security policies of their Web services that are independent of SSL.

For more information about default network security, see the Oracle Fusion Applications Enterprise Deployment Guide.

Network Security in Oracle Fusion Applications Enterprise Deployments: Explained

The objective of network security is to prevent exposure of data transmitted over the network to unauthorized users and also to prevent malicious "person in the middle" attacks.

The following methods are most common in achieving network security.

Configuring Secure Socket Layer (SSL) on all network connections among servers, as well as between clients and servers.
Isolating the servers involved within their own isolated networks or protected network zones, which are only accessible by authorized administrators.

For mission critical enterprise applications such as Oracle Fusion Applications, a judicious combination of both of these schemes is considered ideal for ensuring not only security, but also ease of deployment and maintenance. The architectures of the enterprise deployment guidelines, as presented in the Oracle Fusion Applications Enterprise Deployment Guide, rely on this hybrid strategy. You must understand the built-in network security model offered by the enterprise deployment guidelines to understand the scenarios where you could consider additional SSL configurations and other network security measures.

As the guiding network security principle of most deployments, the middleware servers for Oracle Fusion Applications run on an isolated network within the larger corporate network. Accordingly, Enterprise Deployment Architecture (EDA) stipulates network isolation for various functional groups. Each functional group of software components is isolated in its own firewall separated by demilitarized zones (DMZ). All traffic is restricted by protocol and port. SSL is configured to secure all the network segments between Oracle Fusion Application components and enterprise infrastructures outside of the Oracle Fusion Application functional groups.

The network architecture of the enterprise deployment guidelines includes the following.

The Web servers (Oracle HTTP Server (OHS)), the application servers (WebLogic Server (WLS)), and all other servers for your Oracle Fusion Applications instance run within a single isolated network.
The Oracle Fusion Applications Database, Business Intelligence, Content Management, and Search services all run in either the same isolated network or each in its own isolated network that can only be reached via the applications private network.
Centralized services such as Oracle Identity Management (OIM) servers are assumed to operate outside of these isolated networks.
The connection to the database is assumed to be between two isolated networks.
There are no connections to external Web services configured by initial provisioning.

Given that this network topology is the target, the enterprise deployment guidelines recommend enabling SSL appropriately for all connections leading into or out of the isolated networks.

The figure shows the connections that are SSL enabled in an Oracle Fusion Applications deployment. The connections among the Oracle WebLogic Servers (WLS) and domains of the Oracle Fusion Applications deployment are not SSL enabled because the enterprise deployment guidelines require and assume that the subnets in the data center where Oracle Fusion Application is deployed are secured by network firewalls preventing direct access of Oracle Fusion Application components by users and applications outside the data center. The connection to the Oracle Fusion Applications database in an adjoining protected zone is also not SSL enabled. But connections to the identity access management components are SSL enabled.

Connections within and among the Oracle
WebLogic Servers of the Oracle Fusion Applications domains are within
a protected zone and not SSL enabled out of the box. Connections out
of the protected zone to the protected zone of the Oracle Identity
Management domain are SSL enabled out of the box. Connection to the
Oracle Fusion Applications database in its adjoining protected zone
is not SSL enabled out of the box.

For more information on configuring SSL in the generic case, see the Oracle Fusion Applications Administrator's Guide.

Network Security on Transactional Database Access: Critical Choices

Network Data Encryption and Data Integrity features of Oracle Advanced Security protect sensitive data when it is transmitted over the network by encrypting all communication between the client, the application server, and the database. This encrypts transactions end to end.

Data transmits in packets. Secure Socket Layers (SSL) and other network protections secure data in transit. Digital certificates encrypt or provide a hash digest of the data prior to transmission.

Network Database Encryption and Data Integrity

Oracle Database Advanced Security provides encryption algorithms to protect the privacy of network data transmissions such as the following.

RC4 Encryption
DES Encryption
Triple-DES Encryption
Advanced Encryption Standard

Based on the level of security and performance required for different types of data transfers, select a network encryption algorithm during configuration of Oracle Database Advanced Security.

Network encryption protects all data on the network, not selectively only some data.

Data integrity algorithms protect against attacks such as data modification, deleted packets and replay attacks. To ensure the integrity of data packets during transmission, use the Oracle Advanced Database Security cryptographically secure message digest (MD5 or SHA-1 hashing algorithms), which includes the digest with each message sent across a network.

For more information about network data encryption and integrity for oracle servers and clients, see the Oracle Database Advanced Security Administrator's Guide.

Sensitive Data In Transit

Your enterprise activates a configuration of encryption algorithms and negotiations depending on levels of security and performance for different types of data transfers. Network Data Encryption encrypts all data rather than selectively encrypting only some data.

Oracle Fusion Applications deploys with the following settings for client and server in Oracle Net Manager.

Encryption Type: REQUIRED

Checksum Level: REQUIRED

Oracle Advanced Security generates a cryptographically secure message digest using hashing algorithms and includes the digest with each message sent across a network to ensure the integrity of the data packets. These data integrity protections prevent data modification, deletion of replay attacks during transmission.

Non-SSL Encryption

Enable non-SSL encryption of SQL* Net network traffic by adding the following line to the listener.ora config file on the database server(s) and then bouncing the database TNS Listener.

SQLNET.ENCRYPTION_SERVER = REQUIRED

Additionally, to avoid weak protocols and add more seed, include the following lines.

SQLNET.ENCRYPTION_TYPES_SERVER= (AES256, AES192, 3DES168)
SQLNET.CRYPTO_SEED = <randomstring_for_this_deployment_up_to_70_characters>

For more information about configuring SSL for the database, see the Oracle Fusion Applications Administrator's Guide.

Network Security on Oracle Fusion Applications Search: Points to Consider

Oracle Fusion Applications enforces security in Oracle Fusion Applications Search and the Enterprise Crawl and Applications Search Framework (ECSF).

Oracle Fusion Applications Search can be further hardened by enabling a secure sockets layer (SSL).

Hardening Oracle Fusion Applications Search

When enabling SSL in an Oracle Fusion Applications environment, the keystore certificate and the following system properties must be set for the crawler in Oracle Fusion Applications Search.

Settings for Oracle Fusion Applications Search with SSL Enabled on Windows

Ensure that the crawler script file %ORACLE_HOME%\bin\crawlerlauncher.cmd contains the following line after the set PATH= line.

set TRUST_STORE_PATH=%WEBLOGIC_HOME%\server\lib\fusion_trust.jks

Ensure that the following properties are included both in the CRAWLER_EXEC_PARAMS script variable and in the Java command at the end of the script file.

-Dweblogic.security.SSL.trustedCAKeyStore=%TRUST_STORE_PATH% 
-Djavax.net.ssl.trustStore=%TRUST_STORE_PATH%

Settings for Oracle Fusion Applications Search with SSL Enabled on Linnux

Ensure that the crawler script file $ORACLE_HOME/bin/crawlerlauncher.sh contains the following line after the LOG_PREFIX= line.

TRUST_STORE_PATH=$WLS_HOME/server/lib/fusion_trust.jks

Ensure that the following properties are included both in the CRAWLER_EXEC_PARAMS script variable and in the Java command at the end of the script file.

-Dweblogic.security.SSL.trustedCAKeyStore=$TRUST_STORE_PATH 
-Djavax.net.ssl.trustStore=$TRUST_STORE_PATH

For more information about SSL and HTTPS Support in Oracle Fusion Applications Search, see the Oracle Secure Enterprise Applications Search Administrator's Guide.

Locking Down Web Services: Points to Consider

Oracle Fusion Web Services are set up with internal and external policies.

All internal-facing Web services are protected by Authentication Only policies.

Service or Client Side	Internal Policy	Description
Service Side	`oracle/wss_saml_or_username_token_service_policy`	The service accepts an unencrypted username and password token, or an unsigned Security Assertions Markup Language (SAML) token.
Client Side	`oracle/wss_username_token_client_policy`	The client sends an unencrypted username and password.
Client Side	`oracle/wss10_saml_token_client_policy`	The client sends unsigned SAML token.

These policies send and accept passwords in clear text, meaning unencrypted.. They do not perform any encryption or signing, and they do not have high security. However they are high performance because they don't do any expensive cryptography operations. They should be used only for backend Web services in small internal private networks that are completely blocked off from the internet and also blocked off from the enterprise intranet.

External-facing web services are protected by WS11 Message protection policies.

Service or Client Side	External Policy	Description
Service Side	`oracle/wss11_saml_or_username_token_with_message_protection_service_policy`	The service accepts encrypted username and password token, or a signed SAML token, plus the entire message body must be signed and encrypted.
Client Side	`oracle/wss11_username_token_with_messge_protection_client_policy`	The client sends an encrypted username and password.
Client Side	`oracle/wss11_saml_token_with_message_protection_client_policy`	The client sends signed SAML token.

These policies are very secure, however they are not high performance because they do expensive cryptographic operations.

Oracle Fusion Applications provisioning also sets the following policies globally at the domain level.

Service or Client Side	Global Policy	Description
Service Side	`oracle/wss_saml_or_username_token_service_policy`	The authentication only policy.
Client Side	`oracle/wss10_saml_token_client_policy`	The authentication only policy for SAML token.

Since these are set globally on the domain level, all Web services and Web service clients automatically get these policies unless they attach a different policy locally. Since the global policy attachment (GPA) policy is set to Authentication only, all internal-facing services use this GPA policy, whereas all the external-facing services attach their message protection policy locally.

The message protection policies also need a keystore. The Oracle Fusion Applications provisioning script sets up an initial keystore with the name default-keystore.jks that contains a single private key and a self signed certificate with alias orakey. All but the Oracle Identity Management (OIM) domain are set up with this same keystore, which means that all the Oracle Fusion Applications domains, except OIM, share this same key.

The following figure shows that each domain of a deployment provides access to identity management using the default Java keystore (JKS) default_keystore.jks. Each default keystore file contains an identical, single key called orakey. The credentials store based on a Lightweight Directory Access Protocol (LDAP) such as Oracle Internet Directory (OID) in the Oracle Identity Management domain stores the keystore and key passwords and is shared across all domains.

Every domain but the Oracle Identity
Management domain has a private key: orakey. The Oracle Identity Management
domain authenticates using the passwords in Oracle Internet Directory.

Configuring External Clients to Communicate with Externally Facing Web Services

Since external Web services are protected by the external service oracle/wss11_saml_or_username_token_with_message_protection_service_policy, external clients need to either provide username and password or a SAML assertion.

External clients must complete the following steps.

Get the certificate of the service.

The certificate is advertised in the Web Services Description Language (WSDL). To extract the certificate from the WSDL, perform the following steps.
1. Save the WSDL to a local file.
2. Search for the string X509Certificate inside the local file to locate the certificate.
  For example,
```
<dsig:X509Certificate> MIICHTCCAYagAwIBAgIETBwVYjA ... </dsig:X509Certificate>
```
3. Copy this long string framed by the <dsig:X509Certificate> tags into a text file.
4. Rename the file.
  1. If you are using this certificate in a Microsoft client, you can rename this file with .cer file extension and use it as a certificate file
  2. If you are using this certificate in a Java client, change the text file so that the certificate is framed by BEGIN and END.
    For example,
```
-----BEGIN
MIICHTCCAYagAwIBAgIETBwVYjA ... 
-----END
```
Import the certificate of the service into your client's trust store.
For Java clients use keytool -importcert to import this file from the previous step into your client's keystore.
[For SAML only.] Generate a client certificate.
If your client expects to perform ID propagation, the client needs to authenticate with SAML certificates. For this the client needs to have a client certificate for use as a SAML signing key
[For SAML only.] Import the client certificate into the trust store of the service.
Take the certificate in the previous step and import it into the default-keystore.jks file of the service.

Warning

A SAML signing key lets the client authenticate as any user, so SAML is recommended for trusted clients that need to propagate user identities. Regular clients should use username and password instead of SAML.

Hardening Web Services

For more security you can make the following adjustments.

Choose a more secure policy for all your internal Web services. You may choose to not distinguish between internal and external, and use the same policy for all Web services.
Change your keystore to have private keys and certificates. For example if you have an enterprise certificate authority (CA), you can use that to generate your keys, and put the CA certificate in the keystore.

Caution

When changing the attachment of the security policies, the client policy

Be aware of the following fundamentals when changing the attachment of the security policies.

The client and callback policies must be compatible with the service that you are invoking, otherwise the Web service invocation will not work.
In the case of export setup data, the corresponding Service and Callback policies for all Setup Data services must match the Functional Setup Manager (FSM) Processing Service (MigratorService) and FSM Migrator Callback Service (MigratorCallbackService) policies. These must be the same in all the domains so that FSM export and import are fully functional.
As a security guideline, use the same GPA policy across all the domains if you change the domain-wide GPA policy.

If you use a secure sockets layer (SSL) policy, verify the following.

You have set the Oracle HTTP Server (OHS) options to propagate the SSL client certificate and settings to the Weblogic Server (WLS) if your SSL terminates at the OHS.

For more information on setting up your environment for policies, see the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
You have set the SSL variables and client to go to OHS and then load balancer (LBR) if your SSL terminates at the LBR level.
You have configured the policies for SAML Token (Sender Vouches) Over SSL for two-way SSL. Other authentication tokens such as username token, SAML bearer token, and so on, require only one-way SSL.

For information about securing Web services generally, see the Oracle Fusion Application Administrator's Guide.

More Secure Keys and Certificates

Oracle Fusion Applications provisioning sets up the keystore with self-signed certificates that you can choose to replace your own keys and certificates.

For example, if you have an enterprise CA, you can use that to generate keys and certificates, but you must also do the following.

Configure your Web services to accept only a configured list of SAML signers by configuring the trusted distinguished names (DN) list for SAML signing certificates in every domain.
The private key that you configure for Oracle Web Services Manager (OWSM is used for signing SAML Sender Vouches assertion. The certificates that you place in the OWSM keystore are for verifying SAML assertion. If you put your enterprise CA in this OWSM keystore, every certificate issued by your enterprise is acceptable for verifying assertion unless Web services is configured to accept only your list of SAML signers.

For more information about Defining a Trusted Distinguished Names List for SAML Signing Certificates, see the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
Enable hostname verification by setting the value of wsm.ignore.hostname.verification to false.
By default, host name verification is turned off in OWSM .

Hardware Security Modules

Hardware security modules (HSM) protect high-value cryptographic keys on the application server. For example, you can use an HSM together with Oracle Transparent Data Encryption to store the master encryption key.

As a security guideline, secure Web services that are served through HTTPS (SSL/TLS) by using SSL Acceleration HSMs.