Skip Headers
Oracle® Fusion Applications Administrator's Guide
11g Release 6 Refresh 4 (11.1.6)

Part Number E14496-14
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

6 Securing Oracle Fusion Applications

This chapter explains the security features available to all Oracle Fusion applications. It explains the enterprise identity store, identity provisioning, authorization policies, roles, audit trail, SSL configuration, data masking, securing Web services, and customizing security.

This chapter contains the following topics:

The high-level information presented in this chapter includes links to other documents where the topic is explained in detail.

For additional information about application security, see the following documents:

For a detailed list of administrative tasks and pointers to further documentation, see Oracle Fusion Applications Administrator and Implementor Roadmap.

6.1 Introduction to Security

Oracle Fusion Applications use the services of the Oracle Platform Security Services (OPSS) to secure applications.

OPSS is a security platform that provides enterprise product development teams, systems integrators, and independent software vendors with a standards-based enterprise-grade security framework for Java SE and Java EE applications. Using OPSS, Oracle Fusion Applications benefit from the same, uniform security, identity management, and audit services across the enterprise.

The intended audience for this chapter are application security administrators and system security administrators.

Oracle Fusion Applications provisioning sets up the security infrastructure, including:

For instructions about protected URIs and configuring Oracle ADF applications with Oracle Access Manager SSO, see the "Integration with Oracle ADF Applications" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

For details about security tasks, including creating and managing users and roles, function and data security, audit, and compliance tasks, see the Oracle Fusion Applications Security Guide.

6.2 About the Enterprise Identity Store

Oracle Fusion applications run within a container in the Oracle WebLogic Server. This container handles authentication automatically for the application running in it by intercepting all requests to the application and ensuring that users are properly authenticated and the security context is propagated, as appropriate, before the request can proceed forward.

Note:

The Subject creation is automatic, but the security context propagation requires application configuration.

Fusion Applications use LDAP-based authenticators; Fusion Application identity provisioning sets up and wires WebLogic domains with the appropriate authenticators during the Fusion Application installation.

Important:

Any LDAP-based authenticator, other than the DefaultAuthenticator, requires that the flag UseRetrievedUserNameAsPrincipal be set. During installation, this flag is automatically set in the DefaultAuthenticator.

For details about bootstrap identity provisioning, such as super administrators for Fusion pillars, see Section 6.3.

6.2.1 Supported LDAP Identity Providers

Fusion Applications support the following LDAP identity store types:

  • Oracle Internet Directory 11g

  • Active Directory 2008

6.2.2 Configuring the Identity Store

Multiple LDAP authenticators can be configured in a given context. For the algorithm that selects the identity store to initialize from a stack of authenticators, see the "Configuring the Identity Store Service" section in the Oracle Fusion Middleware Application Security Guide.

Note:

The Oracle WebLogic Server Administration Console is the recommended tool to configure authenticators, but this configuration can also be alternatively carried out with WLST commands. For the list of all available WLST commands, see Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

The specification and configuration of LDAP authenticators is carried out with the Oracle WebLogic Administration Console. For details, see the "Configuring Authentication Providers" chapter in the Oracle Fusion Middleware Securing Oracle WebLogic Server.

It is important to keep the username attribute on the authenticator synchronized with the corresponding identity store property. For details, see note at the end of the table of identity store properties in the "LDAP Identity Store Properties" section in the Oracle Fusion Middleware Application Security Guide.

It is also important that the following two time intervals be equal:

  • The number of seconds that cached entries stay in the cache. This value is controlled by the WebLogic authenticator parameter Group Hierarchy Cache TTL, which by default is 60 seconds.

  • The number of seconds after which group membership changes are in effect. This value is controlled by the system property jps.subject.cache.ttl, which by default is 60 seconds.

If the Group Hierarchy Cache TTL value is changed, then that new value must also be set with the system property jps.subject.cache.ttl. For example, if the value of Group Hierarchy Cache TTL is changed to 55,000 (milliseconds), then jps.subject.cache.ttl must be reset as follows:

-Djps.subject.cache.ttl 55000

6.3 Provisioning Identities

Provisioning as a whole encompasses all the operations required to install, configure, and deploy applications product offerings. Identity provisioning is a subset of this process which populates the users and groups needed for deployment and ongoing administration.

This section contains the following topics:

6.3.1 Identity Provisioning Concepts

During the identity provisioning stage of installation, Oracle Fusion Applications require the existence of certain users with specific privileges. These administrative users reside in a secure, central repository called the identity store. This section explains the phases of identity provisioning, what users or groups are needed for provisioning, and the users and groups that exist at the end of the process.

This section contains the following topics:

6.3.1.1 Administrators For Fusion Applications

The application provisioning process bootstraps the provisioned environment with two administrator groups for each application family.

These two administrator groups are:

  • A system administrator

    A directory group representing the WebLogic Server domain administrators for all the domains.

  • An application administrator

    A directory group with an assigned enterprise role reflecting all the application roles and delegation privileges for all the applications in a given family.

The purpose of creating these "Super Administrators" during provisioning is to enable ongoing administration and/or delegation privileges.

The above process facilitates separation of duties between system administration and application administration responsibilities, but you are free to assign the same user to both hierarchies ("system admin" and "application admin").

Table 6-1 shows the groups that are created for each application family:

Table 6-1 Provisioned Administrator Groups

Product Family/Product System Administrator Group Application Administrator Group

Oracle Fusion Supply Chain Management

FSCMSysAdmin

FSCMAppAdmin

Oracle Fusion Customer Relationship Management

CRMSysAdmin

CRMAppAdmin

Oracle Fusion Human Capital Management

HCMSysAdmin

HCMAppAdmin

Oracle Fusion Financials

FINSysAdmin

FINAppAdmin

Oracle Fusion Procurement

PRCSysAdmin

PRCAppAdmin

Oracle Fusion Project

PRJSysAdmin

PRJAppAdmin

Oracle Fusion Incentive Compensation

OICSysAdmin

OICAppAdmin


In addition a single user, known as the super user, is set up to belong to all the administrator groups. That user becomes the administrator for all middleware and the application administrator for all product families.

Figure 6-1 shows the relationship between these groups.

Figure 6-1 Super-User and Administrators

Description of Figure 6-1 follows
Description of "Figure 6-1 Super-User and Administrators"

6.3.1.2 Two Types of Users During Provisioning

It is important to distinguish between the two types of super-administrators that exist in the provisioning process.

  • Pre-seeded bootstrap user

  • Designated super-user

In the context of the pre-seeded user, provisioning employs an identity known as the App ID that is required to bootstrap the WebLogic domains. The pre-configuration phase of provisioning automatically generates the credential needed for this App ID user.

In the context of the designated super user, during the interview phase of provisioning, you are asked to specify the user ID of the designated "real" user who will be set up as the Middleware Administrator and Functional Setup Manager.

For example, if you want a "real" user such as "cn=john.doe,cn=users,cn=acme,cn=com" to be the super user, provide "john.doe" as the user ID during provisioning. This user will be set up as the super user in the identity store.

Note:

It should be emphasized that the identity seed data that is used in the LDIF file to configure the WebLogic domains does not use real user DNs.

6.3.2 WebLogic Authenticators and the Primary Identity Store

When Oracle WebLogic Server is installed, the default authenticator is based on an embedded LDAP store.

As part of Oracle Fusion Applications provisioning, the default authenticator based on the embedded LDAP is deleted. Upon completion of Oracle Fusion Applications provisioning, the primary and only identity store will be your external LDAP store. The bootstrap identity used to configure the domains during the provisioning process will be pre-seeded in the external LDAP through the LDIF file, as explained in Section 6.3.1.2.

6.3.3 Provisioning Steps

The identity provisioning process consists of distinct phases.

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.

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.

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

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 the Oracle Fusion Applications Installation Guide.

6.3.4 Best Practices for the Administrator Groups

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) you can 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 your site.

6.3.5 Managing Identities after Deployment

Oracle Identity Manager is the best-in-class user provisioning and administration component in Oracle Fusion Middleware.

Oracle Identity Manager automates the process of adding, updating, and deleting 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 Oracle Identity Manager Administrative Console.

For more information about provisioning and managing identities, see:

6.4 Managing Authorization Policies

Authorization is the most sensitive and application-specific security concept. At its very core, authorization protects access to application resources through the enforcement of policies, which are stored in the domain policy store. Authorization determines what types of actions, tasks, or services a user can access.

In most cases, the definition of application policies begins during the design of the application. This definition includes identifying application privileges and application roles, the hierarchical relationships between application roles, and categorizing them into products and Java EE applications.

The policy model is based on a number of logical entities, such as resource types, resource instances, entitlements (also known as permission sets), application roles, and enterprise roles. For details about these entities and the logical model of a policy, see the "Terminology" section in the Oracle Fusion Middleware Application Security Guide.

This section includes the following topics:

6.4.1 Managing Oracle Fusion Application Policies

An Oracle Fusion application policy is either a functional policy or a data security policy. Both these policies define who can do what on a resource.

A data security policy includes a condition, while a functional policy does not. The condition identifies a row or a set of rows in a business object, and the privileges the data security grants are for only the data that meets the condition. A functional policy, instead, assigns permissions to resources or code artifacts (such as task flows, pages, Java methods, or UI components) and grants a specific set of actions on each resource.

Data security policies are stored in the transactional database; functional policies are stored in the domain policy store.

Oracle Authorization Policy Manager is the recommended tool to administer application policies once the application has been deployed. This graphical interface tool allows application security administrators to provision, search, and modify application functional and data security policies. Using this tool they can, for example, remove a resource from an entitlement or change the actions granted to a resource in an entitlement.

For details about the most frequently uses of Oracle Authorization Policy Manager, see the "Managing Policies and Policy Objects" section in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition) where the following typical administrative tasks are described:

  • Managing application roles

  • Managing application resource types

  • Managing application resources

  • Managing application entitlements

  • Creating and modifying an application policy

  • Viewing the enterprise role hierarchy

  • Managing the application role hierarchy

  • Mapping application roles to an enterprise role

  • Mapping enterprise roles to an application role

For details about configuring application roles, see Section 6.5.1.

6.4.2 Managing System Policies

Oracle Enterprise Manager Fusion Middleware Control is the recommended tool to administer system policies. These are policies that pertain to the whole domain, as opposed to application policies, which pertain a particular application.

A principal policy is a system policy that grants permissions to a list of users or enterprise groups. A codebase policy is a system policy that grants permissions to a piece of code or a URL (typically represented by an EAR or a JAR file); for example, an application using the Credential Store Framework requires an appropriate codebase policy.

Fusion Middleware Control allows the creation and modification of both these types of system policies. For details about the procedure to follow, see the "Managing System Policies" section in the Oracle Fusion Middleware Application Security Guide.

An alternative way to administer policies (both system and application policies), although not as convenient but occasionally useful, is using WLST commands. For a complete list of security-related commands, see the "OPSS Scripts" appendix in the Oracle Fusion Middleware Application Security Guide.

6.4.3 Reconciling GUIDs

The recipient of a grant can be either an application role or an enterprise role. In Oracle Fusion Data Security and policy grants this recipient is identified by a GUID, and it is crucial for the security system to work as expected that these GUIDs be consistent. Since GUIDs are not preserved by migration, the GUIDs in the Oracle Fusion Data Security policies and in the policy store policies must be reconciled when, for instance, migrating to a staging or a production environment.

The java utility program DSDataMigrator reconciles GUIDs by modifying GUIDs in Oracle Fusion Data Security so that the GUIDs of the role entries in the identity and policy stores are consistent with those in Oracle Fusion Data Security.

DSDataMigrator needs not be run when:

  • The user interface is used to create new policies or to modify existing ones.

  • The system is provisioned for the first time (GUID reconciliation happens automatically in this case).

  • A patch containing Grants Seed Data is applied to the environment (GUID reconciliation happens automatically in this case).

DSDataMigrator must be run when:

  • A policy stripe was dropped or recreated.

  • A role was dropped or recreated.

  • An SQL script was used to upload grants data.

  • Patching the infrastructure fails, such as, when the LDAP server went down.

  • The LDAP server was swapped out.

  • FndGrantsSD.xml data was loaded to the database using SDF programs directly bypassing the patching infrastructure.

  • The file jps-config-jse.xml contains invalid or incorrect configurations.

  • Security data was migrated to a staging or to a production environment.

  • Enterprise roles in the identity store were dropped and imported again using a migration tool.

This section includes the following topics:

6.4.3.1 Prerequisites to Running DSDataMigrator

Before an administrator runs this command, it is assumed that:

  • The Fusion Application has been installed (so that Oracle Fusion Data Security has been loaded).

  • The XML policies (jazn-data.xml) have been migrated to an Oracle Internet Directory server.

  • The FND_GRANTS table has been backed up, as illustrated in the following invocation:

    >sqlplus sys as sysdba
    create table FUSION.FND_GRANTS_OLD as select * from FUSION.FND_GRANTS;
    
  • The classpath in the shell where the command is to be run contains the following JAR files:

    • MW_HOME/atgpf/atgpf/modules/oracle.applcore.model_11.1.1/Common-Model.jar.

    • MW_HOME/atgpf/atgpf/modules/oracle.applcore.model_11.1.1/DataSecurity-Model.jar.

    • MW_HOME/oracle_common/modules/oracle.adf.model_11.1.1/adfm.jar.

    • MW_HOME/oracle_common/modules/oracle.adf.share_11.1.1/adf-share-support.jar.

    • MW_HOME/oracle_common/modules/oracle.adf.share.ca_11.1.1/adf-share-ca.jar.

    • MW_HOME/oracle_common/modules/oracle.adf.share.ca_11.1.1/adf-share-base.jar.

    • MW_HOME/oracle_common/modules/oracle.adf.share_11.1.1/jsp-el-api.jar.

    • MW_HOME/oracle_common/modules/oracle.adf.businesseditor_11.1.1/adf-businesseditor.jar.

    • MW_HOME/oracle_common/modules/oracle.adf.share_11.1.1/adflogginghandler.jar.

    • MW_HOME/oracle_common/modules/oracle.jps_11.1.1/jps-manifest.jar.

    • MW_HOME/modules/javax.jsp_1.2.0.0_2-1.jar.

    • MW_HOME/oracle_common/modules/oracle.mds_11.1.1/mdsrt.jar.

    • MW_HOME/oracle_common/modules/oracle.javatools_11.1.1/resourcebundle.jar.

    • MW_HOME/oracle_common/modules/oracle.javatools_11.1.1/javatools-nodeps.jar.

    • MW_HOME/wlserver_10.3/server/ext/jdbc/oracle/11g/ojdbc5.jar.

  • Optionally, the identity store has been seeded.

Notes:

The files Common-Model.jar and DataSecurity-Model.jar are expected to be in the paths indicated above, but, depending on the environment, the could be installed in some other location. To find out the location of those files in your environment, invoke the following commands at the top of the MW_HOME directory:

>find . -name "Common-Model.jar"
>find . -name "DataSecurity-Model.jar"

DSDataMigrator is executed automatically when (and only when) a patch containing the data security grants seed data file FndGrantsSD.xml is applied to the environment. In particular, the script is not executed automatically if the seed data file is applied manually.

6.4.3.2 DSDataMigrator Syntax

DSDataMigrator is located in the directory oracle.apps.fnd.applcore.dataSecurity.util, and it has the following syntax (arguments are written in separate lines for the sake of clarity only):

java -classpath $CLASSPATH 
-Doracle.security.jps.config=path to the jps-config-jse.xml file 
-DFND_DS_GUID_RECON_LOG_DIR=path to the log output directory
DSDataMigrator -dsdburl dsdbURL
               -dsdbuser dsdbUser
               -silentMode <true_or_false>
               -forceProcessAllRows true|false
               -policyStripe FA policy stripe name
               -idStoreOnly true|false
               -validationMode true|false
               -multiTenantAware true|false
               -enterprise_id enterpriseId

