3 Secure Oracle Fusion Applications

Key connections in Oracle Fusion Applications can be secured either during provisioning or post-provisioning.

This section contains the following topics:

• Basic Network Topology

• Provisioned SSL Connections

This section contains checklists of the SSL connections required by the various IdM components that can operate within the Oracle Fusion Applications environment.

For each component, there is a table listing the server, inbound client connections to that server, and outbound clients from the server, with links to the SSL configuration details for each path.

Table 3-12 shows the connections for Oracle Internet Directory:

Table 3-13 shows the connections for Oracle Access Manager:

Table 3-14 shows the connections for Oracle HTTP Server (OHS):

Enable Secure Sockets Layer (SSL) on ECSF to secure all connections that transmit passwords. These include connections to Oracle WebLogic Server, the ECSF servlet, and the Oracle SES server.

To enable SSL for ECSF, perform the following tasks:

• Task 1, "Generate a Certificate for the Oracle WebLogic Server Instance"

• Task 2, "Enable SSL on the Oracle WebLogic Server Instance"

• Task 3, "Add the Oracle WebLogic Server's Certificate to Oracle SES's Trust Store"

• Task 4, "Enable SSL for Oracle SES Services"

• Task 5, "Configure Search Engine Instances to Use SSL"

Task 1   Generate a Certificate for the Oracle WebLogic Server Instance

A certificate that contains the public key of the Oracle WebLogic Server instance hosting ECSF must be generated. This can be either a CA-signed certificate or a self-signed server certificate.

As described later (Task 3), if this is a self-signed certificate, then it must be imported to Oracle SES's truststore. If it is a CA-signed certificate, it likely already exists in the truststore; if not, you must import the CA certificate into Oracle SES's truststore.

Task 2   Enable SSL on the Oracle WebLogic Server Instance

Enabling SSL connections on the Oracle WebLogic Server instance, on which the ECSF application is running, secures the ECSF servlet connections used to access the feeds and the security service.

To enable SSL on Oracle WebLogic Server:

1. Configure SSL.

   • Select the server on which the ECSF application is running.

   • Make sure that Allow Unencrypted Null Cipher is unchecked (default).

