| Oracle® Fusion Applications Administrator's Guide 11g Release 6 Refresh 4 (11.1.6) Part Number E14496-14 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Administrator's Guide 11g Release 6 Refresh 4 (11.1.6) Part Number E14496-14 |
|
|
PDF · Mobi · ePub |
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:
Section 6.7, "Configuring SSL for Oracle Fusion Applications"
Section 6.8, "Managing Wallets, Keystores, Credentials, and Certificates"
Section 6.12, "Extracting Data from an LDAP- Based Store to a File"
Section 6.13, "Customizing Security from Installation to Deployment"
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.
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:
the identity store
authorization policies
enterprise roles
SSL wiring and its support structure including keystores and certificates
data masking
setting protected URIs for the infrastructure to work as expected
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.
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.
Fusion Applications support the following LDAP identity store types:
Oracle Internet Directory 11g
Active Directory 2008
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
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:
Section 6.3.2, "WebLogic Authenticators and the Primary Identity Store"
Section 6.3.4, "Best Practices for the Administrator Groups"
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:
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 |
|
|
|
Oracle Fusion Customer Relationship Management |
|
|
|
Oracle Fusion Human Capital Management |
|
|
|
Oracle Fusion Financials |
|
|
|
Oracle Fusion Procurement |
|
|
|
Oracle Fusion Project |
|
|
|
Oracle Fusion Incentive Compensation |
|
|
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.
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.
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.
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.
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.
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:
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:
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.
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.
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:
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.
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.
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
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).
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:
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 |
|
Job |
Enterprise role mapped to application role. Typically, the name of this role has the suffix |
|
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).
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.
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.
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:
Section 6.7.1, "SSL Configuration in Oracle Fusion Middleware"
Section 6.7.2, "SSL Configuration for Oracle Fusion Applications"
Section 6.7.3, "End-to-End SSL for Oracle Fusion Applications"
Section 6.7.4, "Checklist of SSL Connections for IdM Components"
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:
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.
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
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.
Key connections in Oracle Fusion Applications can be secured either during provisioning or post-provisioning.
This section contains the following topics:
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
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:
You can choose not to enable SSL connections during provisioning.
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.
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.
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) |
|
|
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.
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:
Enabling SSL on Oracle Fusion Applications Domains and Apps OHS
Enabling SSL between Oracle Fusion Applications Domains and IdM Components
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:
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.
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:
Section 6.7.3.2.1, "Enabling the SSL Listener on your application's WebLogic Managed Server"
Section 6.7.3.2.4, "mod_ossl Directives for Inbound SSL Configuration to Oracle HTTP Server"
Section 6.7.3.2.5, "List of Managed Servers for Oracle Fusion Applications Domains"
Take these steps to complete this task:
Log in to the Weblogic Administration Console as the "faadmin" user.
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.
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.
Scroll down the page and click Advanced to unhide the advanced server options.
Check the WebLogic Plug-In Enabled box so that the server can receive proxied requests.
Click Save.
Stop the managed server.
Restart the managed server to enable the SSL listener.
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:
Take these steps to enable SSL on the Apps OHS server which front-ends the Oracle Fusion Applications domain:
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.
Update the virtual host file to enable SSL:
Open the FusionVirtualHost_hcm.conf file using a text editor.
Search for the string "External virtual host for hcm".
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"
Scroll down in the file to "Context roots for application HcmBenefits".
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".
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.
Save and close the file.
Stop and restart the OHS server:
/root_dir/APPTOP/instance/CommonDomain_webtier/bin/opmnctl stopall /root_dir/APPTOP/instance/CommonDomain_webtier/bin/opmnctl startall
Take these steps to ensure SSL is operational:
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
Repeat for other application URLs for that managed 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 |
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/ |
|
CompensationServer_1 |
Yes |
https://hcmppbr.host.example.com/hcmCompensation/ https://hcmppbr.host.example.com/hcmCompensation/faces/ 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 https://hcmppbr.host.example.com/hcmCore/faces |
|
CoreSetupServer_1 |
Yes |
https://hcmppbr.host.example.com/hcmCoreSetup/faces |
|
Ess_server1 |
No |
|
|
HCMAnalyticsServer_1 |
No |
|
|
Odi_server1 |
No |
|
|
PayrollServer_1 |
Yes |
https://hcmppbr.host.example.com/hcmPayroll/faces/ https://hcmppbr.host.example.com/hcmPayroll/faces/ https://hcmppbr.host.example.com/hcmPayroll/faces/ https://hcmppbr.host.example.com/hcmPayroll/faces https://hcmppbr.host.example.com/hcmPayroll/faces https://hcmppbr.host.example.com/hcmPayroll/faces |
|
Soa_server1 |
No |
|
|
TalentManagementServer_1 |
Yes |
ttps://hcmppbr.host.example.com/hcmTalent/faces/ https://hcmppbr.host.example.com/hcmTalent/faces/ManageGoalsWorkArea https://hcmppbr.host.example.com/hcmTalent/faces/ManageProfilesWorkArea https://hcmppbr.host.example.com/hcmTalent/faces/ |
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/ https://hcmfinppbr.host.example.com/ledger/faces/ https://hcmfinppbr.host.example.com/ledger/faces/ |
|
PayableServer_1 |
Yes |
https://hcmfinppbr.host.example.com/payables/faces/InvoiceWorkbench https://hcmfinppbr.host.example.com/payables/faces https://hcmfinppbr.host.example.com/payables/faces |
|
ReceivableServer_1 |
Yes |
https://hcmfinppbr.host.example.com/receivables/ https://hcmfinppbr.host.example.com/receivables/ |
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 |
|
HelpPortalServer_1 |
No |
|
|
HomePageServer_1 |
Yes |
https://hcmcmppbr.host.example.com/homePage |
|
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 |
|
CRMAnalyticsServer_1 |
No |
|
|
CRMCommonServer_1 |
Yes |
https://hcmcrmppbr.host.example.com/crmCommon/faces https://hcmcrmppbr.host.example.com/crmCommon/faces |
|
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 https://hcmscmppbr.host.example.com https://hcmscmppbr.host.example.com https://hcmscmppbr.host.example.com |
|
CostManagementServer_1 |
Yes |
https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement https://hcmscmppbr.host.example.com/costManagement |
|
Ess_server1 |
No |
|
|
GlobalizationServer_1 |
Yes |
https://hcmscmppbr.host.example.com/globalization/faces |
|
LogisticsServer_1 |
Yes |
https://hcmscmppbr.host.example.com/logistics/faces https://hcmscmppbr.host.example.com/logistics/faces https://hcmscmppbr.host.example.comlogistics/faces |
|
Odi_server1 |
No |
|
|
OrderOrchestrationServer_1 |
Yes |
https://hcmscmppbr.host.example.com https://hcmscmppbr.host.example.com |
|
ProductManagementServer_1 |
Yes |
https://hcmscmppbr.host.example.com |
|
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 https://hcmprcppbr.host.example.com/procurement/faces |
|
Soa_server1 |
No |
|
|
SupplierPortalServer_1 |
Yes |
https://hcmprcppbr.host.example.com/supplierPortal/faces |
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 |
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.
This section contains these topics:
Section 6.7.3.3.2, "Configure SSL on the Apps OHS Server on the IdM Domain"
Section 6.7.3.3.3, "Configure SSL on the Authentication OHS Server"
Section 6.7.3.3.4, "Configure SSL on the Managed Server for Oracle Identity Manager"
Section 6.7.3.3.5, "Configure SSL for Oracle Access Manager"
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:
Log in to the IdM node as the Oracle Identity Manager administrator.
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: *******
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>
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
Make a note of this certificate as you will need it in the next section for Oracle HTTP Server configuration.
Take these steps to enable secure communication between the Application Oracle HTTP Server (Apps OHS) and IDM components:
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/”.
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.
Add a VirtualHost block to the Oracle Identity Manager configuration file and include the FusionSSL.conf file in the block.
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"
Modify "WebLogicPort nnnn" to point to Oracle Identity Manager's SSL managed server port (several occurrences).
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.
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):
Create an Oracle Wallet with certificates. For details, see the "Common Wallet Operations" section in the Oracle Fusion Middleware Administrator's Guide.
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
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
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
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
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
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.
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...
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
Repeat Steps 1 through 10 for any additional Apps OHS servers.
Take these steps to enable SSL on the Authentication Oracle HTTP Server (Auth OHS):
Replace the existing wallet files.
Navigate to the wallet directory located at /root_dir/idm/ohsauth/ohsauth_inst1/config/OHS/ohs1/keystores/default.
Move the existing cwallet.sso and ewallet.p12 files to a backup location.
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]$
Import the certificate for the Oracle Identity Manager's managed server as a trusted certificate, oimcert.crt, into the default Auth OHS wallet:
Confirm that that /root_dir/idm/Certs/oimcert.crt is also accessible from the IDM node.
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 .
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
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 ...
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...
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
Configure the load balancer to point to the new SSL virtual host created on the authenticating WebGate.
Take these steps to configure a trust store (used for outgoing requests) and enable SSL on the managed server hosting Oracle Identity Manager:
Log in to the Apps OHS node.
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.
Copy these certificates from the Apps OHS node to the node where the managed server for Oracle Identity Manager resides.
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
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
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
Log in to the WebLogic domain console as the “oim_admin” user.
Navigate to Environment, then Servers, then oim_server1. Click the Configuration tab, then General.
Check the “SSL Listen Port Enabled” box and provide an SSL port, as in this example:
Scroll down to the Advanced portion of the page. Check the "WebLogic Plug-In Enabled" box:
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".
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
Navigate to Environment, then Servers, then oim_server1, then Configuration, then SSL.
Provide the alias for the private key:
Private Key Alias: selfsigned
Save the changes.
Restart Oracle WebLogic Server if prompted to do so by the server.
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.
This section lists known issues with the SSL configurations described in this document. This section contains these topics:
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.
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.
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
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):
Table 6-19 Connections for Oracle HTTP Server
| Server Component | Inbound Clients to Server | Outbound Clients from Server |
|---|---|---|
|
OHS Server in Apps Domain - Section 6.7.3.2.2, "Enabling SSL on the Oracle HTTP Server for the Oracle Fusion Applications domain" |
Section 6.7.3.2.4, "mod_ossl Directives for Inbound SSL Configuration to Oracle HTTP Server" |
Applications OHS - Section 6.7.3.3.2, "Configure SSL on the Apps OHS Server on the IdM Domain" |
|
Auth OHS - Section 6.7.3.3.3, "Configure SSL on the Authentication OHS Server" |
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:
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.
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.
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
Enable Secure Sockets Layer (SSL) on ECSF to secure all connections that transmit passwords. These include connections to Oracle WebLogic Server, the ECSF servlet, and the Oracle SES server.
To enable SSL for ECSF, perform the following tasks:
Task 1, "Generate a Certificate for the Oracle WebLogic Server Instance"
Task 2, "Enabling SSL on the Oracle WebLogic Server Instance"
Task 3, "Add the Oracle WebLogic Server's Certificate to Oracle SES's Trust Store"
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.
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:
Configure SSL.
Select the server on which the ECSF application is running.
Make sure that the Allow Unencrypted Null Cipher checkbox is deselected (default).
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.
Save your changes.
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:
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.
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.
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:
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.
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.
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.
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:
Section 6.8.6, "Updating Certificates with the Certificate Renewal Utility"
Section 6.8.5.3, "Changing Oracle Identity Management Passwords"
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.
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.
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.
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.
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.
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:
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.
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.
The following provides a summary of the steps in a certificate's lifecycle:
Create an empty wallet (that is, a wallet that does not contain a certificate request).
Add a certificate request to the wallet.
Export the certificate request.
Use the certificate request to obtain the corresponding certificate.
Import trusted certificates.
Import the certificate.
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).
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:
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.
Typical keystore operations include the following:
Creating or updating a keystore.
Exporting and importing keystores.
Deleting a keystore.
Changing the keystore password.
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.
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.
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:
WebLogic data sources
These objects contain properties such as the URL or user name and password. Application components use data sources to obtain connections to a relational database.
You can create and manage JDBC data sources using the administration tools provided with Oracle WebLogic Server. For more information about managing data sources, see Oracle Fusion Middleware Configuring and Managing JDBC Data Sources for Oracle WebLogic Server and the "Configure JDBC data sources" topic in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help.
Application-specific credentials
These credentials provide access to different components of your application. An example is the credential associated with the designated super-user.
Application credentials are maintained through Fusion Middleware Control or Oracle WebLogic Scripting Tool (WLST). For details, see the "Configuring the Credential Store" topic in the Oracle Fusion Middleware Application Security Guide.
This section contains the following topics:
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.
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.
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.
To change the password of the Oracle Fusion Middleware administrative user using the Oracle WebLogic Server Administration Console:
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.)
From the target navigation pane, select Security Realms.
The Summary of Security Realms page is displayed.
Select a realm, such as myrealm.
The Settings for the realm page is displayed.
Select the Users and Groups tab, then the Users tab. Select the user.
The Settings for user page is displayed.
Select the Passwords tab.
Enter the new password, then enter it again to confirm it.
Click Save.
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).
To use the password-reset-tool utility:
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).
Ensure the Administration Servers for all domains are up. See Section 4.4.4.
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.
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.
When prompted, enter the password for cn=orcladmin.
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.
Provide the new password for the users.
Let the utility run to completion (without interruption).
Stop and restart all the Administration Servers. See Section 4.4.4.
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:
Section 6.8.6.2, "Location of the Certificate Renewal Utility"
Section 6.8.6.3, "Before Using the Certificate Renewal Utility"
Section 6.8.6.5, "After Using 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.
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
Take these steps before running the certificate renewal utility:
If SSL is not enabled:
Stop all the Administration Servers, either manually or using the fastartstop utility.
Stop the Node Manager.
If SSL is enabled:
Stop all the Administration Servers.
Stop middle tier components; however, the database and identity management components can continue running.
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
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.
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
Take these steps to execute the utility:
Navigate to:
(UNIX) APPLICATIONS_BASE/fusionapps/applications/lcm/facertsutil/bin (Windows) APPLICATIONS_BASE\fusionapps\applications\lcm\facertsutil\bin
Set the JAVA_HOME environment variable to:
(UNIX) APPLICATIONS_BASE/fusionapps/jdk6 (Windows) APPLICATIONS_BASE\fusionapps\jdk6
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
Take these steps after running the certificate renewal utility:
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
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.
If SSL is not enabled:
Start the Node Manager.
Start all the Administration Servers either manually or using the fastartstop utility.
If SSL is enabled:
Start all middle tier components.
Start all the Administration Servers.
Data masking is the ability to replace sensitive data with realistic but false data on test and development databases. Features include:
the ability to keep data properties (data type, width, and so on) intact and provide realistic data sets for analysis and testing.
ensuring various constraints like (Primary Keys, Uniqueness, Foreign keys) are maintained, preserving relational integrity.
using user specified formatting rules that ensure custom and packaged applications continue to work after the data is masked.
This section contains the following topics:
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.
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.
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.
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.
Data masks and masking definitions are created and managed with Oracle Enterprise Manager Cloud Control.
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:
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:
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.
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
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:
Install the FMTLIB package, which contains functions needed to perform data masking.
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
Copy these scripts to a directory in your target database installation.
Execute the scripts using SQL*Plus, connected as a user that can create packages in the DBSNMP schema (SYSTEM or SYS).
Apply any required patches. Data masking requires a specific Oracle Database version and patch set. See Section 4.8.
Install the agent on the database host using Oracle Enterprise Manager.
Discover the database using Oracle Enterprise Manager.
Change the temp spaces used for data masking to "Auto Extend" from Cloud Control Console:
Click Targets, then Databases.
Select the database and log in.
Navigate to Administration, then Storage, then Datafiles.
On the Datafiles page, enter temp in the Object Name search box. Press Go. The temp spaces are displayed:
When configured correctly for masking, as in this example, auto-extend is enabled for the temp spaces.
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:
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.
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)
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
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.
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).
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.
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.
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.
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.
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:
Ensure that the masking template file has been imported. For details about this task, see Section 6.9.4.1, "Importing the Masking Templates".
Navigate to Enterprise, then Quality Management, then Data Masking Definition.
Click the Targets tab.
Click the Databases secondary tab.
Select the database whose mask definition you are configuring from the list of databases.
Under Related Links, select Data Masking Definitions. The Data Masking Definitions page lists the current masks for the database:
Select the mask definition you wish to view or update and click Edit.
Log in to the database.
The Edit Masking Definition page appears. It lists the columns included in the mask definition.
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.
To introduce a new column into the definition, for example, click Add. The Add Columns page appears.
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:
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.
Click on the toolbox icon. The Define Column Mask page appears.
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.
Note:
You can use the Import Format button to import an existing format entry.
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.
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:
Follow Steps 1 through 7 of Section 6.9.3.1 to display the data masking definitions for the database.
After a masking definition is modified, its status is listed as Script Not Generated."
Select the definition and click Generate Script.
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.
Note:
The results page also displays the generated SQL script, which can be modified as well.
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:
Follow steps 1 through 3 of Section 6.9.3.1 to select the database instance.
Under Related Links, select Data Masking Format Library.
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.
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.
This section contains these topics:
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:
Grant Permissions.
Use the FUSION user for all subsequent steps. Grant select_catalog_role and select any dictionary and DBA to the FUSION user.
Deploy the TDM package.
Navigate to Enterprise, then Jobs, then Job Activity.
From the os command list, select Deploy Test Data management packages and click Go.
Enter the job name, click add, and add the database where masking is to be run.
Click parameters. From the list, select fusion driver.
Click credential and enter the FUSION credentials. This user must have all the privileges specified in Step 1.
Click parameters. Change Application Type to Oracle Fusion Applications.
Click submit.
When the job completes, verify that it succeeded. Review the job details and make sure there are no errors.
Import the Application Data Model (ADM).
Navigate to Enterprise, then Quality Management, then Data Discovery and Modelling menu.
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.
If prompted for database credentials, provide the FUSION user credentials.
You might see one or more warnings indicating that duplicate sensitive types were not imported; these warnings can be safely ignored.
Create a verification job.
Navigate to Enterprise, then Quality Management, then Data Discovery and Modeling.
Select the ADM you just imported. Navigate to Action, then Verify.
Click Create Verification Job.
Provide a job name and job description.
Click New Credential, and provide the FUSION credentials.
Schedule the job to start immediately, and click Submit.
Check the job status.
When the verification job completes, navigate to Enterprise, then Job Activity, then select all job status.
Click go and check that your job completed successfully.
Import the masking template file.
Navigate to Enterprise, then Quality Management, then Data Masking Definitions. A list of masking definitions appears. Click Import.
Import the masking template file Mask_Oracle_Fusion_Applications_1.0_EM_12.1.0.1.0_Combined_Template.xml.
Provide the masking definition name.
For the ADM name, specify the name of the FUSION ADM you created.
For the database name, specify the FUSION database.
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.)
When the job completes, you can view the impact report and save or view the 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.
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:
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.
Set up "dummy" test users to perform the testing.
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.
For a detailed tutorial of data masking:
Go to http://www.oracle.com/technetwork/tutorials/index.html.
Click the link to access the learning library.
In the search field, enter Replacing Sensitive Data Using the Data Masking Pack and press Return.
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.
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:
Developers, at design time through Oracle JDeveloper
System administrators in production environments by means of Fusion Middleware Control and command-line tools
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.
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 |
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 |
Oracle Web Services Manager supports three Web services security profiles:
AuthN Profile
SSL Profile - provides transport-level security
Message Security Profile - provides message-level security
Out-of-the box, Oracle Fusion applications are provisioned with the AuthN profile. You can move your deployment to a different profile if needed.
During provisioning, all Oracle Fusion Applications domains are set up to use a common keystore and credential store, whereas the Oracle Identity Management domain (which includes Oracle Identity Manager) uses a separate keystore, and stores credentials in a logical domain. Provisioning does not set up trust between these keystores. This section explains how to exchange trust with the Oracle Identity Manager domain, enabling Web services security when this domain is involved.
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:
Navigate to the DOMAIN_HOME/config/fmwconfig directory of the domain.
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:
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.
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.
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.
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.
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.
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.
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.
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:
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>
Copy of your jps-config.xml file to, for example, copy-jps-config.xml.
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>
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.
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:
Section 6.13.1, "Installing a New Oracle Fusion Application"
Section 6.13.2, "Customizing and Testing Security with Oracle JDeveloper"
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.
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:
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.
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.
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:
Defines a data source to point to the installed database security policy store.
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.
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.
Once customization and testing within Oracle JDeveloper are completed, hands the file jazn-data.xml back to the system administrator.
In this phase, the administrator proceeds as follows:
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.
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.
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.
In this phase, the administrator proceeds as follows:
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.
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..
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.
|
 Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|