When run and before processing security data, the command prompts the administrator for the database password.

The meaning of the arguments is as follows:

  • oracle.security.jps.config specifies the location of the configuration file jps-config-jse.xml where the policy store and identity store are configured. This file must include the appropriate bootstrap credentials to access the policy store. The following fragment of a configuration file illustrates the specification of credentials for a policy store instance:

    <serviceInstance provider="ldap.policystore.provider" name="policystore.ldap">
      <property value="OID" name="policystore.type"/>
      <property value="bootstrap_123456" name="bootstrap.security.principal.key"/>
      <property value="cn=myFarm123" name="oracle.security.jps.farm.name"/>
      <property value="cn=FusionAppsPolicies" name="oracle.security.jps.ldap.root.name"/>
      <property value="ldap://example.com:33060" name="ldap.url"/>
    </serviceInstance>
    
    <serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
      <property value="./bootstrap" name="location"/>
    </serviceInstance>
    

    Typically, the file jps-config-se.xml is located in the directory DOMAIN_HOME/servers/server_name/CommonDomain/config/fmwconfig. If this file is moved to a different location, the bootstrap directory (which contains the file cwallet.sso) must also be moved to that new location.

  • dsdburl specifies the URL of the data base where Oracle Fusion Data Security is stored.

  • dsdbuser specifies the name of the user that can access the data base.

  • silentMode specifies whether the command should raise exceptions when an entry is not found in the OID server. Set to TRUE to prevent raising these kind of exceptions; otherwise, set to FALSE. Default value: FALSE.

  • forceProcessAllRows specifies whether all rows in the FND_GRANTS table should be processed. Set to TRUE to process all rows in that table; otherwise, set to FALSE. The default behavior is FALSE and processes just those rows with the compile_flag is set to Y.

  • policyStripe specifies the name of the Oracle Fusion application stripe in the policy store. Typical values are fscm, crm, and hcm.

  • idStoreOnly specifies whether only data security grants granting to enterprise roles should be processed. Set to TRUE to process only grants granting to enterprise roles; otherwise, set to FALSE to process all grants. When set to TRUE, the value of the argument policyStripe is ignored. Default value: FALSE.

  • validationMode specifies to run the script in read only mode (validation mode). Set to TRUE to run the script without updating the database data. Set to FALSE to run the script and update database data. Default value: FALSE. A validation run of the script is useful to find out if any reconciliation is needed between the database and the LDAP store.

  • multiTenantAware specifies whether the environment is a multi-tenant environment; applies only to multi-tenant environments; set to TRUE to indicate a multi-tenant environment. Default value: FALSE. When set to TRUE, the argument enterprise_id must be passed.

  • enterprise_id specifies the tenant id for which the reconciliation will be performed; if specified, the value passed for mutiTenantAware must be TRUE. This value is the attribute orclMTTenantGUID in the LDAP repository that is stored in the ENTERPRISE_ID column of the ApplCore/Application tables.

6.4.3.3 Examples of Use

Running the program without any arguments prints out the usage instructions; a sample invocation (in a non-multi-tenant environment) is the following:

java -classpath $CLASSPATH
-Doracle.security.jps.config=/home/sayarram/work/jps/jps-config-jse.xml
oracle.apps.fnd.applcore.dataSecurity.util.DSDataMigrator 
-dsdburl myURL -dsdbuser fusion -silentMode true 
-forceProcessAllRows true -policyStripe fscm

When run, the program generates a log file with the details of records processed, warnings, errors, and a summary of what has been processed.

A sample invocation in a multi-tenant environment is the following:

java -classpath $CLASSPATH -Doracle.security.jps.config=/home/sayarram/work/jps/jps-config-jse.xml
oracle.apps.fnd.applcore.dataSecurity.util.DSDataMigrator
-dsdburl myURL -dsdbuser fusion -silentMode true -forceProcessAllRows true
-policyStripe fscm -multiTenantAware true -enterprise_id 202

6.4.4 Managing Data Security

For details on topics related to data security management, see the following documents:

For details about creating data role templates, see the "Oracle Fusion Applications Data Role Templates" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

6.5 Configuring Roles

An enterprise role or enterprise group is a collection of users and other enterprise roles, and it is stored in the domain identity store. An application role is a collection of users, enterprise roles, and application roles, and it is stored in the domain policy store.

In the Oracle Authorization Policy Manager environment, enterprise roles are referred to as external roles. In the Oracle WebLogic Administration Console, enterprise roles are referred to as enterprise groups.

Roles can be structured in a hierarchy by the relation "inherits." If a parent role inherits a child role, then the parent role can do anything that the child role can do (in addition to what the parent role can do).

Mapping an enterprise role to an application role establishes that the enterprise role inherits the application role, thus, the privileges of the enterprise role become the union of its privileges and those of the application roles to which it is mapped.

For details about managing the role mapping after the application has been deployed, see the following topics in Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition):

For details about managing data security policies in Oracle Fusion applications, see the "Managing Oracle Fusion Applications Data Security Policies" section in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

For details about generating data roles with data role templates, see the "Oracle Fusion Applications Data Role Templates" section in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

This section includes the following topics:

6.5.1 Configuring Oracle Fusion Application Roles

Oracle Fusion applications use the following enterprise and application roles in their application policies and data security policies:

  • Data role, an enterprise role used exclusively in data security policies. It can inherit Job, Duty, and Abstract roles. A number of data roles are provisioned with each Oracle Fusion application.

  • Job role, or Business role, is an enterprise role that corresponds with a job or business occupation. A Job role must inherit at least a Duty role.

  • Duty role, or Task role, is an application role that corresponds with the duties of a job.

  • Abstract role is an enterprise role that can be associated with any user, irrespective of his job or duties. Typical examples of this role are Employee, Manager, Customer, and Supplier. Several job roles are provisioned with each Oracle Fusion application. An Abstract role must inherit at least a Duty role.

Oracle Authorization Policy Manager is the recommended tool to manage application roles once the application has been deployed. Using this tool an administrator can, for example, create, remove, or modify an application role; or modify the hierarchy of application roles; or create, remove, or modify the application role category. For details about the tool, see the "Managing Applications" section in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

Table 6-2 lists the equivalent terms used in the physical and reference implementations. The terminology in the physical implementation follows the one used in Oracle Fusion applications; the terminology in the reference implementation follows the one used in the Oracle Authorization Policy Manager graphic interface.

Table 6-2 Equivalent Terminology

Physical Implementation Reference Implementation

Data role

Enterprise role used only in data security policies. Typically, the name of a data role has the suffix _DATA.

Job

Enterprise role mapped to application role. Typically, the name of this role has the suffix _JOB.

Abstract role

Enterprise role, which are persisted as LDAP groups and can be managed with Oracle Authorization Policy Manager and Oracle Identity Management.

Duty

Application role used only in application policies.

Privilege

Entitlement (or permission set).

FND Grant (or Foundation Grant)

Data security policy, which ties a data role or job role to a specific set of data.


For definitions and details about the terms in the reference implementation, see the "Understanding the Policy Model" section in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).

6.5.2 Configuring Enterprise Roles

A security administrator uses integrated Oracle Identity Management pages to create and manage enterprise (job) roles in Oracle Fusion applications. For details, see the "Organization and Role Management" section in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager.

6.6 Configuring Audit Trail

Auditing features are provided through Audit Trail, a history of the changes that have been made to data in Oracle Fusion Applications. Audit Trail enables you to track who made changes to data, at what time, and how the value changed.

Note:

Oracle Fusion Middleware Audit Framework is a separate service that provides a centralized audit framework for the middleware family of products. For details about this feature, see "Configuring and Managing Auditing" in the Oracle Fusion Middleware Application Security Guide.

6.7 Configuring SSL for Oracle Fusion Applications

SSL provides secure communication between the paths that connect endpoints. For example, the path between Oracle WebLogic Server and an LDAP directory server is secured through SSL.

This section contains the following topics:

6.7.1 SSL Configuration in Oracle Fusion Middleware

Oracle Fusion Middleware provides SSL configuration features across the three tiers of the enterprise stack (Web, Middle, and Data tiers). SSL configuration is consistent and uniform across all Oracle Fusion Middleware system components and applications.

This section contains the following topics:

6.7.1.1 SSL and Infrastructure Hardening

SSL-enabling communication paths is one element in a hardening process whose aim is to ensure that all appropriate security features are activated and configured correctly in the various major systems and subsystems that comprise Oracle Fusion Middleware.

The discussion in this document is limited to SSL features available to Oracle Fusion applications. For information about other elements of hardening, see the Oracle Fusion Applications Security Hardening Guide.

6.7.1.2 Communication in the Three-Tier Model

Oracle Fusion Middleware supports a three-tier structure: the Web tier contains load balancers and other components outside the firewall, the middle tier hosts Oracle WebLogic Server and its applications, and the Data tier contains databases and directories. Different administration tools are shown at the top of the figure.

Figure 6-2 shows the location of key elements in this architecture:

Figure 6-2 Oracle Fusion Middleware and the Three-Tier Model

Description of Figure 6-2 follows
Description of "Figure 6-2 Oracle Fusion Middleware and the Three-Tier Model"

In the figure, the vertical broken lines represent firewalls. The circles represents listeners that can be SSL-enabled for secure communication. As the figure shows, all critical communication paths can be protected with SSL regardless of the tier(s) involved.

For more information, see the "About SSL in Oracle Fusion Middleware" section in the Oracle Fusion Middleware Administrator's Guide.

6.7.2 SSL Configuration for Oracle Fusion Applications

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

This section contains the following topics:

6.7.2.1 Basic Network Topology

Figure 6-3 shows a high-level representation of a three-tier network topology in the typical Oracle Fusion Applications environment:

Figure 6-3 SSL Connections for Basic Network Topology

Description of Figure 6-3 follows
Description of "Figure 6-3 SSL Connections for Basic Network Topology"

Notes:

  • The diagram shows some representative domains.

  • OAP is the Oracle Access Protocol used by Oracle Access Manager. LDAPS is the LDAP-over-SSL protocol.

Several approaches to configuring SSL are available in the Oracle Fusion Applications environment:

  1. You can choose not to enable SSL connections during provisioning.

  2. You can choose to SSL-enable connections to certain components during provisioning.

    These connections are shown as solid lines (red) in the diagram and include IdM components like Oracle Access Manager and Oracle Internet Directory. Table 6-3 lists these connections.

  3. You can SSL-enable connections post-provisioning.

    If you started with Option 2, you can now protect service-to-service connections like those shown in dotted lines (blue) in the diagram; this includes, for example, connections to Oracle Business Intelligence, ECSF, and external Web services. For details about this wiring, see Section 6.7.5.

    If you started with Option 1, you would SSL-enable Oracle Identity Management first (see Section 6.7.3), followed by the service-to-service connections (see Section 6.7.5).

Note the following assumptions about this topology:

  • In most environments, the Fusion Applications middleware servers operate on an isolated network within the larger corporate network.

    This means that such components as Oracle HTTP Server (OHS), Oracle WebLogic Server, Oracle Business Intelligence, and others required for the Oracle Fusion Applications instance all run within a single isolated network.

  • Likewise, the Oracle Fusion Applications database runs in either the same isolated network or on its own isolated network that can only be reached by means of the application's private network.

  • Because most business applications do not face the extranet, the HTTP server (OHS) tier is typically not segregated into its own DMZ.

  • External dependencies for Oracle Identity Management components, represented in the figure by Oracle Access Manager and Oracle Internet Directory servers, are assumed to reside outside this isolated network.

6.7.2.2 Provisioned SSL Connections

As mentioned earlier, Oracle Fusion applications are configured with SSL for client traffic inbound to OHS and traffic to and from the identity management zone. Table 6-3 shows the connections that are SSL-enabled at provisioning:

Table 6-3 Provisioned SSL Connections

Connection Path Protocol Default SSL Connection

Incoming HTTP Traffic (client to HTTP server)

HTTPS

One-way SSL (trust in server)

mod_webgate to Oracle Access Manager

OAP

One-way SSL (trust in server)

Oracle WebLogic Server to LDAP server (Oracle Internet Directory/Oracle Virtual Directory)

LDAPS

One-way SSL (trust in server)


SSL can also be enabled for these connections post-provisioning by following the instructions in Section 6.7.3.

6.7.3 End-to-End SSL for Oracle Fusion Applications

This section provides step-by-step procedures to enable SSL between Oracle HTTP Server (OHS) and Oracle WebLogic Server (WLS). This includes SSL traffic to Oracle HTTP Server, on Oracle Fusion Applications domains, and between Oracle Fusion Applications domains and components in the Identity Management (IdM) domain. SSL is enabled using a self-signed certificate, with one-way SSL communication (server-auth mode).

Procedures for supplementary tasks like keystore and certificate maintenance are also included.

This document contains the following topics:

6.7.3.1 Background and Scope

Keep the following points in mind as you work through this section:

  • The procedures apply to Oracle Access Manager version 10g.

  • The procedures are illustrated using the benefits server in HCMDomain but are generally applicable.

  • The configuration tools prompt you for passwords when necessary. The examples shown here do not display password input or entry.

  • The procedures typically rely on the self-signed certificates that are created by Oracle Fusion Application provisioning tools, and you do not need to recreate them again.

  • APPLTOP is a placeholder that refers to the top-level directory where Oracle Fusion Applications is installed.

Figure 6-4 illustrates the SSL wiring:

Figure 6-4 SSL Connections on Oracle Fusion Applications Domains

This figure shows the SSL wiring on domains.

Two distinct component stacks are pictured here. On the left is the identity management stack, front-ended by an Oracle HTTP Server which is referred to as the Authentication OHS or Auth OHS. On the right are WebLogic and the application stack, front-ended by an Oracle HTTP Server which is referred to as the Application OHS or Apps OHS.

6.7.3.2 Enabling SSL on Oracle Fusion Applications Domains and Apps OHS

We illustrate the steps using the Benefits managed server in the HCMDomain domain. The procedure can be applied to any managed server that needs to be SSL-enabled.

This procedure consists of two distinct tasks:

  • Enable SSL on your application's WebLogic managed server

  • Enable SSL on the OHS which front-ends the Oracle Fusion Applications domain

This section contains these topics:

6.7.3.2.1 Enabling the SSL Listener on your application's WebLogic Managed Server

Take these steps to complete this task:

  1. Log in to the Weblogic Administration Console as the "faadmin" user.

  2. Navigate to Environment, then Servers, then BenefitsServer_1.

    Note:

    The Benefits server in HCMDomain is used as an example. Substitute the relevant server in your environment.

  3. Check the "SSL Listener Port Enable" box. Make sure that the SSL listener port number you select is not in use. Remember this port number for later use in the OHS configuration file.

  4. Scroll down the page and click Advanced to unhide the advanced server options.

  5. Check the WebLogic Plug-In Enabled box so that the server can receive proxied requests.

  6. Click Save.

  7. Stop the managed server.

  8. Restart the managed server to enable the SSL listener.

  9. Repeat Steps 1 through 6 for each managed server in your domain that must be SSL-enabled. For tables of managed servers by domain, see Section 6.7.3.2.5, "List of Managed Servers for Oracle Fusion Applications Domains".

Figure 6-5 shows a sample configuration:

Figure 6-5 Enabling SSL on a Managed Server

This figure shows how to set SSL on a Managed Server.
6.7.3.2.2 Enabling SSL on the Oracle HTTP Server for the Oracle Fusion Applications domain