2. Configure the listen ports to enable the SSL listen port by checking the SSL Listen Port Enabled.

   The SSL Listen Port is usually set as 7002. This port number can be used to access the ECSF servlet through SSL (for example https://mywlsserver.host.com:7002/approot/searchfeedservlet/ConfigFeed). Also note that the protocol in the URL must be https.

3. Save your changes.

Task 3   Add the Oracle WebLogic Server's Certificate to Oracle SES's Trust Store

When Oracle SES initiates SSL connections to ECSF, the Oracle WebLogic Server instance on which the ECSF Servlet is running sends a digital certificate containing its public key to Oracle SES. If this certificate is a self-signed certificate, then the certificate must be extracted from Oracle WebLogic Server and added to Oracle SES's trust store. (If a CA certificate, ensure that it exists in the SES trust store.)

To add the Oracle WebLogic Server certificate to the Oracle SES trust store:

1. Use the keytool utility (located in ORACLE_HOME/jdk/bin) to export the Oracle WebLogic Server's certificate from the keystore, for example:

   keytool -export -alias weblogic -keystore JAVA_HOME/jre/lib/security/cacerts -file /temp/weblogic.cer

   where Oracle WebLogic Server's certificate, located in the keystore at JAVA_HOME/jre/lib/security/cacerts, is exported to the weblogic.cer file in the /temp directory; this file now contains the server's certificate.

2. Navigate to the Oracle SES installation directory, and use keytool to import the Oracle WebLogic Server's certificate into the Oracle SES keystore, for example:

   keytool -import -alias weblogic -file weblogic.cer -keystore ORACLE_HOME/jdk/jre/lib/security/cacerts

   where Oracle WebLogic Server's certificate in the weblogic.cer file is imported into the Oracle SES keystore at ORACLE_HOME/jdk/jre/lib/security/cacerts.

Task 4   Enable SSL for Oracle SES Services

SSL must be enabled on Oracle SES Query and Admin Services. For more information about how to enable SSL, see Oracle Secure Enterprise Search Administrator's Guide.

Since the Oracle SES server's certificate has not been signed by a reputable certificate authority (CA) but instead is a self-signed certificate, the certificate must be extracted from Oracle SES and added to both Oracle WebLogic Server's trust store and ECSF Command Line Administration Utility's trust store using these steps:

1. Use keytool to add the extracted Oracle SES server's certificate to the trust store that Oracle WebLogic Server is configured to use, for example:

   keytool -import -alias oses -file oses.cer -keystore WLS_keystore

   where Oracle SES server's certificate in the oses.cer file is imported into WLS_keystore, which is the keystore that Oracle WebLogic Server is configured to use.

2. Add the extracted Oracle SES server's certificate to ECSF Command Line Administration Utility's trust store by modifying the runCmdLineAdmin.bat and runCmdLineAdmin.sh scripts, located in ORACLE_HOME/jdeveloper/ecsf, so that JAVA_HOME points to the path of the keystore that Oracle WebLogic Server is using.

Task 5   Configure Search Engine Instances to Use SSL

After SSL is enabled, reconfigure the search engine instance parameters that contain URLs that point to the ECSF server. These parameters are ECSF_DATA_SERVICE, ECSF_SECURITY_SERVICE, and ECSF_REDIRECT_SERVICE.

The protocol must change from http to https, and the http port must change from 7101 to 7002, the SSL port. For example, change http://wlsserver.com:7101/approot/searchfeedservlet to https://wlsserver.com:7002/approot/searchfeedservlet.

It is important also to reconfigure the search engine instance parameters that contain URLs that point to the Oracle SES server. These parameters are SES_ADMIN_SERVICE and SES_QUERY_SERVICE.

The protocol must change from http to https. For example, change http://sesserver.com:7777/search/api/admin/AdminService to https://sesserver.com:7777/search/api/admin/AdminService. Do not change the port number because the instructions will switch the current port to be an SSL port instead of adding a separate SSL port.

During the identity provisioning stage of installation, Oracle Fusion Applications require the existence of certain users with specific privileges. These administrative users are defined in the Security Console.

This section contains the following topic:

• Define Implementation Users

The identity provisioning process consists of distinct phases.

1. In the interview phase, Provisioning Wizard collects the following information:

   • The DN of the user designated as the super user. This user must already exist in the identity store.

   • Whether the system administrators group exists or must be created.

   • If the group exists, the DN of the group.

   • The LDAP authenticator, either Oracle Internet Directory (OIDAuthenticator) or Oracle Virtual Directory (OVDAuthenticator) that will serve as the LDAP identity store.

2. The next step of the process verifies that the designated super-user exists in the identity store.

   The system administrator group is created if needed, and the super user is made a member of the group.

3. The application domains are created, the LDAP authenticator is enabled, and the WebLogic domain is started up.

4. Following configuration, the system administrator groups are assigned the appropriate family-level enterprise roles.

At the end of this process, the super user has:

• Administrator privileges for all WebLogic domains and all middleware.

• Function setup privileges for all Oracle Fusion applications.

• Administration privileges to Oracle Fusion Applications. These do not include transactional privileges.

For more information about identity provisioning and using the interview wizard to create a provisioning plan, see Plan the Topology and Provisioning of the Installation in Oracle Fusion Applications Installation Guide.

While there are logical sets of "super" administrative groups (a set of two per application family, consisting of the super-user administrator and the application administrator) it is possible to choose to distribute these functions among fewer individuals. The recommended best practice is to carefully plan the separation of duties, taking into account the real-world operational needs of the site.

The Security Console makes possible to add, update, and delete user accounts from applications and directories.

Identities can be created and managed when user records are created through activities such as employee hiring and creation of contacts through Oracle Fusion CRM. In addition, identities can also be created and managed administratively through the Security Console.

The Oracle Fusion Applications administrator must take certain considerations into account when implementing data masking for an application. For example, free space requirements must be evaluated to ensure that adequate resources are available to the masking job. The following instructions provide guidelines:

• Requirements for Data Masking

• Sensitive Data in Oracle Fusion Applications

• Masking Definitions

The Software Library contains a collection of common masking templates for Oracle Fusion Applications which can be imported for use in the environment and modified as needed.

The following sections explain how to obtain and manage the data masking templates:

• Use Self Update to Obtain the Masking Templates

• Import Masking Templates from the Library

• Export Masking Templates from the Library

1. Ensure that the masking template file has been imported. For details about this task, see Manage the Masking Templates.
2. In Cloud Control, select the Targets drop-down.
3. Select the Databases option.
4. Select the database whose mask definition are being configured from the list of databases.
5. In the Security drop-down, select Data Masking. The Data Masking Definitions page lists the current masks for the database:

   Figure 3-7 Data Masking Definitions Page

   
   

   
   Description of "Figure 3-7 Data Masking Definitions Page"

   
   
6. Select the desired mask definition to view or update and click Edit.
7. Log in to the database.
8. The Edit Masking Definition page appears. It lists the columns included in the mask definition.

   Figure 3-8 Edit Masking Definition Page

   
   

   
   Description of "Figure 3-8 Edit Masking Definition Page"

   
   
9. Several operations are available on this page:

   • To add another column to the definition, click Add.

   • To modify a column format, click the Format icon.

   • To refine the list of columns, use the Enable, Disable and Search filter options. For example, to remove a column from the mask definition, check the box and click Remove.

10. To introduce a new column into the definition, for example, click Add. The Add Columns page appears.
11. To locate the column, enter the schema and table name and click Search.

    In this example, we search the MOO_REVN table in the FUSION schema:

    Figure 3-9 Add Columns Page

    
    

    
    Description of "Figure 3-9 Add Columns Page"

    
    
12. Select the checkbox for the MARGIN_AMT column and click Add.

    The Edit Masking Definition page reappears, with MARGIN_AMT added to the column list.

    Unlike the other columns, the format toolbox icon for MARGIN_AMT is displayed in red, which means that no mask format has yet been defined for the column. A format for this column must be specified to complete the definition.

13. Click on the toolbox icon. The Define Column Mask page appears.

    Figure 3-10 Define Column Mask Page

    
    

    
    Description of "Figure 3-10 Define Column Mask Page"

    
    
14. Now specify a mask format entry for MARGIN_AMT using the drop-down box. Click Add to complete the process.

    In this example we select a random number format and specify the start and end lengths. To see how the masked data will appear in this format, click the Sample icon.

    Figure 3-11 Define Column Mask Page

    
    

    
    Description of "Figure 3-11 Define Column Mask Page"

    
    

    It is possible to use the Import Format button to import an existing format entry.

15. Click OK. Cloud Control checks that the entry is valid for the column's data type. The Edit Masking Definition page reappears, and the MARGIN_AMT column now has a valid mask format.

    Click OK to save the masking definition.

1. Follow Steps 1 through 5 of View and Modify Data Masking Definitions to display the data masking definitions for the database.
2. After creating or modifying a masking definition, its status is listed as Script Not Generated."

   Select the definition and click Generate Script.

3. The Schedule Script Generation page appears. Specify generation options, login credentials, and a start time. Specify the necessary values and click Submit.

   Return to the Data Masking Definitions page; the Status column lists the job in progress.

4. After processing is complete, the job status changes to Script Generated. Click the entry for Most Recent Job Completed to view the job details:

   Figure 3-12 Most Recent Job Completed Summary Page

   
   

   
   Description of "Figure 3-12 Most Recent Job Completed Summary Page"

   
   

   From this page, it is also possible to check the details of intermediate steps by clicking their Status entry.

5. After processing is complete, the following steps may be:

   • Integrate the masking script with the clone database process

   • Schedule execution of the script to perform the masking operation.

1. Ensure that the masking template file has been imported. For details about this task, see Manage the Masking Templates.
2. In Cloud Control, select the Targets drop-down.
3. Select the Databases option.
4. Under Related Links, select Data Masking Format Library.

   Figure 3-13 Data Masking Format Library Page

   
   

   
   Description of "Figure 3-13 Data Masking Format Library Page"

   
   
5. When adding a new format, an existing format as a starting point can be taken. For example, to create a new format for credit card number fields, it is possible to select an existing credit card format and click Create Like.

   Figure 3-14 Create Format Page

   
   

   
   Description of "Figure 3-14 Create Format Page"

   
   
6. Enter a descriptive name for the new format, and use the drop-down list under format entries to select a masking format. A different post-processing function may also be specified, if desired.

Identity data can reside in several repositories: the Oracle Database, the production identity store (an LDAP store), and the Oracle Identity Manager database.

In the current release, when implementing data masking, the identity attributes are only masked (anonymized) in the Oracle Fusion Applications database. To preserve masked values, ensure that these best practices are followed when using the masked data for a test database:

1. Do not run the Enterprise Scheduler Service (ESS) job to synchronize the LDAP identity store and the Oracle Fusion Applications database, since doing so would reset the identity attributes in the database to their unmasked values.

2. Set up "dummy" test users to perform the testing.

3. Do not:

   • Log in to the test database as a real user.

   • Update a user's attributes in either the LDAP identity store or the Oracle Identity Manager database.

   Doing so will reset that user's attributes to their unmasked values, allowing them to see their own masked record in employee self-service, deduce other people's identities by following the hierarchy, and so on.

In short, it is essential to maintain close access control to databases holding live cloned data, and make testers aware of their obligations and responsibilities regarding the data. As far as is possible, the processes around test data based on live data should mirror the processes around the live data itself. In particular, testers must not use privileged access to look beyond what they need to perform the required tests. For example, they must not try to work out to whom the data pertains, or try and find private information to satisfy their own curiosity.

A policy subject is the target resource to which the policies are attached. Examples include Web services endpoints, Web service clients, SOA service endpoints, SOA clients, and SOA components.

Directly attaching one or more policies to a policy subject is referred to as Local Policy Attachment (LPA). The key tasks related to LPAs include:

• Attaching policies to a single Web service endpoint

• Managing and disabling policies at an endpoint

• Removing (detaching) policies from a Web service endpoint

• Troubleshooting Web service security

To locate the procedures for these tasks, see Attaching Policies Locally in the Oracle Fusion Applications Developer's Guide .

A policy set, which can contain multiple policy references, enables policies to be attached globally to a range of endpoints of the same type. By attaching policies globally in this way, referred to as Global Policy Attachment (GPA), it is possible to ensure that all subjects are secured by default.

The key tasks related to GPAs include the following:

• Creating and managing policy sets

• Validating policy sets

• Enabling and disabling policy sets globally and for specific endpoints

• Determining what policies are enforced when both LPA and GPA are defined

• Viewing policies attached to a Web service

• Troubleshooting Web service security

To locate the procedures for these tasks, see Attach Policies Globally in the Oracle Fusion Applications Developer's Guide .

Oracle Web Services Manager supports three Web services security profiles:

• AuthN Profile

• SSL Profile - provides transport-level security

• Message Security Profile - provides message-level security

Out-of-the box, Oracle Fusion applications are provisioned with the AuthN profile. You can move your deployment to a different profile if needed.

During provisioning, all Oracle Fusion Applications domains are set up to use a common keystore and credential store, whereas the Oracle Identity Management domain (which includes Oracle Identity Manager) uses a separate keystore, and stores credentials in a logical domain. Provisioning does not set up trust between these keystores. This section explains how to exchange trust with the Oracle Identity Manager domain, enabling Web services security when this domain is involved.

Encryption Type: REQUIRED

Checksum Level: REQUIRED

1. On the server, locate the sqlnet.ora configuration file in the following directory of the database Oracle Home:

   ORACLE_HOME/network/admin
   

2. Using a text editor, look for the following entries (or similar entries) in the sqlnet.ora file:

   SQLNET.ENCRYPTION_SERVER = REQUIRED
   

   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>
   

3. Repeat this procedure to configure encryption on the other system.

SQLNET.ENCRYPTION_SERVER = [accepted | rejected | requested | required]
SQLNET.ENCRYPTION_TYPES_SERVER = (valid_encryption_algorithm )
SQLNET.CRYPTO_SEED = <randomstring_for_this_deployment_up_to_70_characters>

SQLNET.ENCRYPTION_CLIENT = [accepted | rejected | requested | required]
SQLNET.ENCRYPTION_TYPES_CLIENT = (valid_encryption_algorithm )

1. Create a backup copy of the following directory:

   Oracle_BI1/common/epmstatic/wspace/js/directory
   

2. Delete all the .js files except DIRECTORY_NAME from each subdirectory of Oracle_BI1/common/epmstatic/wspace/js.

The back-channel refers to zones and network paths that are not directly accessible to external users or client programs.

In the Oracle Fusion Applications environment, back-channel communication is conducted by:

• WebGate in Oracle HTTP Server within the Web Tier, using Oracle Access Protocol (OAP) to communicate with Oracle Access Manager

• Managed and administration servers for the various product families in the Application Tier

• Database and LDAP servers in the Data Tier

• Oracle Fusion Web Services

For implementation details for securing back-channel communications, see Secure Web Services.

This section explains the Web services policies that external clients can use to further secure communication. The first step is to choose the appropriate mechanism for the client application; the second one is to configure the chosen mechanism.

The policy oracle/wss11_saml_or_username_token_with_message_protection_service_policy contains the following assertions:

• oracle/wss11_saml_token_with_message_protection_service_template: a SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard.

• oracle/wss11_username_token_with_message_protection_service_template: a username token authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard.

• oracle/wss_saml_token_bearer_over_ssl_service_template: a SAML-based authentication using credentials provided in SAML tokens with confirmation method 'Bearer' in the WS-Security SOAP header; it verifies that the transport protocol provides SSL message protection.

• oracle/wss_username_token_over_ssl_service_template: a username token authentication using the credentials in the UsernameToken WS-Security SOAP header to authenticate users against the configured identity store; it verifies that the transport protocol provides SSL message protection.

• oracle/wss_http_token_over_ssl_service_template: HTTP authentication using credentials extracted from the HTTP header to authenticate users against the configured identity store; it verifies that the transport protocol is HTTPS.

To further the security of Web Services, keep in mind the following adjustments and recommendations:

• Choose a more secure policy appropriate for all the internal Web services; it is possible to choose to not distinguish between internal and external, and use the same policy for all Web services.

• When changing the attachment of security policies, note that:

  • The client policy must be changed accordingly.

  • The client and callback policies must be compatible with the service being invoked; otherwise the Web service invocation will not work.

  • In case of exporting 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.

  • Use the same GPA policy across all the domains if the domain-wide GPA policy is changed.

• If a secure sockets layer (SSL) policy is used, verify the following:

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

  • The SSL variables and client have been set to go to OHS and then load balancer (LBR) if the SSL terminates at the LBR level.

  • The policies for SAML Token (Sender Vouches) have been configured over SSL for two-way SSL. Other authentication tokens such as username token, and SAML bearer token require only one-way SSL.

Oracle Fusion Applications provisioning sets up the keystore with self-signed certificates that can be chosen to replace keys and certificates. For example, if there is an enterprise CA, its can be used to generate keys and certificates, but it is essential to:

• Configure the 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 configured for Oracle Web Services Manager (OWSM) is used for signing SAML Sender Vouches assertions. The certificates placed in the OWSM keystore are for verifying SAML assertions.

  If the enterprise CA is put in the OWSM keystore, every certificate issued by the enterprise is acceptable for verifying assertion unless Web services is configured to accept only the list of SAML signers. For detailed information, see Configure the Token Issuer Trust (Server Side).

• Enable hostname verification by setting the value of wsm.ignore.hostname.verification to false. By default, host name verification is turned off in OWSM.

During the Oracle Fusion Applications installation, a password for the Oracle Fusion Middleware administration user must be provided; this account is used to log in to Fusion Applications Control and to the Oracle WebLogic Server Administration Console.

In environments where the FMWAdmin user and the FAAdmin user are different users, the password of the FMWAdmin user can be changed using either the Oracle WebLogic Server Administration Console or the WLST command line, as explained in Change the Oracle Fusion Middleware Administrative User Password Using the Command Line, and Change the Oracle Fusion Middleware Administrative User Password Using the Administration Console.

In environments where those two users are the same user (that is, the FAAdmin user), then use PRT to change the password of the FAAdmin user, as explained in Invoke PRT in Interactive Mode.

FA installations need periodically to change passwords stored in the Identity Store. The Password Reset Tool meets this need by allowing to:

• Change the password of the FAAdmin user

• Change the password of the OAMAdmin user

• Change the passwords of bind users used by Fusion Applications

• Regenerate random passwords for all application id users

Application id user passwords are not used for login in, but internally by the system, for example, when wiring connections between components. Application id user passwords are set randomly during provisioning and can be reset randomly with PRT.

PRT changes the password of the FA administration user only if that user is FAAdmin; if the FA administration user has been set (during FA provisioning) to a user different than FAAdmin, then PRT will not change that user's password.

The use of this tool is explained in the following sections:

• Prerequisites

• Invoke PRT in Interactive Mode

The Password Change Utility (PCU) is the tool that must be used to reset database schema passwords in a provisioned Fusion Application environment.

Using this tool, it is possible to update:

• Database schema passwords

• Datasource passwords using the schema users listed under schemas section of the input configuration (INI) file

• Credential store keys

• The ESS wallet and the ESS registry password

• The ESSBase password

• The BI repository password (and activate the new repository)

• The ODI password

• The IIR password.

• The search schema FUSION_DISCUSSIONS_CRAWLER password for Announcement and Jive Forums User defined sources using searchadmin API

• In release 12 , for IDM decoupled environments, PCU updates the schema password of FUSION_OPSS in bootstrap wallets in the following location <APPLTOP>/instance/domains/<domainhost>/<domainname>/config/fmwconfig/bootstrap/cwallet.sso

In addition, this tool also allows to:

• Seed new CSF keys for new schemas and new system user CSF keys

• Validate passwords stored in the LDAP store

• Use a complexity check for the submitted passwords.

Details about PCU features and usage are found in the following sections:

• Use PCU

• Validate Password Complexity

• Run templateGen

• Run iniGen

• Run PCU Offline

• Additional PCU Features

• Encrypt and Decrypt with lcmcrypt

The Certificate Renewal Utility (CRU) updates weblogic and OWSM self signed certificates.

The utility details are explained in the following sections:

• About CRU

• Locate CRU

• Use CRU for fa/weblogic Certificates

• Use CRU for OWSM Certificates