Take these steps to enable SSL on the Apps OHS server which front-ends the Oracle Fusion Applications domain:

  1. Locate the configuration file FusionVirtualHost_hcm.conf, which resides in the following directory:

    ohs_instance/CommonDomain_webtier/config/OHS/ohs1/moduleconf
    
    /FusionVirtualHost_hcm.conf
    

    This file is generated during provisioning. Out-of-the-box, SSL is not enabled and the file must be modified manually.

  2. Update the virtual host file to enable SSL:

    1. Open the FusionVirtualHost_hcm.conf file using a text editor.

    2. Search for the string "External virtual host for hcm".

    3. Include the SSL configuration file in the OHS configuration by adding a line similar to the following below this string, ensuring the correct path:

      include "/root_dir/APPLTOP/instance/CommonDomain_webtier/config/OHS/ohs1/FusionSSL.conf"
      

      For example:

      #External virtual host for hcm
      <VirtualHost appohs.myoutsource.com:10620 >
      ServerName https://hcmppbr.host.example.com
      include "/u01/APPLTOP/instance/CommonDomain_webtier/config/OHS/ohs1/FusionSSL.conf"
      
    4. Scroll down in the file to "Context roots for application HcmBenefits".

    5. Change the port number for WebLogicCluster configuration to the SSL listener port specified in the earlier task in Section 6.7.3.2.1, "Enabling the SSL Listener on your application's WebLogic Managed Server".

    6. Next, configure the outbound connection to Oracle WebLogic Server by adding the following two lines:

      SecureProxy On
      WlSSLWallet  ~/fusionapps/wlserver_10.3/server/lib"
      

      Here is an example for the hcmBenefits context root:

      ## Context roots for application HcmBenefits
          <Location /hcmBenefits >
              SetHandler weblogic-handler
              WebLogicCluster fscmh-primary.myvhost.com:9411
              WLProxySSL ON
              WLProxySSLPassThrough ON
              RewriteEngine On
              RewriteOptions inherit
              SecureProxy On
              WlSSLWallet "/u01/APPLTOP/fusionapps/wlserver_10.3/server/lib"
          </Location>
      

      Note:

      • The port number must match the SSL listen port on the managed server (as shown in Figure 6-5).

      • The directory “~/fusionapps/wlserver_10.3/server/lib” is the location where cwallet.sso resides.

      • This directive assumes that the Web Tier shares the top-level directory with Oracle Fusion Application domains. If, however, the Web Tier is in a DMZ or it cannot share the drive with Oracle Fusion Application domains, do not perform this step. Instead, export all certificates from the wallet in "/root_dir/APPLTOP/fusionapps/wlserver_10.3/server/lib" and import them to the Web Tier wallet.

  3. Save and close the file.

  4. Stop and restart the OHS server:

    /root_dir/APPTOP/instance/CommonDomain_webtier/bin/opmnctl stopall
    /root_dir/APPTOP/instance/CommonDomain_webtier/bin/opmnctl startall
    
6.7.3.2.3 Verify SSL Configuration

Take these steps to ensure SSL is operational:

  1. Bring up the application URL and try to log in over the SSL protocol. For the Benefits application example:

    https://hcmppbr.host.example.com/hcmBenefits/faces
    
    /HcmBenefitsProcessesAdministerBenefitsWorkArea
    
  2. Repeat for other application URLs for that managed server.

6.7.3.2.4 mod_ossl Directives for Inbound SSL Configuration to Oracle HTTP Server

mod_ossl is the plug-in to Oracle HTTP Server that enables the server to use SSL. This section describes certain key directives you configure for mod_ossl to configure secure inbound client connections to Oracle HTTP Server.

The SSLProtocol Directive

The SSLProtocol directive specifies SSL protocol(s) for mod_ossl to use when establishing the server environment. Clients can only connect with one of the specified protocols.

Context: server configuration, virtual host

Syntax:

SSLProtocol [+-] protocol 

where protocol is one of: SSLv3, TLSv1, TLSv1.1, TLSv1.2, ALL

Default: SSLProtocol ALL

Example 1: To specify only SSL version 3.0, set this directive to the following:

SSLProtocol +SSLv3 

Example 2: To specify all flavors, but not SSL version 3.0, set this directive to the following:

SSLProtocol ALL -SSLv3 

The SSLCipherSuite Directive

The SSLCipherSuite directive specifies the SSL cipher suit that the client can use during SSL handshake. This directive uses a colon-separated cipher specification string consisting of prefixes and tags to identify the cipher suite.

Context: server configuration, virtual host, directory

Syntax:

SSLCipherSuite cipher-spec 

where cipher-spec is a colon-separated string consisting of prefixes plus allowed or excluded ciphers. The prefixes are shown in Table 6-4:

Table 6-4 Prefixes in SSLCipherSuite

Prefix Description

none

Adds the cipher to the list .

+

Adds the cipher to the list and places it in the correct location in the list .

-

Removes the cipher from the list (it can be added later).

!

Removes the cipher from the list permanently.


Default: ALL:!ADH:+HIGH:+MEDIUM:+LOW

Example: To specify all ciphers except MD5 strength ciphers:

SSLCipherSuite ALL:!MD5 

Table 6-5 lists the available cipher suite tags:

Table 6-5 Tags for Cipher Suite Specification

Function Tag Description

Key Exchange

kRSA

RSA key exchange

Key Exchange

kDHr

Diffie-Hellman key exchange with RSA key

     

Authentication

aNULL

No authentication

Authentication

aRSA

RSA authentication

Authentication

aDH

Diffie-Hellman authentication

     

Encryption

eNULL

No encryption

Encryption

DES

DES encoding

Encryption

3DES

Triple DES encoding

Encryption

RC4

RC4 encoding

Encryption

ECC

Elliptic curve cryptography encoding

     

Data Integrity

MD5

MD5 hash function

Data Integrity

SHA

SHA hash function

Data Integrity

SHA256

SHA256 hash function

Data Integrity

SHA384

SHA384 hash function

     

Aliases

SSLv3

All SSL version 3 ciphers

Aliases

TLSv1.1

All TLS version 1.1 ciphers

Aliases

TLSv1 .2

All TLS version 1.2 ciphers

Aliases

LOW

All low strength ciphers (export and single DES)

Aliases

MEDIUM

All ciphers with 128-bit encryption

Aliases

HIGH

All ciphers using triple DES

Aliases

AES

All ciphers using AES encryption.

Aliases

RSA

All ciphers using RSA key exchange

Aliases

DH

All ciphers using Diffie-Hellman key exchange


6.7.3.2.5 List of Managed Servers for Oracle Fusion Applications Domains

This section contains tables of the managed servers for each domain, showing which managed servers need to be SSL-enabled using the procedure shown in Section 6.7.3.2.1, "Enabling the SSL Listener on your application's WebLogic Managed Server".

Table 6-6 Managed Servers in the Oracle Fusion Human Capital Management Domain

Managed Server SSL? Application URLs

AdminServer

No

 

BenefitsServer_1

Yes

https://hcmppbr.host.example.com/hcmBenefits/faces/
HcmBenefitsProcessesAdministerBenefitsWorkArea

CompensationServer_1

Yes

https://hcmppbr.host.example.com/hcmCompensation/
faces/HcmCompWorkbenchWorkarea

https://hcmppbr.host.example.com/hcmCompensation/faces/
HcmCompAdminWorkarea

https://hcmppbr.host.example.com/hcmCompensation/faces/HcmCompPersonStatementWorkArea

https://hcmppbr.host.example.com/hcmCompensation/faces/SetupMainPage

CoreProcessesServer_1

Yes

https://hcmppbr.host.example.com/hcmCore/faces
/MyPortrait

https://hcmppbr.host.example.com/hcmCore/faces
/PersonSearch

CoreSetupServer_1

Yes

https://hcmppbr.host.example.com/hcmCoreSetup/faces
/HcmWSIntWA

Ess_server1

No

 

HCMAnalyticsServer_1

No

 

Odi_server1

No

 

PayrollServer_1

Yes

https://hcmppbr.host.example.com/hcmPayroll/faces/
ChecklistUI

https://hcmppbr.host.example.com/hcmPayroll/faces/
PayrollAdminWorkArea

https://hcmppbr.host.example.com/hcmPayroll/faces/
PayrollCalculationWorkArea

https://hcmppbr.host.example.com/hcmPayroll/faces
/PaymentDistributionWorkArea

https://hcmppbr.host.example.com/hcmPayroll/faces
/AccountingWorkarea

https://hcmppbr.host.example.com/hcmPayroll/faces
/StatutoryReportsWorkArea

Soa_server1

No

 

TalentManagementServer_1

Yes

ttps://hcmppbr.host.example.com/hcmTalent/faces/
PerformanceWorkArea

https://hcmppbr.host.example.com/hcmTalent/faces/ManageGoalsWorkArea

https://hcmppbr.host.example.com/hcmTalent/faces/ManageProfilesWorkArea

https://hcmppbr.host.example.com/hcmTalent/faces/
FacilitatorOverviewWorkArea


Table 6-7 Managed Servers in the Oracle Fusion Financials Domain

Managed Server SSL? Application URLs

Admin Server

No

 

Ess_server1

No

 

FinancialAnalyticsServer_1

No

 

FinancialCommonServer_1

Yes

https://hcmfinppbr.host.example.com/financialCommon/faces/LegalEntityDashboard

FinancialSearchServer_1

No

 

GeneralLedgerServer_1

Yes

https://hcmfinppbr.host.example.com/ledger/faces/
JournalEntryPage

https://hcmfinppbr.host.example.com/ledger/faces/
LedgerWorkArea

https://hcmfinppbr.host.example.com/ledger/faces/
XlaEssMain

PayableServer_1

Yes

https://hcmfinppbr.host.example.com/payables/faces/InvoiceWorkbench

https://hcmfinppbr.host.example.com/payables/faces
/ExpenseShell

https://hcmfinppbr.host.example.com/payables/faces
/PaymentLandingPage

ReceivableServer_1

Yes

https://hcmfinppbr.host.example.com/receivables/
faces/ReceiptsWorkArea

https://hcmfinppbr.host.example.com/receivables/
faces/TransactionsWorkArea


Table 6-8 Managed Servers in the Oracle Fusion Setup Domain

Managed Server SSL? Application URLs

AdminServer

No

 

Ess_server1

No

 

FunctionalSetupServer_1

Yes

https://hcmcmppbr.host.example.com/setup/faces
/TaskListManagerTop

HelpPortalServer_1

No

 

HomePageServer_1

Yes

https://hcmcmppbr.host.example.com/homePage
/faces/AtkHomePageWelcome

IPM_server1

No

 

Search_server1

No

 

Soa_server1

No

 

UCM_server1

No

 

WC_Collaboration

No

 

WC_Spaces

No

 

Wlcs_server1

No

 

Wlcs_sipstate1

No

 

Table 6-9 Managed Servers in the Oracle Fusion Customer Relationship Management Domain

Managed Server SSL? Application URLs

AdminServer

No

 

ContractManagementServer_1

Yes

https://hcmcrmppbr.host.example.com
/contractManagement/faces/ContractsDashboard

CRMAnalyticsServer_1

No

 

CRMCommonServer_1

Yes

https://hcmcrmppbr.host.example.com/crmCommon/faces
/CdmFoundationResourcesWorkArea

https://hcmcrmppbr.host.example.com/crmCommon/faces
/InteractionsDashBoard

Ess_server1

No

 

Odi_server1

No

 

Soa_server1

No

 

Table 6-10 Managed Servers in the Oracle Fusion Supply Chain Management Domain

Managed Server SSL? Application URLs

AdminServer

No

 

AdvancedPlanningServer_1

Yes

https://hcmscmppbr.host.example.com
/advancedPlanning/faces/ViewCollectedData

https://hcmscmppbr.host.example.com
/advancedPlanning/faces/MscCentralEssUi

https://hcmscmppbr.host.example.com
/advancedPlanning/faces/testAtpRule

https://hcmscmppbr.host.example.com
/advancedPlanning/faces
/testManageDataCollectionProcess

CostManagementServer_1

Yes

https://hcmscmppbr.host.example.com/costManagement
/faces/ItemCostProfileWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ManageCostElementWorkArea

https://hcmscmppbr.host.example.com/costManagement
/faces/ManageAnalysisGroupsWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ManageComponentGroupWorkArea

https://hcmscmppbr.host.example.com/costManagement
/faces/CostOrganizationsWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/DefaultCostProfileWorkArea

https://hcmscmppbr.host.example.com/costManagement
/faces/CostElementGroupWorkArea

https://hcmscmppbr.host.example.com/costManagement
/faces/RunControlWorkarea

https://hcmscmppbr.host.example.com/costManagement
/CostAccountingWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ManageCostElementWorkArea

https://hcmscmppbr.host.example.com/costManagement
/faces/CostProfilesWorkArea

https://hcmscmppbr.host.example.com/costManagement
/faces/ValuationStructureWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/CostProfilesWorkArea

https://hcmscmppbr.host.example.com/costManagement
/faces/ValuationStructureWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/CostProfilesWorkArea

https://hcmscmppbr.host.example.com/costManagement
/faces/ExpensePoolWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ValuationUnitsWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ExpensePoolWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ValuationUnitsWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ExpensePoolWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ReviewAccountingWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ReceiptAccountingWorkarea

https://hcmscmppbr.host.example.com/costManagement
/faces/ReviewDistributionsWorkarea

Ess_server1

No

 

GlobalizationServer_1

Yes

https://hcmscmppbr.host.example.com/globalization/faces
/IntrastatWorkarea

LogisticsServer_1

Yes

https://hcmscmppbr.host.example.com/logistics/faces
/RcvWorkArea

https://hcmscmppbr.host.example.com/logistics/faces
/ScmInvWorkArea

https://hcmscmppbr.host.example.comlogistics/faces
/WshDeliveriesWorkarea

Odi_server1

No

 

OrderOrchestrationServer_1

Yes

https://hcmscmppbr.host.example.com
/orderOrchestration/faces
/ProcessConstraintWorkarea

https://hcmscmppbr.host.example.com
/orderOrchestration/faces
/DooOrchManageProcessDashBoard

ProductManagementServer_1

Yes

https://hcmscmppbr.host.example.com
/productManagement/faces/ItemDashboard

SCMCommonServer_1

No

 

SCM_PDQ

No

 

Soa_server1

No

 

Table 6-11 Managed Servers in the Oracle Fusion Project Domain

Managed Server SSL? Application URLs

AdminServer

No

 

Ess_server1

No

 

ProjectsFinancialsServer_1

Yes

https://hcmprjppbr.host.example.com/projectsFinancials/faces/PRJProjectWorkarea https://hcmprjppbr.host.example.com/projectsFinancials/faces/PrjCostWorkArea https://hcmprjppbr.host.example.com/projectsFinancials/faces/CapitalWorkArea https://hcmprjppbr.host.example.com/projectsFinancials/faces/InvoiceWorkareaUI https://hcmprjppbr.host.example.com/projectsFinancials/faces/RevenueWorkArea https://hcmprjppbr.host.example.com/projectsFinancials/faces/ProjectPerformanceDashboard

Soa_server1

No

 

Table 6-12 Managed Servers in the Oracle Fusion Procurement Domain

Managed Server SSL? Application URLs

AdminServer

No

 

Ess_server1

No

 

ProcurementServer_1

Yes

https://hcmprcppbr.host.example.com/procurement/faces
/NegotiationWorkarea

https://hcmprcppbr.host.example.com/procurement/faces
/PrcPozSuppliersDashboard

Soa_server1

No

 

SupplierPortalServer_1

Yes

https://hcmprcppbr.host.example.com/supplierPortal/faces
/PrcPosSupplierPortalWorkarea


Table 6-13 Managed Servers in the Business Intelligence Domain

Managed Server SSL? Application URLs

AdminServer

No

 

Bi_server1

Yes

https://hcmbippbr.host.example.com/xmlpserver

https://hcmbippbr.host.example.com/analytics

https://hcmbippbr.host.example.com/workspace https://hcmbippbr.host.example.com/rtd


6.7.3.3 Enabling SSL between Oracle Fusion Applications Domains and IdM Components

As shown by the topology in Figure 6-6, the Authenticating WebGate handles all the authentication requests on Oracle HTTP Server (OHS) host (identified by authohs.example.com), which also protects Oracle Identity Manager in the IdM domain. You must SSL-enable this Auth OHS host, communication between the Apps OHS host and the IDM domain, and the Oracle Identity Manager managed server itself using the instructions in this section.

Figure 6-6 SSL to IdM Components

This figure shows the SSL flow in the IDM domain.

This section contains these topics:

6.7.3.3.1 Create the Identity Keystore

This section explains how to create a new Oracle Identity Manager identity keystore which is required to process incoming requests, and how to export a certificate from the new keystore.

The steps are as follows:

  1. Log in to the IdM node as the Oracle Identity Manager administrator.

  2. Create a new keystore with a self-signed certificate using the following keytool syntax:

    MW_HOME/jdk6/bin/keytool -genkey -keyalg RSA -alias selfsigned 
    
    -keystore /root_dir/Certs/oimkeystore.jks  -validity 360 -keysize 1024
    

    You will be prompted to specify the keystore password.

    Here is an example:

    [applmgr@myhost u01]$ /u01/oim/jdk6/bin/keytool -genkey -keyalg RSA -alias selfsigned -keystore /u01/Certs/oimkeystore.jks -validity 360 
    
    -keysize 1024
    
    Enter password: *******
    What is your first and last name?
      [Unknown]:  Mycorp PPBR
    What is the name of your organizational unit?
      [Unknown]:  PPBR
    What is the name of your organization?
      [Unknown]:  Mycorp
    What is the name of your City or Locality?
      [Unknown]:  Anytown
    What is the name of your State or Province?
      [Unknown]: CA
    What is the two-letter country code for this unit?
      [Unknown]: CA
    Is CN=Mycorp PPBR, OU=PPBR, O=Mycorp, L=Anytown, ST=CA, C=CA correct?
      [no]:  yes
     
    Enter key password for <selfsigned>
            (RETURN if same as keystore password):*******
    Re-enter new password: *******
    
  3. Export the self-signed certificate from the new keystore using the following keytool syntax:

    /root_dir/oim/jdk6/bin/keytool -export -v -rfc -alias selfsigned 
    
    -keystore /root_dir/Certs/oimkeystore.jks -file /root_dir/Certs/oimcert.crt –trustcacerts
    

    You will be prompted for the keystore password.

    For example:

    /u01/oim/jdk6/bin/keytool -export -v -rfc -alias selfsigned -keystore /u01/Certs/oimkeystore.jks 
    -file /u01/Certs/oimcert.crt –trustcacerts
     
    Enter password: ******* 
     
    Certificate stored in file </u01/Certs/oimcert.crt>
    
  4. Verify that the certificate is exported:

    [applmgr@OIM-node-a1 Certs]$ pwd
    /u01/Certs
    [applmgr@myhost Certs]$ ls -lrt
    -rw-r--r-- 1 applmgr dba 1348 Nov 10 23:54 oimkeystore.jks
    -rw-r--r-- 1 applmgr dba  833 Nov 10 23:56 oimcert.crt
    
  5. Make a note of this certificate as you will need it in the next section for Oracle HTTP Server configuration.

6.7.3.3.2 Configure SSL on the Apps OHS Server on the IdM Domain

Take these steps to enable secure communication between the Application Oracle HTTP Server (Apps OHS) and IDM components:

  1. Locate the Oracle Fusion Applications Oracle HTTP Server configuration file “APPLTOP/instance/CommonDomain_webtier/config/OHS/ohs1/FusionSSL.conf”, and copy it to “OHS-Instance/config/OHS/ohs1/”.

  2. Locate the IDM configuration file “OHS-Instance/config/OHS/ohs1/moduleconf/idm.conf” and copy it to “OHS-Instance/config/OHS/ohs1/moduleconf/idm.ssl.conf”.

    Note:

    Be sure to use the new file name in the target location. Use descriptive file names; for example, you can specify oam.ssl.conf to indicate that you are configuring SSL for Oracle Access Manager only.

  3. Add a VirtualHost block to the Oracle Identity Manager configuration file and include the FusionSSL.conf file in the block.

  4. Modify each Location block in the idm.ssl.conf (or similar) file as follows:

    WLProxySSL ON
    WLProxySSLPassThrough ON
    SecureProxy On
    WlSSLWallet "/root_dir/ohsauth/ohsauth_inst/config/OHS/ohs1/keystores/default"
    
  5. Modify "WebLogicPort nnnn" to point to Oracle Identity Manager's SSL managed server port (several occurrences).

  6. After Steps 3 through 5, the configuration file appears like this:

    ##   <start> Entries added as part of SSL configuration ##
    Listen authohs.company.com:4446
     
    <VirtualHost authohs.company.com:4446>
    ServerName https://host.example.com
    include "/root_dir/idm/ohsauth/ohsauth_inst1/config/OHS/ohs1/FusionSSL.conf"
     
    ##   <End> Entries added as part of SSL configuration ##
     
    # OAM Related Entries
      # Admin Server and EM 
       <Location /console>
          SetHandler weblogic-handler
          WebLogicHost host.example.com
          WeblogicPort nnnn <--- Set to Weblogic Admin SSL Port
          WLProxySSL ON
          WLProxySSLPassThrough ON
          WLCookieName    oimjsessionid
          WLProxySSL ON
          WLProxySSLPassThrough ON
          SecureProxy On
          WlSSLWallet "/root_dir/idm/ohsauth/ohsauth_      inst1/config/OHS/ohs1/keystores/default"
          WLLogFile "${ORACLE_INSTANCE}/diagnostics/logs/mod_wl/oam_component.log"
     
       </Location>
    

    Only the first of several Location blocks is shown in this file fragment. Additional Location blocks, for such components as oamconsole, Oracle Identity Manager admin consoles, and so on, must be similarly configured.

    Note that root_dir/idm/ohsauth/ohsauth_inst1/config/OHS/ohs1/keystores/default is the SSL wallet used by OHS (mod_wl_ohs) containing the trusted certificate for Oracle Identity Manager server.

  7. Create a new CA certificate for signing OHS wallets (Apps OHS and Auth OHS). The steps are as follows (the order of steps is critical when importing the root CA certificate):

    1. Create an Oracle Wallet with certificates. For details, see the "Common Wallet Operations" section in the Oracle Fusion Middleware Administrator's Guide.

    2. If you intend to use a Certificate Authority (CA) to sign Auth OHS and Apps OHS certificates, you must obtain the signed certificates from the CA. Here is an example of an Oracle Wallet, certificates and related files for a Microsoft CA:

      [applmgr@myhost Certs]$ pwd
      /root_dir/fa/Certs
      [applmgr@myhost Certs]$ ls -ltr
      total 27
      -rw------- 1 applmgr dba 4976 Jan 12 14:51 ewallet.p12
      -rw------- 1 applmgr dba 5053 Jan 12 14:51 cwallet.sso
      -rw------- 1 applmgr dba 1022 Jan 12 14:51 ohsserver01req.csr --> certificate request
      -rw-r--r-- 1 applmgr dba 2392 Jan 24 15:12 signingCA01.cer  --> cert1 obtained from authority:Microsoft CA
      -rw-r--r-- 1 applmgr dba 1834 Jan 24 15:12 rootca1.cer    --> root (trusted) cert obtained from :Microsoft CA
      -rw-r--r-- 1 applmgr dba 2202 Jan 24 15:12 ohsServer.cer --> cert2 obtained from authority:Microsoft CA
      

      Create a Certificate Signing Request (CSR) based on the OHS Oracle Wallet. The CSR is a wildcard certificate as shown in this example:

      [applmgr@myhost Certs]$ /root_dir/fa/APPLTOP/webtier_mwhome
      
      /oracle_common/bin/orapki wallet display -wallet .
      Oracle PKI Tool : Version 11.1.1.5.0
      Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.
       
      Requested Certificates:
      Subject:        CN=*.company.com,<your_organization>,O=<your_company> ,L=<your city>,ST=<your State>,C=US
      User Certificates:
      Trusted Certificates:
      Subject:        OU=Class 1 Public Primary Certification Authority,O=VeriSign, Inc.,C=US
      Subject:        OU=Class 3 Public Primary Certification Authority,O=VeriSign, Inc.,C=US
      Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign, Inc.,C=US
      Subject:        CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions, Inc.,O=GTE Corporation,C=US
      
    3. Import the root CA certificate(s) into the wallet using orapki. For a root certificate file rootca1.cer, for example, the syntax is:

      /root_dir/fa/APPLTOP/webtier_mwhome/oracle_common/bin/orapki 
      
      wallet add -wallet  
      /root_dir/fa/Certs/   
      
      /root_dir/fa/Certs/rootca1.cer  -trusted_cert 
      
    4. Import the CA's signing certificate into the wallet using orapki. For a signing certificate file signingca01.cer, for example, the syntax is:

      /root_dir/fa/APPLTOP/webtier_mwhome/oracle_common/bin/orapki 
      wallet add -wallet  
      /root_dir/fa/Certs/ 
      /root_dir/fa/Certs/signingCA01.cer  -trusted_cert 
      
    5. Import the OHS server certificate. For a certificate file ohsServer.cer, for example, the syntax is:

      /root_dir/fa/APPLTOP/webtier_mwhome/oracle_common/bin/orapki 
      wallet add -wallet  
      /root_dir/fa/Certs/ 
      /root_dir/fa/Certs/ohsServer.cer  -user_cert  
      
    6. Check the wallet using orapki:

      /root_dir/fa/APPLTOP/webtier_mwhome/oracle_common/bin/orapki 
      
      wallet display -wallet .
              Oracle PKI Tool : Version 11.1.1.5.0
              Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.
       
              Requested Certificates:
              User Certificates:
      Subject:        CN=*.company.com,OU=<your_organization>,O=<your_compnay> ,L=<your_city>,ST=<your_state>,C=US
              Trusted Certificates:
              Subject:        CN=rootca1 <--------- The root CA as a trusted cert
              Subject:        OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
      Subject:        CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US
              Subject:        CN=signingCA,DC=company,DC=com <---------- The signing CA as a trusted cert
              Subject:        OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
              Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
      
    7. Check the listing of wallet files:

      [applmgr@myhost Certs]$ pwd
      /root_dir/fa/Certs/
      [applmgr@myhost Certs]$ ls -ltr
      total 60
      - -rw-r--r-- 1 applmgr dba 2392 Jan 24 15:12 myca01.cer
      -rw-r--r-- 1 applmgr dba 1834 Jan 24 15:12 rootca1.cer
      -rw-r--r-- 1 applmgr dba 2202 Jan 24 15:12 ohsServer.cer
      -rw------- 1 applmgr dba 9816 Jan 24 23:15 ewallet.p12    <-- newly updated
      -rw------- 1 applmgr dba 9893 Jan 24 23:50 cwallet.sso  <-- newly updated
      

      As shown here, both the required wallet files (ewallet.p12 and cwallet.sso) should have updated date stamps; they will be used for Apps OHS and Auth OHS.

  8. Restart the Oracle HTTP Server:

    [applmgr@myhost bin]$ pwd
    /root_dir/fa/APPLTOP/instance/CommonDomain_webtier/bin
    [applmgr@myhost bin]$ ./opmnctl stopall
    opmnctl stopall: stopping opmn and all managed processes...
    [applmgr@myhost bin]$ ./opmnctl startall
    opmnctl startall: starting opmn and all managed processes...
    
  9. Verify that a virtual server is running on the SSL port you configured:

    OHS_instance/bin/opmnctl status –l
    Processes in Instance: CommonDomain_webtier
    --------------+---------------+---------+----------+-----------+------
    ias-component | process-type  |     pid | status   |    uptime | ports
    --------------+---------------+---------+----------+-----------+------
    ohs1          | OHS           |   20088 | Alive    |   0:02:59 | http:10621,https:10622,http:10615,https:10616,http:10605,https:10606,http:10617,https:10618,http:10623,https:10624,https:7046,https:10604,http:10603
    
  10. Repeat Steps 1 through 10 for any additional Apps OHS servers.

6.7.3.3.3 Configure SSL on the Authentication OHS Server

Take these steps to enable SSL on the Authentication Oracle HTTP Server (Auth OHS):

  1. Replace the existing wallet files.

    1. Navigate to the wallet directory located at /root_dir/idm/ohsauth/ohsauth_inst1/config/OHS/ohs1/keystores/default.

    2. Move the existing cwallet.sso and ewallet.p12 files to a backup location.

    3. Copy over the new cwallet.sso and ewallet.p12 files. For example:

      [applmgr@myhost default]$ scp -p 
      
      applmgr@myhost:/root_dir/fa/Certs/cwallet.sso 
      
      /root_dir/idm/ohsauth/ohsauth_inst1/config/OHS/ohs1/keystores/default
      applmgr@myhost's password:
      cwallet.sso                                                                                             100% 9893     9.7KB/s   00:00
      [applmgr@myhost default]$ scp -p 
      
      applmgr@myhost:/root_dir/fa/Certs/ewallet.p12 
      
      /root_dir/idm/ohsauth/ohsauth_inst1/config/OHS/ohs1/keystores/default
      applmgr@myhost's password:
      ewallet.p12                                                                                              100% 9816     9.6KB/s   00:00
      [applmgr@myhost default]$
      
  2. Import the certificate for the Oracle Identity Manager's managed server as a trusted certificate, oimcert.crt, into the default Auth OHS wallet:

    1. Confirm that that /root_dir/idm/Certs/oimcert.crt is also accessible from the IDM node.

    2. List the contents of the cwallet.sso file for Auth OHS using orapki:

      [applmgr@myhost default]$ /root_dir/idm/oim/oracle_common/bin/orapki 
      
      wallet display -wallet .
      
    3. Add the Oracle Identity Manager certificate, oimcert.crt, to the Auth OHS SSL wallet:

      [applmgr@myhost default]$ /root_dir/idm/oim/oracle_common/bin/orapki 
      
      wallet add -wallet 
      
      /root_dir/idm/ohsauth/ohsauth_inst1/config/OHS/ohs1/keystores/default  -cert /root_dir/idm/Certs/oimcert.crt -trusted_cert
      

      A listing of the directory shows the updated files:

      [applmgr@myhost default]$ ls -ltr
      total 23
      drwxr-xr-x 2 applmgr dba     3 Jan 25 12:28 backup
      -rw------- 1 applmgr dba 10557 Jan 25 14:39 cwallet.sso
      -rw------- 1 applmgr dba 10480 Jan 25 14:39 ewallet.p12
      
    4. List the wallet contents using orapki to confirm that the Oracle Identity Manager certificate was imported:

      [applmgr@myhost default]$ /root_dir/idm/oim/oracle_common/bin/orapki 
      
      wallet display -wallet .
      Oracle PKI Tool : Version 11.1.1.5.0
      Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.
       
      Requested Certificates:
      User Certificates:
      Subject:        CN=*.company.com,OU=ABCD,O=Company,L=Anytown,ST=Anystate,C=US
      Trusted Certificates:
      Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
      Subject:        CN=OIM server host,OU=your organization,O=your company,L=your city,ST=your state,C=US
      Subject:        CN=rootca1
      ...
      
  3. Restart the Oracle HTTP Server:

    [applmgr@myhost bin]$ ./opmnctl stopall
    opmnctl stopall: stopping opmn and all managed processes...
    [applmgr@myhost bin]$ ./opmnctl startall
    opmnctl startall: starting opmn and all managed processes...
    
  4. Verify that a virtual server is running on the SSL port you configured:

    OHS_instance/bin/opmnctl status –l
    Processes in Instance: ohsauth_inst1
    --------------+---------------+---------+----------+-----------+------
    ias-component | process-type  |     pid | status   |    uptime | ports
    --------------+---------------+---------+----------+-----------+------
    ohs1          | OHS           |   4650  | Alive    |   0:00:29 | https:4444,https:7779,https:4446,http:7777
    
  5. Configure the load balancer to point to the new SSL virtual host created on the authenticating WebGate.

6.7.3.3.4 Configure SSL on the Managed Server for Oracle Identity Manager

Take these steps to configure a trust store (used for outgoing requests) and enable SSL on the managed server hosting Oracle Identity Manager:

  1. Log in to the Apps OHS node.

  2. Export the certificates in the Oracle Wallet used at this node using orapki. This example exports the root certificate:

    [applmgr@myhost Certs]$ /root_dir/fa/APPLTOP/webtier_mwhome/oracle_common/bin/orapki 
    wallet export -wallet . 
    -dn "CN=*.company.com,OU=FAHR,O=Company,L=Anytown,ST=Anystate,C=US" 
    -cert /root_dir/fa/Certs/rootca1.cer 
    

    You should have two certificates in the /root_dir/fa/Certs location: the CA's root certificate and its signing certificate.

  3. Copy these certificates from the Apps OHS node to the node where the managed server for Oracle Identity Manager resides.

  4. Set the environment as shown in this example:

    [applmgr@myhost ~]$ export ORACLE_HOME=/root_dir/idm/oim/oim_home
    [applmgr@myhost ~]$ export OIM_ORACLE_HOME=/=/root_dir/idm/oim/oim_home
    [applmgr@myhost ~]$ export SOA_HOME=/root_dir/idm/oim/soa_home
    [applmgr@myhost ~]$ export DOMAIN_HOME=/root_dir/idm/oim
    
    /user_projects/domains/idm_domain
    
  5. Create the trust store with the OHS server's CA chain using the keytool command. For example:

    [applmgr@myhost Certs]$ /root_dir/idm/oim/jrockit-jdk1.6.0_24/bin/keytool 
    -import -v 
    -alias authohs.host.example.com 
    -keystore /root_dir/idm/Certs/trustkeystore.jks  
    -file //root_dir/idm/Certs/rootca1.cer –trustcacerts
     
    [applmgr@myhost Certs]$ /root_dir/idm/oim/jrockit-jdk1.6.0_24/bin/keytool 
    -import -v 
    -alias authohs.host.example.com 
    -keystore /root_dir/idm/Certs/trustkeystore.jks  
    -file //root_dir/idm/Certs/signingCA1.cer -trustcacerts
    
  6. Confirm the new keystore is created:

    [applmgr@myhost Certs]$ pwd
    /root_dir/idm/Certs
    [applmgr@myhost Certs]$ ls -ltr
    total 9
    -rw-r--r-- 1 applmgr dba 1349 Jan 24 13:39 oimkeystore.jks
    -rw-r--r-- 1 applmgr dba  833 Jan 24 13:49 oimcert.crt
    -rw------- 1 applmgr dba 2161 Jan 25 18:10 rootca1.cer
     rw------- 1 applmgr dba 2161 Jan 25 18:10  signingCA1.cer
    -rw-r--r-- 1 applmgr dba 1636 Jan 25 19:12 trustkeystore.jks
    
  7. Log in to the WebLogic domain console as the “oim_admin” user.

  8. Navigate to Environment, then Servers, then oim_server1. Click the Configuration tab, then General.

  9. Check the “SSL Listen Port Enabled” box and provide an SSL port, as in this example:

    This figure shows how to set SSL on a managed server.
  10. Scroll down to the Advanced portion of the page. Check the "WebLogic Plug-In Enabled" box:

    This figure shows a proxy for managed servers.
  11. Navigate to Environment, then Servers, then oim_server1, then Configuration, then Keystores. Here you will change the keystore type from "Demo Identity Demo Trust" to "Custom Identity Custom Trust".

  12. Provide the keystore details as in this example:

    For identity:

    Custom Identity Keystore: /root_dir/idm/Certs/oimkeystore.jks
    Custom Identity Keystore Type: jks
    

    For trust:

    Custom Trust Keystore: /root_dir/idm/Certs/trustkeystore.jks
    Custom Trust Keystore Type: jks
    
  13. Navigate to Environment, then Servers, then oim_server1, then Configuration, then SSL.

  14. Provide the alias for the private key:

    Private Key Alias: selfsigned
    
  15. Save the changes.

  16. Restart Oracle WebLogic Server if prompted to do so by the server.

6.7.3.3.5 Configure SSL for Oracle Access Manager

This section provides background for configuring 10g WebGates and the Oracle Access Manager server for secure communication.

You must provision a WebGate agent to use Oracle Access Manager 11g authentication and authorization services. After installation and registration, Oracle Access Manager 10g WebGates directly communicate with Oracle Access Manager 11g servers through a JAVA-based Oracle Access Manager proxy.

In Oracle Access Manager 11g, credential collection occurs using the HTTP(S) channel; authorization occurs over the NetPoint Access Protocol (NAP) channel, which is also referred to as the Oracle Access Manager Protocol (OAP) channel.

Securing communication between Oracle Access Manager servers and WebGate agents means defining the transport security mode for the NAP channel. There are two options for SSL communication between Oracle Access Manager 11g and Webgate 10g: Simple Mode and Cert Mode.

Oracle recommends enabling the secure sockets layer (SSL) for communication across the HTTP(S) channel to transport credentials and to exchange security tokens. Both functions require signing or encryption with certificates. Oracle Access Manager 11g provides a central facility to manage certificates used across all Oracle Access Manager components, including WebGates.

For WebGate configuration details, see the "Provisioning a 10g WebGate with OAM 11g" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

To configure SSL for the NAP channel to Oracle Access Manager 11g, see the "Securing Communication with OAM 11g" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager.

6.7.3.4 Known Issues

This section lists known issues with the SSL configurations described in this document. This section contains these topics:

6.7.3.4.1 Oracle Access Manager Operation Error

Problem

In Google Chrome, attempt to access the Benefits Server URL: https://hcmppbr.host.example.com/hcmBenefits/faces/HcmBenefitsProcessesAdministerBenefitsWorkArea displays SSL Warning. Upon clicking on “Continue Any Way”, returns message:

Oracle Access Manager Operation Error
-------------
The credentials (Resource=/hcmBenefits/faces/HcmBenefitsProcessesAdministerBenefitsWorkArea RequesterIP=141.147.0.3 HostTarget=https://hcmppbr.domain.com Operation=GET) used in the login do not correspond to a user profile in the Identity System.

This issue is likely due to an authentication problem such as invalid credentials.

Solution

Contact your website administrator to remedy this problem.

6.7.3.4.2 SSL connection Error

Problem

Attempt to connect to Access Server URL: https://hcmssoppbr.domain.com/ returns error:

SSL connection error
Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.
Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

This issue is due to a configuration mismatch between client and server configurations.

Solution

Check for configuration issues such as mismatched authentication modes between client and server.

6.7.3.4.3 Issue 3: Webpage Not Available Error

Problem

Attempts to log in to URL:

https://hcmfinppbr.domain.com/financialCommon/faces/LegalEntityDashboardresult in this error message:

This webpage is not available
Google Chrome's connection attempt to hcmfinppbr.host.example.com was rejected. The website may be down, or your network may not be properly configured.
 
Issue: Direct URL to Benefits server: https://myhost.example.com:10620/hcmBenefits/faces/HcmBenefitsProcessesAdministerBenefitsWorkArea

Report error:

[2011-10-11T15:44:20.1733-04:00] [OHS] [INCIDENT_ERROR:32] [OHS-2171] [core.c] [host_id: myhost] [host_addr: 10.200.12.63] [pid: 31977] [tid: 1425013056] [user: applmgr] [VirtualHost: hcmsscppbr.domain.com:0]  NZ Library Error: SSL protocol error [Hint: the client probably speaks HTTPS over HTTP protocol]

From the Oracle HTTP Server error log in
/root_dir/ohsauth/ohsauth_inst/diagnostics/logs/OHS/ohs1/ohs1.log:

[2011-10-11T16:08:34.3706-04:00] [OHS] [INCIDENT_ERROR:32] [OHS-2171] [core.c] [host_id: myhost] [host_addr: 10.200.12.61] [pid: 28467] [tid: 1349544256] [user: applmgr] [VirtualHost: hcmcrp1sso.domain.com:0]  NZ Library Error: SSL fatal alert

This problem occurs when the browser gets two SSL certificates with the same serial key. Mozilla Firefox shows this message:

Secure Connection Failed
...
...
Your certificate contains the same serial number as another certificate issued by the certificate authority.
...

Solution

Take these steps to manually delete and recreate the Oracle Identity Manager trust key store with a new certificate (substitute actual paths for the samples shown here):

/root_dir/oim/jdk6/bin/keytool -list -keystore /root_dir/Certs/oimkeystore.jks
/root_dir/oim/jdk6/bin/keytool -list -keystore /root_dir/Certs/oimkeystore.jks -v
/root_dir/oim/jdk6/bin/keytool -list -keystore /root_dir/Certs/trustkeystore.jks -v
 
/root_dir/oim/jdk6/bin/keytool -delete -keystore trustkeystore.jks -alias authohsoim.example.com
/root_dir/oim/jdk6/bin/keytool -delete -keystore trustkeystore.jks -alias authohsoim2.example.com
/root_dir/oim/jdk6/bin/keytool -import -keystore trustkeystore.jks -alias authohsoim.example.com -file <location of cert.txt> -rfc

6.7.4 Checklist of SSL Connections for IdM Components

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 6-14 shows the connections for Oracle Internet Directory:

Table 6-14 Connections for Oracle Internet Directory

Server Component Inbound Clients to Server Outbound Clients from Server

Oracle Internet Directory - See the "Enabling SSL on Oracle Internet Directory Listeners" section in the Oracle Fusion Middleware Administrator's Guide.

Oracle Identity Manager - See the "Enabling SSL for LDAP Synchronization" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

Database - See the "Enabling Outbound SSL from Oracle Internet Directory to Oracle Database" section in the Oracle Fusion Middleware Administrator's Guide

 

Oracle Access Manager - See the "Outbound SSL from LDAP Authenticator to LDAP" section in the Oracle Fusion Middleware Administrator's Guide.

 
 

Oracle Directory Integration Platform - See the "Configuring Oracle Directory Integration Platform for SSL Mode 2 Server-Only Authentication" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Directory Integration Platform.

 
 

Oracle Directory Services Manager - See the "Logging Into the Directory Server from Oracle Directory Services Manager Using SSL" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

 
 

Oracle Enterprise Manager - See the "Oracle Enterprise Manager Fusion Middleware Control" section in the Oracle Fusion Middleware Administrator's Guide.

 

Table 6-15 shows the connections for Oracle Virtual Directory:

Table 6-15 Connections for Oracle Virtual Directory

Server Component Inbound Clients to Server Outbound Clients from Server

Oracle Virtual Directory - See the "Enabling SSL on Oracle Virtual Directory Listeners" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.

Oracle Identity Manager - See the "Enabling SSL for LDAP Synchronization" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

LDAP - See the "Configuring LDAP Adapters" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Virtual Directory.


Table 6-16 shows the connections for Oracle Access Manager:

Table 6-16 Connections for Oracle Access Manager

Server Component Inbound Clients to Server Outbound Clients from Server

Oracle Access Manager - Section 6.7.3.3.5, "Configure SSL for Oracle Access Manager"

WebGate - See the "Configuring Cert Mode Communication for OAM 11g" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.

Oracle Internet Directory - See the "Enable Inbound SSL on an Oracle Internet Directory Listener Using Fusion Middleware Control" section in the Oracle Fusion Middleware Administrator's Guide.

 

mod_wl_ohs - See the "Enable SSL for Outbound Requests from Oracle HTTP Server" section in the Oracle Fusion Middleware Administrator's Guide.

Oracle Virtual Directory - See the "Enable SSL for Oracle Virtual Directory Using Fusion Middleware Control" section in the Oracle Fusion Middleware Administrator's Guide.


Table 6-17 shows the connections for Oracle Identity Manager:

Table 6-17 Connections for Oracle Identity Manager

Server Component Inbound Clients to Server Outbound Clients from Server

Oracle Identity Manager - See Section 6.7.3.3.4, "Configure SSL on the Managed Server for Oracle Identity Manager".

Also see the "Enabling SSL for Oracle Identity Manager By Using Default Setting" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

OHS through mod_wl_ohs - See the "Enable SSL for Outbound Requests from Oracle HTTP Server" section in the Oracle Fusion Middleware Administrator's Guide.

SOA managed server - See the "Enabling SSL for Oracle Identity Manager and SOA Servers" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

 

SOA through SPML - See the "Changing OimFrontEndURL to Use SSL Port" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager.

 

Table 6-18 shows the connections for Oracle Identity Federation:

Table 6-18 Connections for Oracle Identity Federation

Server Component Inbound Clients to Server Outbound Clients from Server

Oracle Identity Federation - See the "Configuring Oracle Identity Federation as an SSL Server" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.

Oracle WebLogic Server - See the "Configuring Oracle WebLogic Server" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.

LDAP Server - See the "Connecting to an LDAP Server over SSL" section in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Federation.


Table 6-19 shows the connections for Oracle HTTP Server (OHS):

6.7.5 Additional SSL Configuration

Besides the connections that are SSL-enabled during provisioning, there are additional connections in the Oracle Fusion Applications environment that can be SSL-enabled. For example, you can secure traffic to Oracle Database.

This section contains the following topics:

6.7.5.1 SSL-enable Oracle Business Intelligence

You can configure the components of Oracle Business Intelligence to communicate over SSL.

For configuration details, see "SSL Configuration in Oracle Business Intelligence" chapter in the Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition.

6.7.5.2 SSL-enable Oracle WebCenter Content

You can configure SSL for Oracle WebCenter Content applications running in a production or development environment.

For configuration details, see "Configuring SSL for Oracle WebCenter Content Applications" section in the Oracle WebCenter Content Installation Guide.

6.7.5.3 SSL to External Web Services

For information about securing Oracle Fusion Web Services, see the following:

  • "Locking Down Web Services: Points to Consider" section in the Oracle Fusion Applications Security Hardening Guide

  • "Hardening Web Services" section in the Oracle Fusion Applications Security Hardening Guide

6.7.6 Enabling Secure Sockets Layer on ECSF

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

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.

For information about how to generate the certificate, see Oracle Fusion Middleware Securing Oracle WebLogic Server.

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   Enabling 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. For more information, see the "Configuring SSL" chapter in Oracle Fusion Middleware Securing Oracle WebLogic Server.

To enable SSL on Oracle WebLogic Server:

  1. Configure SSL.

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

    • Make sure that the Allow Unencrypted Null Cipher checkbox is deselected (default).

  2. Configure the listen ports to enable the SSL listen port (check the SSL Listen Port Enabled checkbox).

    Note:

    The SSL Listen Port is usually set as 7002. You can use this port number 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.) For more information about adding the certificate to the trust store, see the Oracle Secure Enterprise Search Administrator's Guide.

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   Enabling SSL for Oracle SES Services

You must also enable SSL 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, you must extract the certificate from Oracle SES and add it 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, you must 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, you need to change http://wlsserver.com:7101/approot/searchfeedservlet to https://wlsserver.com:7002/approot/searchfeedservlet.

You must also 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, you need to change http://sesserver.com:7777/search/api/admin/AdminService to https://sesserver.com:7777/search/api/admin/AdminService. You do not need to change the port number because the instructions will switch the current port to be an SSL port instead of adding a separate SSL port.

You can use Fusion Applications Control to configure the engine instance parameters. For information, see Section 9.5.3.2.

6.8 Managing Wallets, Keystores, Credentials, and Certificates

Enabling SSL requires the use of a number of security artifacts such as certificates and keys, as well as the containers (keystores) where they are stored. Oracle Fusion Middleware provides a number of tools to create and maintain these artifacts.

This section contains the following topics:

6.8.1 Wallets and Keystores

Oracle Fusion Middleware provides two types of repositories (keystores) for keys and certificates:

For more information about wallets and keystores, see Section 6.7.2.

6.8.1.1 JKS Keystore and Truststore

A JKS keystore is the default JDK implementation of Java keystores. In 11g Release 1 (11.1.1), all Java components and Java EE applications use the JKS-based keystore and truststore.

While creating a keystore, you can pre-populate it with a keypair wrapped in a self-signed certificate. Such a keystore is typically used in development and testing phases.

You can also generate a certificate signing request for a keypair and request a signed certificate back from a Certificate Authority (CA). Once the CA sends the certificate back, it is imported into the keystore. The keystore now contains a trusted certificate since it comes from a trusted third-party. Such a keystore is typically used in production.

For more information about creating and managing keystores, see the"JKS Keystore and Truststore" section in the Oracle Fusion Middleware Administrator's Guide.

6.8.1.2 Oracle Wallet

An Oracle wallet is a type of keystore or container that stores your credentials, such as certificates, trusted certificates, certificate requests, and private keys. You can store Oracle wallets on the file system or in LDAP directories such as Oracle Internet Directory.

In the Oracle Fusion Applications environment, Oracle wallets are used by Oracle HTTP Server, LDAP clients, and SQL*net clients.

When creating a wallet, you can pre-populate it with a self-signed certificate. Such a wallet is called a test wallet and is typically used in development and testing phases.

You can also create a certificate request and request a signed certificate back from a Certificate Authority (CA). Once the CA sends the certificate back it is imported into the wallet. Such a wallet is called a third-party wallet.

For more information about creating and managing wallets, see the "Oracle Wallet" section in the Oracle Fusion Middleware Administrator's Guide.

6.8.1.3 Keystore Types Used by Products

Table 6-20 shows the type of keystore, either Oracle wallet or JKS keystore, used by various products:

Table 6-20 Keystore Types for Products

Product Type of Keystore Used

Oracle HTTP Server

Oracle Wallet

Oracle Internet Directory

Oracle Wallet

Oracle Virtual Directory

JKS-based Keystore

Oracle WebLogic Server

JKS-based Keystore

Oracle SES Services

JKS-based Keystore

Oracle ECM

JKS-based Keystore

Oracle Business Intelligence

JKS-based Keystore


See Section 6.8.2 for a survey of common tools used to create and manage keystores. See the SSL references in Section 6.7 for the keystore management tools used by individual products.

6.8.2 Management Tools

Oracle Fusion Middleware provides these tools for keystore operations:

  • WLST, a command-line interface for JKS keystores and wallets

  • orapki, a command-line tool for wallets

  • Fusion Middleware Control, a graphical user interface

  • Oracle Wallet Manager, a stand-alone GUI tool for wallets, recommended for managing PKCS#11 wallets

  • the keytool utility

For more information about these management tools, see the "Keystore Management Tools" section in the Oracle Fusion Middleware Administrator's Guide.

6.8.3 Managing Wallets and their Contents

When working with certificates and the wallets in which they are stored, you must be aware of the operations that can be performed on these objects in the course of routine administration:

6.8.3.1 Wallet Lifecycle

Typical life cycle events for an Oracle wallet are as follows:

  • The wallet is created. Wallets can be created directly, or by importing a wallet file from the file system.

  • The list of available wallets is viewed and specific wallets are selected for update.

  • Wallets are updated or deleted. Update operations for password-protected wallets require that you enter the wallet password.

  • The wallet password can be changed for password-protected wallets.

  • The wallet can be deleted.

  • Wallets can be exported and imported.

6.8.3.2 Wallet Operations

Typical operations for the Oracle Wallet include the following:

  • Creating wallets, including auto-login, self-signed, and password-protected wallets

  • Changing a self-signed wallet to a third-party wallet

    Note:

    Third-party wallets contains certificates signed by a trusted Certificate Authority (CA).

  • Exporting and importing wallets to and from the file system

  • Deleting a wallet.

6.8.3.3 Certificate Lifecycle

The following provides a summary of the steps in a certificate's lifecycle:

  1. Create an empty wallet (that is, a wallet that does not contain a certificate request).

  2. Add a certificate request to the wallet.

  3. Export the certificate request.

  4. Use the certificate request to obtain the corresponding certificate.

  5. Import trusted certificates.

  6. Import the certificate.

6.8.3.4 Certificate Operations

Common certificate operations include:

  • Creating a certificate request

  • Exporting a Certificate, Certificate Request, or a Trusted Certificate

  • Importing a Certificate or a Trusted Certificate

  • Deleting a Certificate Request, a Certificate, or a Trusted Certificate

  • Converting a Self-Signed Certificate into a Third-Party Certificate.

    Note:

    Third-party certificates are signed by a trusted Certificate Authority (CA).

6.8.4 Managing Keystores and their Contents

When working with JKS certificates and the keystores in which they are stored, you must be aware of the operations that can be performed on these objects in the course of routine administration:

6.8.4.1 Keystore Lifecycle

Typical life cycle events for a JKS keystore are as follows:

  • The keystore is created. Keystores can be created directly, or by importing a keystore file from the file system.

  • The list of available keystores are viewed and specific keystores selected for update.

  • Keystores are updated or deleted. Update operations require that the keystore password be entered.

  • The keystore password can be changed.

  • The keystore can be deleted.

  • Keystores can be exported and imported.

6.8.4.2 Keystore Operations

Typical keystore operations include the following:

  • Creating or updating a keystore.

  • Exporting and importing keystores.

  • Deleting a keystore.

  • Changing the keystore password.

6.8.4.3 Certificate Lifecycle

Typical life cycle events for a certificate residing in a keystore are as follows:

  • A self-signed certificate is automatically created for the keypair.

  • A certificate signing request (CSR) is generated, and can then be exported to a file.

  • Certificates are imported into the keystore. You can import both user certificates and trusted certificates (also known as CA certificates) in this way.

  • Certificates or trusted certificates are exported from the keystore out to a file.

  • Certificates or trusted certificates are deleted from the keystore.

6.8.4.4 Certificate Operations

Common operations on JKS certificates include the following:

  • Generating a new key (that is, a new self-signed certificate) for a keystore.

  • Generating a certificate signing request.

  • Importing/exporting a certificate or trusted certificate into/from a keystore.

  • Deleting a certificate or trusted certificate from a keystore.

6.8.5 Managing Credentials

In Oracle Fusion Applications, user and role information such as passwords are maintained in a domain credential store. The tools you use to update existing passwords (for routine administration or regulatory compliance), depend on the type of credentials:

This section contains the following topics:

6.8.5.1 Changing App ID Passwords

When invoking Web services, Oracle Fusion Applications must rely on a type of credential known as the Application ID or App ID. Each application has its own App ID which is initially provisioned for the application.

For information about resetting App ID passwords (a task typically done during scheduled downtime), see the Application Identity Password Reset And Password Policy Management section in the Oracle Fusion Applications Security Guide.

6.8.5.2 Changing the Oracle Fusion Middleware Administrative User Password

During the Oracle Fusion Applications installation, you must provide a password for the Oracle Fusion Middleware administration user. By default, this administrator takes the Super User value you specified on the Identity Management page when creating the provisioning plan. The password is the one specified when adding the user to the identity store.

Then, you can use this account to log in to Fusion Applications Control and the Oracle WebLogic Server Administration Console for the first time. You can create additional administrative accounts using the WLST command line or the Oracle WebLogic Server Administration Console.

You can change the password of the administrative user using the Oracle WebLogic Server Administration Console or the WLST command line.

This section contains the following topics:

If your configuration uses FAAdmin as the Oracle Fusion Middleware administrative user, you can also use the password-reset-tool script to change the password. See Section 6.8.5.2.

6.8.5.2.1 Changing the Oracle Fusion Middleware Administrative User Password Using the Command Line

To change the Oracle Fusion Middleware administrative user password or other user passwords using the command line, you invoke the UserPasswordEditorMBean.changeUserPassword method, which is extended by the security realm's AuthenticationProvider MBean.

For more information, see the changeUserPassword method in the Oracle Fusion Middleware Oracle WebLogic Server MBean Reference.

6.8.5.2.2 Changing the Oracle Fusion Middleware Administrative User Password Using the Administration Console

To change the password of the Oracle Fusion Middleware administrative user using the Oracle WebLogic Server Administration Console:

  1. Navigate to the Oracle WebLogic Server Administration Console. (For example, from the home page of the domain in Fusion Applications Control, select To configure and managed this WebLogic Domain, use the Oracle WebLogic Server Administration Console.)

  2. From the target navigation pane, select Security Realms.

    The Summary of Security Realms page is displayed.

  3. Select a realm, such as myrealm.

    The Settings for the realm page is displayed.

  4. Select the Users and Groups tab, then the Users tab. Select the user.

    The Settings for user page is displayed.

  5. Select the Passwords tab.

  6. Enter the new password, then enter it again to confirm it.

  7. Click Save.

6.8.5.3 Changing Oracle Identity Management Passwords

In production environments, certain passwords are required to be reset periodically. For UNIX environments, the password-reset-tool utility provides a way to reset passwords of bind users used by Oracle Fusion applications and stored in Oracle Fusion Applications domains. Specifically, this tool can be used to reset passwords of the following users: FAAdmin, IDROUser, IDRWUser, PolicyRWUser, and oamadminuser. For a configuration that does not use FAAdmin as the Oracle Fusion Middleware administrative user, use one of the methods described in Section 6.8.5.2.

Notes:

Typically, a system outage is scheduled and expected while the password-reset-tool utility is running.

Make a note of the new passwords you submit to the tool (those passwords cannot be retrieved in plain text and may need to be provided later on).

6.8.5.3.1 Syntax and Example of Use

To use the password-reset-tool utility:

  1. Prepare the Oracle Fusion Applications environment for the password-reset-tool utility by ensuring the following prerequisites are fulfilled:

    • Java is installed on the system and inserted in the path.

    • ANT is installed on the system and inserted in the path.

    • Ensure the provisioning plan is available at APPLICATIONS_BASE/provisioning/plan/provisioning.plan.

    • You know the password for cn=orcladmin (the administrative user for Oracle Identity Management).

  2. Ensure the Administration Servers for all domains are up. See Section 4.4.4.

  3. At an operating system command prompt for the CommonDomain domain, navigate to the location of the password-reset-tool utility:

    (UNIX) FA_ORACLE_HOME/lcm/idmpasswordreset/bin 
    

    FA_ORACLE_HOME is the Oracle Fusion Applications Oracle home located at:

    (UNIX) APPLICATIONS_BASE/fusionapps/applications
    

    The password-reset-tool utility is not available on Windows.

  4. Run the password-reset-tool utility:

    password-reset-tool.sh APPLICATIONS_BASE/provisioning/plan/provisioning.plan
    

    where provisioning.plan is the file generated at the beginning of the preverify phase with the Provisioning Wizard. For more information about the preverify phase, see "Provisioning a New Applications Environment" table in the Oracle Fusion Applications Installation Guide.  

  5. When prompted, enter the password for cn=orcladmin.

  6. When prompted, enter Y for the password of the users you want to change, and enter N for all other users.

    If you are not using faadmin for the Oracle Fusion Middleware administrative user, then answer N for that user.

  7. Provide the new password for the users.

  8. Let the utility run to completion (without interruption).

  9. Stop and restart all the Administration Servers. See Section 4.4.4.

6.8.6 Updating Certificates with the Certificate Renewal Utility

Self-signed certificates created in Oracle Fusion Applications 11g Release 4 (11.1.4) and earlier provisioning versions have a six month life span. Beginning in Oracle Fusion Applications 11g Release 5 (11.1.5), certificates have a three year life span.

The Certificate Renewal Utility enables you to update your self-signed certificates. You must run this utility on pre-Release 5 environments to keep those environments working.

This section contains the following topics:

6.8.6.1 About the Certificate Renewal Utility

The certificate renewal utility updates and replaces old self-signed certificates with new self-signed certificates with a three year life span. The utility updates the following keystores:

Note:

For details about the home directories mentioned here, see Table 1-4 and Figure 1-6.

  • OWSM keystore default-keystore.jks for all available domains under every host, that is, under:

    (UNIX) APPLICATIONS_CONFIG/domains/host_name/domain_home/config/fmwconfig
    (Windows) APPLICATIONS_CONFIG\domains\host_name\domain_home\config\fmwconfig
    
  • OWSM keystore owc_discussions.jks for the CommonDomain domain only.

  • fusion_trust.jks and host_fusion_identity.jks located in either WL_HOME/server/lib or APPLICATIONS_CONFIG/keystores.

  • Oracle wallet cwallet.sso file present under WL_HOME/server/lib.

Note:

In a multi-host environment, there are as many host_fusion_identity.jks files as there are hosts.

6.8.6.2 Location of the Certificate Renewal Utility

The certificate renewal utility is located at:

(UNIX) APPLICATIONS_BASE/fusionapps/applications/lcm/facertsutil
(Windows) APPLICATIONS_BASE\fusionapps\applications\lcm\facertsutil

The utility makes use of a properties file with path definitions. A reference properties file is located at:

(UNIX)
APPLICATIONS_BASE/fusionapps/applications/lcm/facertsutil/config/crutil.properties
(Windows)
APPLICATIONS_BASE\fusionapps\applications\lcm\facertsutil\config\crutil.properties

6.8.6.3 Before Using the Certificate Renewal Utility

Take these steps before running the certificate renewal utility:

  1. If SSL is not enabled:

    1. Stop all the Administration Servers, either manually or using the fastartstop utility.

    2. Stop the Node Manager.

  2. If SSL is enabled:

    1. Stop all the Administration Servers.

    2. Stop middle tier components; however, the database and identity management components can continue running.

  3. Navigate to the location of fusion_trust.jks, either:

    (UNIX) APPLICATIONS_CONFIG/keystores
    (Windows) APPLICATIONS_CONFIG\keystores
    

    or

    (UNIX) WL_HOME/server/lib
    (Windows) WL_HOME\server\lib
    
  4. Run keytool to check the validity of current certificates in the keystore:

    keytool -list -keystore fusion_trust.jks 
    
    -alias fa-internal.example.com_fusion -v 
    

    keytool will prompt for the store password.

  5. Ensure that the properties file is configured with the correct paths required during utility execution.

    Here is an example properties file:

    # For all the paths append _path as suffix so that the validation
    # will be done at the time of loading the properties
     
    # Uncomment either Old Path or New Path depending on your environment.
     
    # Best practice to use '/' as path separator
     
    # fusion trust, cwallet_sso and *_fusion identity keystore locations
    # Old path
    #wlks_path=APPLICATIONS_BASE/fusionapps/$WL_HOME/server/lib
    # New path with flex clone changes
    #wlks_path=APPLICATIONS_CONFIG/keystores
     
    # Instance specific files FUSION_env and FUSION_prov properties files
    # Old path
    #fusion_props_path=APPLICATIONS_BASE/fusionapps/applications/admin
    # New path with flex clone changes
    #fusion_props_path=APPLICATIONS_CONFIG/fapatch
     
    # default and owc_discussions keystore locations across all domains
    #domainks_path=APPLICATIONS_CONFIG/domains
     
    # Certificate validity period in days, configured for 3 years by default.
    # This value can be changed as per the renewal requirement
    validity_period=1095
     
    # Path of intermediate config property file generated by this utility
    # which stores information of all the domains that needs to be updated
    # generated with name "domains.properties"
    config_prop_path=APPLICATIONS_BASE/fusionapps/applications/admin/
     
    # Application config directory
    appnconfig_path=APPLICATIONS_CONFIG
     
    # domains folder suffix under 
    # APPLICATIONS_CONFIG/domains/<host_name>/<domains_suffix>
    # Based on this suffix we identify the list of domain folders from this 
    # location
    # NEED NOT BE CHANGED unless the convention is changed in creating domain 
    # folders
    domains_suffix=Domain
    

6.8.6.4 Using the Certificate Renewal Utility

Take these steps to execute the utility:

  1. Navigate to:

    (UNIX) APPLICATIONS_BASE/fusionapps/applications/lcm/facertsutil/bin
    (Windows) APPLICATIONS_BASE\fusionapps\applications\lcm\facertsutil\bin
    
  2. Set the JAVA_HOME environment variable to:

    (UNIX) APPLICATIONS_BASE/fusionapps/jdk6
    (Windows) APPLICATIONS_BASE\fusionapps\jdk6
    
  3. Run the certificate renewal utility using this syntax:

    (UNIX) 
    ./facertsutil.sh -inputfile path_to_properties_file -appbase APPLICATIONS_BASE
    
    (Windows) 
    facertsutil.cmd -inputfile path_to_properties_file -appbase APPLICATIONS_BASE
    

    For example:

    ./facertsutil.sh -inputfile ../config/crutil.properties -appbase APPLICATIONS_BASE 
    

6.8.6.5 After Using the Certificate Renewal Utility

Take these steps after running the certificate renewal utility:

  1. Navigate to the location of fusion_trust.jks, either:

    (UNIX) APPLICATIONS_CONFIG/keystores
    (Windows) APPLICATIONS_CONFIG\keystores
    

    or

    (UNIX) WL_HOME/server/lib
    (Windows) WL_HOME\server\lib
    
  2. Run keytool to check that certificate validity was extended by the period specified in the properties file:

    keytool -list -keystore fusion_trust.jks 
    
    -alias fa-internal.example.com_fusion -v 
    

    keytool will prompt for the store password.

  3. If SSL is not enabled:

    1. Start the Node Manager.

    2. Start all the Administration Servers either manually or using the fastartstop utility.

  4. If SSL is enabled:

    1. Start all middle tier components.

    2. Start all the Administration Servers.

6.9 Data Masking

Data masking is the ability to replace sensitive data with realistic but false data on test and development databases. Features include:

This section contains the following topics:

6.9.1 Introduction to Data Masking

Data masking is an on-going activity for the Oracle Fusion Applications administrator. It requires an understanding of masking concepts, methodology, and the implementation tools:

For more information, also see Oracle Database Real Application Testing User's Guide.

6.9.1.1 Masking Terminology

Key terms used in data masking are as follows:

  • Pre Masking script - A SQL script that runs prior to the start of masking.

  • Post masking script - A SQL script that executes after all masking completes. For example, such a script can be used to recompute aggregated columns after the detailed data is masked. This ensures that aggregated and masked columns are consistent and the totals match.

  • User-Defined Function (UDF) - A user-defined function takes the original value, the row id, and column name to generate the mask value. A single column format can be a combination of one of more formats including UDF.

  • Post-processing function - This is a special case of a user-defined function. A post processing function (PPF) is called after the mask value is generated using the specified format. The function takes the generated mask value and further modifies it to produce the actual mask value.

    For example if the format used Random Number (1000,10000) and Post Processing Function (checksum) a number between 1000 and 10000 is generated and this value is fed into the PPF. The PPF computes the checksum and appends it to the original number and returns the new mask value.

    There can be only one PPF to a column. A PPF cannot be the only format for a column. There has to be some other format preceding the function.

6.9.1.2 Types of Sensitive Data

Examples of sensitive data include:

  • Salary information

  • Government IDs like drivers' license numbers and social security numbers

  • Geographical data such as GPS coordinates

Each product family has its own set of sensitive data types.

For details about sensitive data types, see the Oracle Fusion Applications Security Guide.

6.9.1.3 The FAST Methodology

Data masking requires the user to implement the FAST (Find, Assess, Secure, Test) methodology:

  • Find

    The first step is to identify sensitive data that should be subject to data masking. This includes personally identifiable data or information that could be misused. Examples include:

    • Salary Information

    • Driver's License Number

    • Military Service ID

    • Biometrics Data

    Another aspect of this effort is to determine where this data is located. The recommended procedure involves:

    • Defining pattern-matching rules against sensitive tables and columns. Examples of such rules include a column name like "*SSN*" or column format "###-##-####".

      For database independence, applications typically do not store the primary key-foreign key relationships in the database itself; rather, the relationships are enforced in the application. To support this, the Data Masking Pack provides administrators with the ability to register these relationships so that columns in related tables, such as EMPLOYEE_ID, MGR_ID, are masked identically using the same masking rules.

    • Searching Oracle databases to find these patterns.

    • Importing the relevant database fields into a data privacy catalog.

    • Maintaining the catalog as new fields are identified.

  • Assess

    In this phase you specify how each sensitive field is to be masked, that is, transformed into a non-sensitive representation while maintaining the field's structure. This is typically accomplished through a data masking definition, which associates tables and columns in a schema with appropriate masking formats. An example is a mask format that converts the name "John" in the Employee table to "Andy".

    The Data Masking definition contains a list of sensitive columns in the application tables, such as employee social security numbers, and its corresponding association with data masking formats, such as a fictitious social security number generator.

    Note:

    Oracle Fusion Applications provide a set of default mask templates for basic sensitive fields; administrators can update these definitions according to application requirements. For details about viewing and updating masking templates, see Section 6.9.3

  • Secure

    This phase enables the masks to be executed securely to generate the masked data. Notable aspects of this phase include:

    • Production database cloned in restricted mode for the execution

    • Privilege delegation allowing the mask to be executed with tools like sudo or PowerBroker

    • Generation of test database

  • Test

    The test phase involves comparing before and after values for verification. Redo logs are available to restore data to pre-mask state.

6.9.1.4 Administration Tools

Data masks and masking definitions are created and managed with Oracle Enterprise Manager Cloud Control.

6.9.2 Data Masking in Oracle Fusion Applications

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:

6.9.2.1 Requirements for Data Masking

You should be aware of certain background information, prerequisites, and requirements before undertaking data masking operations in your environment.

This section contains the following topics:

6.9.2.1.1 Data Model Descriptions

You must understand the data model for your application data when deciding how and what to mask. For data model descriptions, see the product-specific documentation from Oracle Enterprise Repository for Oracle Fusion Applications.

6.9.2.1.2 Required Versions

Data masking requires the following:

  • Oracle Database 10g Release 2 or Oracle Database 11g Release 1

  • Oracle Enterprise Manager Grid Control 10g Release 4 or Oracle Enterprise Manager Cloud Control 12c

  • The Oracle Data Masking Pack

6.9.2.1.3 Preliminary Steps

You must perform certain steps, such as installing a format library and configuring temp spaces, before using data masking in an Oracle Fusion Applications environment:

  1. Install the FMTLIB package, which contains functions needed to perform data masking.

    1. Locate these scripts in your Oracle Enterprise Manager installation:

      $PLUGIN_HOME/sql/db/latest/masking/dm_fmtlib_pkgdef.sql
      $PLUGIN_HOME/sql/db/latest/masking/dm_fmtlib_pkgbody.sql
      
    2. Copy these scripts to a directory in your target database installation.

    3. Execute the scripts using SQL*Plus, connected as a user that can create packages in the DBSNMP schema (SYSTEM or SYS).

  2. Apply any required patches. Data masking requires a specific Oracle Database version and patch set. See Section 4.8.

  3. Install the agent on the database host using Oracle Enterprise Manager.

  4. Discover the database using Oracle Enterprise Manager.

  5. Change the temp spaces used for data masking to "Auto Extend" from Cloud Control Console:

    1. Click Targets, then Databases.

    2. Select the database and log in.

    3. Navigate to Administration, then Storage, then Datafiles.

    4. On the Datafiles page, enter temp in the Object Name search box. Press Go. The temp spaces are displayed:

      Description of dmts3.gif follows
      Description of the illustration dmts3.gif

      When configured correctly for masking, as in this example, auto-extend is enabled for the temp spaces.

    5. If you need to set auto-extend, edit each temp space in turn by selecting its radio button and clicking Edit. Change the value for each space as shown here:

      Description of dmts4.gif follows
      Description of the illustration dmts4.gif

6.9.2.1.4 Temporary Space Requirements

As shown in Step 3 of Section 6.9.2.1.3 it is recommended that you auto extend your temp files as masking requires additional space for processing. The amount of additional space you need depends on your data. Broadly speaking, masking takes up approximately two times the size of the largest table being masked.

The temp space is needed for two reasons:

  • To perform sort and join operations during masking.

    The space requirement is not straightforward to estimate as it depends on whether sorts and joins go to disk, which in turn depends on how much memory is available on the machine. Try to keep at least as much space as the size of your biggest masked table for sort and join processing.

  • For space taken up in the default user tablespace for temporary masking tables.

    The size of the temp tables is twice the size of all the columns being masked. Since these tables are dropped after processing, the space is released after masking completes.

6.9.2.1.5 Database Free Space Requirements

Ensure that sufficient free space is available to the database before executing the masking job.

Calculate the free space requirements as follows:

largest table being masked +
total size of mapping tables for all columns in that table + 
temporary tablespace (roughly twice the size of the largest mapping table, as
stated under Temporary Space Requirements above)
6.9.2.1.6 Database and Operating System Parameters

The following database configuration is recommended:

max_dump_file_size  = 200M
memory_target = 26G
pga_aggregate_target = 6G
sga_max_size = 26G
sga_target = 0

The following operating system configuration is recommended:

  • Memory Address Space: Unlimited. For example, in the /etc/security/limits.conf file:

    oracle soft memlock unlimited
    oracle hard memlock unlimited
    
  • Memory Map Areas: 200000. For example,

    [my@host ~/rhe]$ /usr/local/packages/aime/ias/run_as_root su[root@host rhe]# echo 200000 > /proc/sys/vm/max_map_count
    
6.9.2.1.7 Role Requirements

The user executing the data masking script must have the dba role. If Virtual Private Database (VPD) security policies are used or Oracle Database Vault is enabled for the database, the user must be SYS.

Additionally, the user may need to have direct grants to objects for any PL/SQL objects provided to user-defined functions or post-processing scripts.

Optionally, you can grant EXEMPT ACCESS POLICY privilege to the masking user to bypass all VPD policies.

6.9.2.1.8 Custom Field Masks

Oracle Fusion Applications include a set of out-of-the-box masking definitions to mask common sensitive data like employee information and credit card numbers. However, these default mask templates cannot account for custom data such as flex fields since these are specific to your application.

You can update the standard masking definitions to include additional flex fields and custom data. For details about viewing and updating masking templates, see Section 6.9.3.

Note:

Be aware that certain sensitive custom attributes may depend on tables in other product families. For example, Procurement masking is dependent on Oracle Fusion CRM (for Suppliers and related entities, and for Procurement Contract terms and deliverables), on Oracle Fusion Supply Chain Management (for Items), on Oracle Fusion HCM (for Workers and Organizations), on Oracle Fusion Financials (for Ledgers), and on Oracle Fusion Project (for Projects and related entities).

6.9.2.1.9 Production-to-Test Requirement

During the production-to-test process, you must replace the production user names with dummy user names. This mandatory step is needed to avoid breaking anonymization.

6.9.2.2 Sensitive Data in Oracle Fusion Applications

Oracle Fusion Applications identify the common sensitive data types for each product family.

You can use Oracle Enterprise Manager Cloud Control to view the sensitive attributes specified in the masking definitions. You can update the definitions with any additional desired sensitive attributes, such as flex fields or other customized fields.

For details about how to view and update masking templates, see Section 6.9.3 and Section 6.9.4.

For additional information about data masking, see the Oracle Fusion Applications Security Guide.

6.9.2.3 Masking Definitions

A masking definition specifies the columns to be masked and the format of the masked data. Out-of-the-box "template" masking definitions are provided for each family of Oracle Fusion Applications.

Masking definitions in XML format masks enable the data masking utility to identify the database tables, columns, and column formats of the data being masked.

For details, see the Oracle Fusion Applications Security Guide.

6.9.3 Managing the Masking Definitions

You can modify the default masks provided with Oracle Fusion Applications, and create your own masking definitions. Use Cloud Control Console to manage and maintain the data masking definitions.

Note:

To configure Oracle Enterprise Manager Cloud Control, see Section 6.9.4.

This section contains the following topics:

Oracle Enterprise Manager Cloud Control Console online help provides more details on these topics.

Note:

You must follow the instructions in Section 6.9.2.1 before you can perform the operations described here.

6.9.3.1 Viewing and Modifying Data Masking Definitions

Note:

The procedure in this section assumes that the masking template file has been imported. If you have not done so already, see Section 6.9.4.1, "Importing the Masking Templates".

You can view and modify out-of-the-box data masking definitions as follows with Cloud Control Console:

  1. Ensure that the masking template file has been imported. For details about this task, see Section 6.9.4.1, "Importing the Masking Templates".

  2. Navigate to Enterprise, then Quality Management, then Data Masking Definition.

  3. Click the Targets tab.

  4. Click the Databases secondary tab.

  5. Select the database whose mask definition you are configuring from the list of databases.

  6. Under Related Links, select Data Masking Definitions. The Data Masking Definitions page lists the current masks for the database:

    Description of dmdef1.gif follows
    Description of the illustration dmdef1.gif

  7. Select the mask definition you wish to view or update and click Edit.

  8. Log in to the database.

  9. The Edit Masking Definition page appears. It lists the columns included in the mask definition.

    Description of dmdef2.gif follows
    Description of the illustration dmdef2.gif

  10. A number of 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 remove a column from the mask definition, check the box and click Remove.

  11. To introduce a new column into the definition, for example, click Add. The Add Columns page appears.

  12. 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:

    Description of dmdef3.gif follows
    Description of the illustration dmdef3.gif

  13. 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. You must specify a format for this column to complete the definition.

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

    Description of dmcoldef.gif follows
    Description of the illustration dmcoldef.gif

  15. You can 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.

    Description of dmdef5.gif follows
    Description of the illustration dmdef5.gif

    Note:

    You can use the Import Format button to import an existing format entry.

  16. 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.

Likewise, starting at the Edit Masking Definition page (Step 7 above), you can modify the definition of an existing column by clicking its Format icon. This is useful, for example, when you wish to customize the properties of a column's format entry, or specify a different format entry for the column.

6.9.3.2 Generating the Masking Script

When you modify a data masking definition by adding or removing columns, or by modifying an existing column's mask format, you must regenerate the SQL masking script to incorporate your changes. To generate the script:

  1. Follow Steps 1 through 7 of Section 6.9.3.1 to display the data masking definitions for the database.

  2. After a masking definition is modified, its status is listed as Script Not Generated."

    Select the definition and click Generate Script.

  3. After processing is complete, you can:

    • Integrate the masking script with the clone database process

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

      Description of dmdef9.gif follows
      Description of the illustration dmdef9.gif

      Note:

      The results page also displays the generated SQL script, which can be modified as well.

6.9.3.3 Customizing Mask Formats

The format library is a collection of common, ready-to-use masking formats you can use in masking definitions. Oracle Data Masking enables you to extend the default mask format library by tailoring the existing formats, or creating new formats to meet your own business needs.

Take these steps to add a new format:

  1. Follow steps 1 through 3 of Section 6.9.3.1 to select the database instance.

  2. Under Related Links, select Data Masking Format Library.

    Description of dmfmt1.gif follows
    Description of the illustration dmfmt1.gif

  3. When adding a new format, you can take an existing format as a starting point. For example, to create a new format for credit card number fields, you can select an existing credit card format and click Create Like.

    Description of dmfmt2.gif follows
    Description of the illustration dmfmt2.gif

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

Similarly, you can modify existing formats or create new formats on the Format Library page.

6.9.4 Data Masking in Oracle Enterprise Manager Cloud Control

This section contains these topics:

6.9.4.1 Importing the Masking Templates

Data masking on Cloud Control requires the following templates, which are shipped in the emfa sysman directory:

ADM_Oracle_Fusion_Applications_1.0_EM_12.1.0.1.0_Combined_Template.xml
Mask_Oracle_Fusion_Applications_1.0_EM_12.1.0.1.0_Combined_Template.xml

Note:

Data masking templates will be made available in a future Oracle Database plug-in release through the Self Update feature in Cloud Control, which enables you to obtain information about new updates and to review, download and apply the updates.

Use the following procedure to import the out-of-the-box data masking templates on Cloud Control:

  1. Grant Permissions.

    Use the FUSION user for all subsequent steps. Grant select_catalog_role and select any dictionary and DBA to the FUSION user.

  2. Deploy the TDM package.

    1. Navigate to Enterprise, then Jobs, then Job Activity.

    2. From the os command list, select Deploy Test Data management packages and click Go.

    3. Enter the job name, click add, and add the database where masking is to be run.

    4. Click parameters. From the list, select fusion driver.

    5. Click credential and enter the FUSION credentials. This user must have all the privileges specified in Step 1.

    6. Click parameters. Change Application Type to Oracle Fusion Applications.

    7. Click submit.

    8. When the job completes, verify that it succeeded. Review the job details and make sure there are no errors.

  3. Import the Application Data Model (ADM).

    1. Navigate to Enterprise, then Quality Management, then Data Discovery and Modelling menu.

    2. Click Action, then Import. Provide the ADM XML file ADM_Oracle_Fusion_Applications_1.0_EM_12.1.0.1.0_Combined_Template.xml, the ADM name, and the FUSION database.

    3. If prompted for database credentials, provide the FUSION user credentials.

    4. You might see one or more warnings indicating that duplicate sensitive types were not imported; these warnings can be safely ignored.

  4. Create a verification job.

    1. Navigate to Enterprise, then Quality Management, then Data Discovery and Modeling.

    2. Select the ADM you just imported. Navigate to Action, then Verify.

    3. Click Create Verification Job.

    4. Provide a job name and job description.

    5. Click New Credential, and provide the FUSION credentials.

    6. Schedule the job to start immediately, and click Submit.

  5. Check the job status.

    1. When the verification job completes, navigate to Enterprise, then Job Activity, then select all job status.

    2. Click go and check that your job completed successfully.

  6. Import the masking template file.

    1. Navigate to Enterprise, then Quality Management, then Data Masking Definitions. A list of masking definitions appears. Click Import.

    2. Import the masking template file Mask_Oracle_Fusion_Applications_1.0_EM_12.1.0.1.0_Combined_Template.xml.

    3. Provide the masking definition name.

    4. For the ADM name, specify the name of the FUSION ADM you created.

    5. For the database name, specify the FUSION database.

  7. Select the mask definition and click the generate script button.

    Script generation can take a few hours, so consider running it on VNC or on a terminal that will be available for a while to allow the job to complete. (If you run it on a laptop and have to disconnect it during execution, you will lose the browser that was generating the script.)

  8. When the job completes, you can view the impact report and save or view the script.

6.9.4.2 Submitting the Masking Script

After you have imported the masking template and generated the masking script by using the procedure described in Section 6.9.4.1, "Importing the Masking Templates", submit the masking script for execution by clicking submit job at the script generation page in Cloud Control.

6.9.5 Best Practices when Masking Test Databases

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

In the current release, when you implement 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 that you 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.

6.9.6 References

For a detailed tutorial of data masking:

  1. Go to http://www.oracle.com/technetwork/tutorials/index.html.

  2. Click the link to access the learning library.

  3. In the search field, enter Replacing Sensitive Data Using the Data Masking Pack and press Return.

  4. Select a lesson by clicking the link, then click Begin OBE.

For additional information about securing sensitive data, Oracle Fusion Applications data security policies, and related topics, see the Oracle Fusion Applications Security Guide. The Privacy chapter explains how Personally identifiable information (PII) is defined and protected.

For deployment guidelines, see Oracle Fusion Applications Customer Relationship Management Enterprise Deployment Guide.

6.10 Securing Web Services

Oracle Web Services Manager (WSM) provides a policy framework to manage and secure Web services consistently across your organization. Oracle WSM is available to the following users:

The Oracle WSM policy framework secures Web services with policies, which describe capabilities and requirements such as whether and how a message must be secured, whether and how a message must be delivered reliably, and so on.

This section contains the following topics:

For more information about the Oracle WSM policy framework, see the "Understanding Oracle WSM Policy Framework" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.

6.10.1 Local Policy Attachment

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). Table 6-21 lists key tasks related to LPAs.

Table 6-21 Common LPA Operations

Operation Reference

Configure LPA using Fusion Middleware Control and WLST

"Attaching a Policy to a Single Subject" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

Attach "no behavior" policies for Web Services and Web Service Clients

"Disabling a Globally Attached Policy" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

Remove LPAs for all Web services

"Attaching a Policy to a Single Subject" section, subsection titled Attaching a Policy to a Web Service Using WLST (Step 4) in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

Troubleshoot Web service security

"Diagnosing Problems" chapter in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services


6.10.2 Global Policy Attachment

A policy set, which can contain multiple policy references, enables you to attach policies globally to a range of endpoints of the same type. By attaching policies globally in this way, referred to as Global Policy Attachment (GPA), you can ensure that all subjects are secured by default. Table 6-22 lists key tasks related to GPAs.

Table 6-22 Common GPA Operations

Operation Reference

GPA concepts and usage; determining if a Web service or client is security-enabled

"Attaching Policies Globally Using Policy Sets" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

Create GPAs using Fusion Middleware Control and WLST

"Creating and Managing Policy Sets" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

Disable GPAs

"Enabling and Disabling a Policy Set" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

Determine what policies are enforced when both LPA and GPA are defined

"Calculating the Effective Set of Policies" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

View policies attached to a Web service

"Viewing the Policies That are Attached to a Web Service" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services

Validate a policy set

"Validating a Policy Set" section in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services


6.10.3 Web Services Security Profiles

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.

6.10.4 Key Exchange with the Domain Hosting Oracle Identity Manager

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.

For additional background and information on the certificate exchange needed to set up Web services security trust, see the Oracle Fusion Applications Security Hardening Guide.

Exporting a Keystore Alias from Application Domain

Take these steps to export the keystore alias:

  1. Navigate to the DOMAIN_HOME/config/fmwconfig directory of the domain.

  2. Run the keytool command to export the alias into a file called orakey.cert using syntax like in this example:

    JAVAHOME/bin/keytool -exportcert -alias orakey -file orakey.cert -keystore default-keystore.jks -storepass keystore-password
    

    This command creates a file called orakey.cert containing the exported orakey alias.

    When using this command, specify the alias name and keystore password applicable to your environment.

Importing a Keystore Alias into Oracle Identity Manager Domain

Take these steps to import the keystore alias:

  1. Copy the file generated by the export procedure (orakey.cert in the export example) into the DOMAIN_HOME/config/fmwconfig directory of the Oracle Identity Manager domain where you wish to import the alias.

  2. Run the keytool command using the following syntax to import the certificate:

    JAVA_HOME/bin/keytool -importcert -alias orakey -file orakey.cert -keystore default-keystore.jks -storepass keystore-password
    

This command imports the alias into the Oracle Identity Manager domain's keystore.

Similar steps are used to export the Oracle Identity Manager key and import it into the other domain.

6.10.5 Web Services Security Hardening

For detailed instructions about Web Services Security hardening, see the "Locking Down Web Services: Points to Consider" section in the Oracle Fusion Applications Security Hardening Guide.

6.11 Securing Oracle Fusion Middleware Products

This section describes security guidelines recommended for Oracle Fusion Middleware products in the context of Fusion Applications. These administrative tasks, typically carried out with Oracle Authorization Policy Manager, Oracle Enterprise Manager Fusion Middleware Control, or WLST scripts, apply only to a specific product.

6.11.1 Administrative Tasks and Features Specific to the IDCCS Stripe

This section describes administrative tasks and features specific to Oracle WebCenter Content in the IDCSS stripe of the policy store, and they do not apply to any other stripe.

The grants specified in the stripe IDCCS must conform to one of the grants described in Section 6.11.1.1.

Section 6.11.1.2 explains why not to delete groups or accounts in that stripe.

6.11.1.1 Grants Supported by Oracle WebCenter Content

Oracle Authorization Policy Manager allows an administrator to specify grants to accounts and groups in a number of combinations, but not all these combinations are supported by Oracle WebCenter Content. The following list identifies the grants in the IDCSS stripe that are supported and unsupported.

  • Grants to Accounts

    • User to account resource: supported.

    • Enterprise role to account resource: supported.

    • Application role to account resource: supported.

  • Grants to Security Group Resources

    • User to security group resource: not supported.

    • Enterprise role to security group resource: not supported.

    • Application role to security group resource: supported.

  • Grants to Entitlements

    • None supported.

Even though Oracle Authorization Policy Manager allows an administrator to define a non-supported grant in for Oracle WebCenter Content, such grants are ignored at runtime.

6.11.1.2 Security Groups and Accounts Associated with Documents

Oracle Authorization Policy Manager allows deleting a security group or account associated with a document; but Oracle WebCenter Content does not allow deleting such artifacts.

Security administrators should be cautious never to delete a security group or account associated with a document stored in the Oracle Content Server. If, however, such deletion takes place accidentally, the deleted artifact will automatically reappear.

6.12 Extracting Data from an LDAP- Based Store to a File

This section describes the use of the OPSS script migrateSecurityStore to extract the contents of one stripe and save it in an XML file.

To extract the policies in a given application stripe from an LDAP-based store, proceed as follows:

  1. Create a file with the following content and save it as, for example, exported-jazn-data.xml in the same directory where your jps-config.xml file is located:

    <?xml version = '1.0' encoding = 'UTF-8' standalone = 'yes'?>
    <jazn-data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/jazn-data-11_0.xsd">
      <jazn-realm default="jazn.com">
        <realm>
          <name>jazn.com</name>
        </realm>
      </jazn-realm>
    </jazn-data>
    
  2. Copy of your jps-config.xml file to, for example, copy-jps-config.xml.

  3. Edit the file copy-jps-config.xml to contain an instance and two contexts like the following:

    <serviceInstance location="./exported-jazn-data.xml"
                     provider="policystore.xml.provider" 
                     name="export.xml"/>
            
    <jpsContext name="ldap_source">
      <serviceInstanceRef ref="policystore.ldap"/>
     </jpsContext>
            
    <jpsContext name="xml_target">
      <serviceInstanceRef ref="export.xml"/>
    </jpsContext>
    
  4. Run the script migrateSecurityStore as in the following invocation (the arguments are written in separate lines for the sake of clarity only):

    migrateSecurityStore(type="appPolicies",
                         configFile="./copy-jps-config.xml", 
                         src="ldap_source",
                         dst="xml_target", 
                         srcApp="hcm")
    

    The above illustrates the extraction of the contents of the application stripe hcm to the XML file exported-jazn-data.xml. To extract the contents of any other stripe, specify the appropriate stripe name in the argument srcApp. No more than one stripe can be extracted at a time.

    Note that in the above example, both copy-jps-config.xml and exported-jazn-data.xml are assumed to be located in the same directory.

6.13 Customizing Security from Installation to Deployment

This section describes the typical flow of application security data from the application installation to the application deployment to a production environment, and, in particular, how to handle GUIDs in application policies throughout that flow; its phases, performed by developers and administrators, are explained in the following sections:

6.13.1 Installing a New Oracle Fusion Application

In this phase, an administrator installs a new Oracle Fusion environment whereby the following application-specific artifacts are installed and provisioned:

  • An identity store, containing users and security enterprise roles.

  • An LDAP-based policy store, containing functional policies.

  • An Oracle Fusion Data Security policy store, containing database resources and data security policies.

6.13.2 Customizing and Testing Security with Oracle JDeveloper

In this phase, a developer uses Oracle JDeveloper to customize and test functional security artifacts in the installed application. First, the developer needs an XML version of the application stripe in the installed LDAP-based store, the XML format been required by JDeveloper.

The obtain this file, the administrator proceeds as follows:

  1. Runs the OPSS script migrateSecurityStore with the argument preserveAppRoleGuid set to True to export the contents of the application stripe in the LDAP-based policy store to the XML file (called jazn-data.xml throughout this section). For details on this procedure, see Section 6.12.

    Important Note:

    The use of the argument preserveAppRoleGuid is strictly restricted to the scenario described above; in particular, that argument should not be used with migrateSecurityStore in a production environment or when migrating from a staging to a production environment.

  2. Edits the generated file jazn-data.xml to replace the group principal for enterprise roles with the group principal required by Oracle JDeveloper. Specifically, it runs a command that replaces, in that file, every instance of the string weblogic.security.WLSGroupImpl with the string oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl.

  3. Delivers the edited jazn-data.xml to the developer, who copies it to the directory <jdevapphome>/src/META-INF.

Then, within Oracle JDeveloper, the developer proceeds as follows:

  1. Defines a data source to point to the installed database security policy store.

  2. Uses the security policy overview editor to customize function security (in the XML-based policy store), as documented in the "Implementing Function Security" chapter of the Oracle Fusion Applications Developer's Guide.

  3. Creates test users and test groups, and run the application within Oracle JDeveloper. When the application is run, the WebLogic Server integrated in Oracle JDeveloper, merges jazn-data.xml with the domain file-based store system-jazn-data.xml.

  4. Once customization and testing within Oracle JDeveloper are completed, hands the file jazn-data.xml back to the system administrator.

6.13.3 Migrating to a Staging Environment

In this phase, the administrator proceeds as follows:

  1. If the staging environment already has a stripe for the application and that stripe is to be preserved, merges the file jazn-data.xml with the staging application policy store, using Oracle Authorization Policy Manager as described in the "Upgrading Oracle Fusion Applications Policies" chapter of the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition). The relevant artifacts involved in this merge are the baseline store, represented by the original XML file jazn-data.xml; the production store, represented by the staging policy store stripe; and the patch store, represented by the new, customizedjazn-data.xml file

    Otherwise, if the application stripe is not present or is present but need not be preserved, the administrator uses the OPSS script migrateSecurityStore with the argument overWrite set to TRUE to migrate application policies in the file jazn-data.xml to the staging policy store.

  2. Reconciles GUIDs in the Oracle Fusion Data Security policy store with GUIDs in application roles by running the command DSDataMigrator as described in Section 6.4.3. This operation does not modify the file jazn-data.xml but updates GUIDs in data security policies.

    Important Note:

    When migrating to a staging environment, reconciling GUID's is required only before deploying the application in the staging environment that will merge policies (from a developer's file-based policy store) containing newly introduced custom application roles that are also referenced in data security policies.

  3. Packs the file jazn-data.xml with the application EAR and deploys the application to the staging environment with the following system property set:

    -Djps.deployment.handler.disabled="true"
    

    The above setting disables the OPSS listeners and ensures that when the EAR is deployed, domain policies do not get overwritten or appended with those in the packed jazn-data.xml file.

    Note:

    Typically, the application deployment is set so that users and groups are not migrated during deployment. For details about this setting within Oracle JDeveloper, see the "Implementing Function Security" chapter in the Oracle Fusion Applications Developer's Guide.

6.13.4 Migrating to a Production Environment

In this phase, the administrator proceeds as follows:

  1. Migrates the staging policy store to the production policy store in one of the following two ways:

    • If the production environment has not undergone changes since the customization was tested in the staging environment, the administrator moves the staging policy store to the production store as described in Section 20.3.2.

    • Otherwise, if the production policy store has undergone changes since the customization was tested in the staging environment and those changes must be preserved, the administrator uses Oracle Authorization Policy Manager as described in the Upgrading Oracle Fusion Applications Policies chapter of the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition) to merge the customized, pillar-level jazn-data.xml with the production policy store.

  2. Reconciles GUIDs in the Oracle Fusion Data Security policy store with GUIDs in the Oracle Internet Directory LDAP-based policy store by running the command DSDataMigrator as described in Section 6.4.3.

    Important Note:

    When migrating to a production environment, reconciling GUID's is required only if application roles or data security have been modified in the production environment..

  3. Packs the file jazn-data.xml with the application EAR and deploys the application to the production environment with the following system property set:

    -Djps.deployment.handler.disabled="true"
    

    The above setting disables the OPSS listeners and ensures that when the EAR is deployed, domain policies do not get overwritten or appended with those in the packed jazn-data.xml file.