The following topics are discussed:
The high-level information presented in this section includes links to other documents where the topic is explained in detail.
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 section is application security administrators and system security administrators.
Oracle Fusion Applications provisioning sets up the security infrastructure, including:
the identity store
authorization policies
enterprise roles
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 Integration with Oracle ADF Applications in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.
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:
Key connections in Oracle Fusion Applications can be secured either during provisioning or post-provisioning.
This section contains the following topics:
Figure 3-1 shows a high-level representation of a two-tier network topology in the typical Oracle Fusion Applications environment:
Figure 3-1 SSL Connections for Basic Network Topology
The diagram shows some representative domains.
SOAP is the Oracle Access Protocol used by Oracle Access Manager. LDAP is the LDAP-over-SSL protocol.
Several approaches to configuring SSL are available in the Oracle Fusion Applications environment. Choose one of the following options:
Not to enable SSL connections during provisioning.
If the first option is selected as the starting point, enable SSL Oracle Identity Management first (see End-to-End SSL for Oracle Fusion Applications), followed by the service-to-service connections.
Enable SSL connections to certain components during provisioning.
If the second option is selected as the starting point, protect now, service-to-service connections like those shown in dotted lines (blue) in the diagram; this includes, for example, connections to Oracle Business Intelligence. For details about this wiring, see SSL-enable Oracle Business Intelligence.
These connections are shown as solid lines (red) in the diagram and include IdM components like Oracle Access Manager and Oracle Internet Directory. Table 3-1 lists these connections.
Enable SSL connections post-provisioning.
Consider 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 with 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 3-1 shows the connections that are SSL-enabled at provisioning:
Table 3-1 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 End-to-End SSL for Oracle Fusion Applications.
This section provides step-by-step procedures to enable SSL between Oracle HTTP Server (OHS) and Oracle WebLogic Server (WLS). This includes SSL traffic to Oracle HTTP Server, on Oracle Fusion Applications domains, and between Oracle Fusion Applications domains and components in the Identity Management (IDM) domain. SSL is enabled using a self-signed certificate, with one-way SSL communication (server-auth mode).
Procedures for supplementary tasks like keystore and certificate maintenance are also included.
This document contains the following topics:
Keep the following points in mind while working 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 request 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, which do not need to be recreated again.
APPLTOP
is a placeholder that refers to the top-level directory where Oracle Fusion Applications is installed.
Figure 3-2 illustrates the SSL wiring:
Figure 3-2 SSL Connections on Oracle Fusion Applications Domains
Two distinct component stacks are pictured here. On the left is the identity management stack with an Oracle HTTP Server on the front end. This server 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.
The following procedure can be applied to any managed server that must be SSL-enabled.
There are two distinct tasks to perform:
Enable SSL on the application's WebLogic managed server.
Enable SSL on the OHS which front-ends the Oracle Fusion Applications domain.
The steps in the procedures use the Benefits managed server in the HCMDomain
domain as en example.
This section contains the following topics:
Complete the following steps to enable the SSL listener:
Log in to the Weblogic Administration Console as the "faadmin" user.
Navigate to Environment, Servers, and then select BenefitsServer_1.
The Benefits server in HCMDomain
is used as an example. Substitute the relevant server in the environment.
Check the "SSL Listener Port Enable" box. Make sure that the SSL listener port number selected is not in use. Remember this port number for later use in the OHS configuration file.
Scroll down the page and click Advanced to view 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 the domain that must be SSL-enabled. For tables of managed servers by domain, see List of Managed Servers for Oracle Fusion Applications Domains.
Figure 3-3 shows a sample configuration:
Figure 3-3 Enable SSL on a Managed Server
Complete the following steps to enable SSL on the Apps OHS server with an Oracle Fusion Applications domain on the front end:
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 the "External virtual host for hcm" 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" and change the port number for WebLogicCluster configuration to the SSL listener port specified in the earlier task in Enable the SSL Listener on the 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>
The port number must match the SSL listen port on the managed server (as shown in Figure 3-3).
The directory "~/fusionapps/wlserver_10.3/server/lib" is the location where cwallet.sso
resides.
(Optional) 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
Complete the following 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.
The mod_ossl
plug-in enables Oracle HTTP Server to use SSL. This section describes certain key directives 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 the following: 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 protocol types, 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 suite that the client can use during the 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 3-2:
Table 3-2 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 3-3 lists the available cipher suite tags:
Table 3-3 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 Enable the SSL Listener on the application's WebLogic Managed Server.
Table 3-4 Managed Servers in the Oracle Fusion Human Capital Management Domain
Managed Server | SSL? | Application URLs |
---|---|---|
AdminServer |
No |
N/A |
BenefitsServer_1 |
Yes |
https://hcmppbr.host.example.com/hcmBenefits/faces/ HcmBenefitsProcessesAdministerBenefitsWorkArea |
CompensationServer_1 |
Yes |
https://hcmppbr.host.example.com/hcmCompensation/ faces/HcmCompWorkbenchWorkarea https://hcmppbr.host.example.com/hcmCompensation/faces/ HcmCompAdminWorkarea https://hcmppbr.host.example.com/hcmCompensation/faces/HcmCompPersonStatementWorkArea https://hcmppbr.host.example.com/hcmCompensation/faces/SetupMainPage |
CoreProcessesServer_1 |
Yes |
https://hcmppbr.host.example.com/hcmCore/faces /MyPortrait https://hcmppbr.host.example.com/hcmCore/faces /PersonSearch |
CoreSetupServer_1 |
Yes |
https://hcmppbr.host.example.com/hcmCoreSetup/faces /HcmWSIntWA |
Ess_server1 |
No |
N/A |
HCMAnalyticsServer_1 |
No |
N/A |
Odi_server1 |
No |
N/A |
PayrollServer_1 |
Yes |
https://hcmppbr.host.example.com/hcmPayroll/faces/ ChecklistUI https://hcmppbr.host.example.com/hcmPayroll/faces/ PayrollAdminWorkArea https://hcmppbr.host.example.com/hcmPayroll/faces/ PayrollCalculationWorkArea https://hcmppbr.host.example.com/hcmPayroll/faces /PaymentDistributionWorkArea https://hcmppbr.host.example.com/hcmPayroll/faces /AccountingWorkarea https://hcmppbr.host.example.com/hcmPayroll/faces /StatutoryReportsWorkArea |
Soa_server1 |
No |
N/A |
TalentManagementServer_1 |
Yes |
https://hcmppbr.host.example.com/hcmTalent/faces/ PerformanceWorkArea https://hcmppbr.host.example.com/hcmTalent/faces/ManageGoalsWorkArea https://hcmppbr.host.example.com/hcmTalent/faces/ManageProfilesWorkArea https://hcmppbr.host.example.com/hcmTalent/faces/ FacilitatorOverviewWorkArea |
Table 3-5 Managed Servers in the Oracle Fusion Financials Domain
Managed Server | SSL? | Application URLs |
---|---|---|
Admin Server |
No |
N/A |
Ess_server1 |
No |
N/A |
FinancialAnalyticsServer_1 |
No |
N/A |
FinancialCommonServer_1 |
Yes |
https://hcmfinppbr.host.example.com/financialCommon/faces/LegalEntityDashboard |
FinancialSearchServer_1 |
No |
N/A |
GeneralLedgerServer_1 |
Yes |
https://hcmfinppbr.host.example.com/ledger/faces/ JournalEntryPage https://hcmfinppbr.host.example.com/ledger/faces/ LedgerWorkArea https://hcmfinppbr.host.example.com/ledger/faces/ XlaEssMain |
PayableServer_1 |
Yes |
https://hcmfinppbr.host.example.com/payables/faces/InvoiceWorkbench https://hcmfinppbr.host.example.com/payables/faces /ExpenseShell https://hcmfinppbr.host.example.com/payables/faces /PaymentLandingPage |
ReceivableServer_1 |
Yes |
https://hcmfinppbr.host.example.com/receivables/ faces/ReceiptsWorkArea https://hcmfinppbr.host.example.com/receivables/ faces/TransactionsWorkArea |
Table 3-6 Managed Servers in the Oracle Fusion Setup Domain
Managed Server | SSL? | Application URLs |
---|---|---|
AdminServer |
No |
N/A |
Ess_server1 |
No |
N/A |
FunctionalSetupServer_1 |
Yes |
https://hcmcmppbr.host.example.com/setup/faces /TaskListManagerTop |
HelpPortalServer_1 |
No |
N/A |
HomePageServer_1 |
Yes |
https://hcmcmppbr.host.example.com/homePage /faces/AtkHomePageWelcome |
IPM_server1 |
No |
N/A |
Search_server1 |
No |
N/A |
Soa_server1 |
No |
N/A |
UCM_server1 |
No |
N/A |
WC_Collaboration |
No |
N/A |
WC_Spaces |
No |
N/A |
Wlcs_server1 |
No |
N/A |
Wlcs_sipstate1 |
No |
N/A |
Table 3-7 Managed Servers in the Oracle Fusion Customer Relationship Management Domain
Managed Server | SSL? | Application URLs |
---|---|---|
AdminServer |
No |
N/A |
ContractManagementServer_1 |
Yes |
https://hcmcrmppbr.host.example.com /contractManagement/faces/ContractsDashboard |
CRMAnalyticsServer_1 |
No |
N/A |
CRMCommonServer_1 |
Yes |
https://hcmcrmppbr.host.example.com/crmCommon/faces /CdmFoundationResourcesWorkArea https://hcmcrmppbr.host.example.com/crmCommon/faces /InteractionsDashBoard |
Ess_server1 |
No |
N/A |
Odi_server1 |
No |
N/A |
Soa_server1 |
No |
N/A |
Table 3-8 Managed Servers in the Oracle Fusion Supply Chain Management Domain
Managed Server | SSL? | Application URLs |
---|---|---|
AdminServer |
No |
N/A |
AdvancedPlanningServer_1 |
Yes |
https://hcmscmppbr.host.example.com /advancedPlanning/faces/ViewCollectedData https://hcmscmppbr.host.example.com /advancedPlanning/faces/MscCentralEssUi https://hcmscmppbr.host.example.com /advancedPlanning/faces/testAtpRule https://hcmscmppbr.host.example.com /advancedPlanning/faces /testManageDataCollectionProcess |
CostManagementServer_1 |
Yes |
https://hcmscmppbr.host.example.com/costManagement /faces/ItemCostProfileWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ManageCostElementWorkArea https://hcmscmppbr.host.example.com/costManagement /faces/ManageAnalysisGroupsWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ManageComponentGroupWorkArea https://hcmscmppbr.host.example.com/costManagement /faces/CostOrganizationsWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/DefaultCostProfileWorkArea https://hcmscmppbr.host.example.com/costManagement /faces/CostElementGroupWorkArea https://hcmscmppbr.host.example.com/costManagement /faces/RunControlWorkarea https://hcmscmppbr.host.example.com/costManagement /CostAccountingWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ManageCostElementWorkArea https://hcmscmppbr.host.example.com/costManagement /faces/CostProfilesWorkArea https://hcmscmppbr.host.example.com/costManagement /faces/ValuationStructureWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/CostProfilesWorkArea https://hcmscmppbr.host.example.com/costManagement /faces/ValuationStructureWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/CostProfilesWorkArea https://hcmscmppbr.host.example.com/costManagement /faces/ExpensePoolWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ValuationUnitsWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ExpensePoolWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ValuationUnitsWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ExpensePoolWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ReviewAccountingWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ReceiptAccountingWorkarea https://hcmscmppbr.host.example.com/costManagement /faces/ReviewDistributionsWorkarea |
Ess_server1 |
No |
N/A |
GlobalizationServer_1 |
Yes |
https://hcmscmppbr.host.example.com/globalization/faces /IntrastatWorkarea |
LogisticsServer_1 |
Yes |
https://hcmscmppbr.host.example.com/logistics/faces /RcvWorkArea https://hcmscmppbr.host.example.com/logistics/faces /ScmInvWorkArea https://hcmscmppbr.host.example.comlogistics/faces /WshDeliveriesWorkarea |
Odi_server1 |
No |
N/A |
OrderOrchestrationServer_1 |
Yes |
https://hcmscmppbr.host.example.com /orderOrchestration/faces /ProcessConstraintWorkarea https://hcmscmppbr.host.example.com /orderOrchestration/faces /DooOrchManageProcessDashBoard |
ProductManagementServer_1 |
Yes |
https://hcmscmppbr.host.example.com /productManagement/faces/ItemDashboard |
SCMCommonServer_1 |
No |
N/A |
SCM_PDQ |
No |
N/A |
Soa_server1 |
No |
N/A |
Table 3-9 Managed Servers in the Oracle Fusion Project Domain
Managed Server | SSL? | Application URLs |
---|---|---|
AdminServer |
No |
N/A |
Ess_server1 |
No |
N/A |
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 |
N/A |
Table 3-10 Managed Servers in the Oracle Fusion Procurement Domain
Managed Server | SSL? | Application URLs |
---|---|---|
AdminServer |
No |
N/A |
Ess_server1 |
No |
N/A |
ProcurementServer_1 |
Yes |
https://hcmprcppbr.host.example.com/procurement/faces /NegotiationWorkarea https://hcmprcppbr.host.example.com/procurement/faces /PrcPozSuppliersDashboard |
Soa_server1 |
No |
N/A |
SupplierPortalServer_1 |
Yes |
https://hcmprcppbr.host.example.com/supplierPortal/faces /PrcPosSupplierPortalWorkarea |
Table 3-11 Managed Servers in the Business Intelligence Domain
Managed Server | SSL? | Application URLs |
---|---|---|
AdminServer |
No |
N/A |
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 3-4, the Authenticating WebGate handles all the authentication requests on Oracle HTTP Server (OHS) host (identified by authohs.example.com), and also protects Oracle Identity Manager in the IDM domain. This Auth OHS host must be SSL-enabled, communication between the Apps OHS host and the IDM domain, and the Oracle Identity Manager managed server itself using the instructions in this section.
Figure 3-4 SSL to IDM Components
This section contains the following topics:
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
It is necessary to specify the keystore password.
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
Introduce the keystore password when prompted.
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 it is required 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".
Be sure to use the new file name in the target location. Use descriptive file names. For example, it is possible to specify oam.ssl.conf
to indicate that SSL for Oracle Access Manager only is being configured.
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 all occurrences of "WebLogicPort nnnn
" to point to Oracle Identity Manager's SSL managed server port.
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 one Location
block 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 Certificate Authority (CA) certificate for signing OHS wallets (Apps OHS and Auth OHS) by following the next steps:
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 Administering Oracle Fusion Middleware.
If a CA is intended to be used to sign Auth OHS and Apps OHS certificates, 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 if the imported certificates are present in 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 are used for Apps OHS and Auth OHS.
Restart the Oracle HTTP Server:
Note that pwd
present working directory. It is a linux command used in this particular case to illustrate which directory this is being implemented in.
[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 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 9 for any additional Apps OHS servers.
Complete the following 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 /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. Any load balancer of choice can be used.
This section provides background for configuring 11g WebGates and the Oracle Access Manager server for secure communication.
A WebGate agent must be provisioned to use Oracle Access Manager 11g authentication and authorization services. After installation and registration, Oracle Access Manager 11g 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 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 11g: 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 Registering and Managing OAM 11g Agents section in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.
To configure SSL for the OAP channel to Oracle Access Manager 11g, see the Securing Communication section in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.
This section lists known issues with the SSL configurations described in this document. The following topics are discussed:
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/LegalEntityDashboard result 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 the following message:
Secure Connection Failed ... ... Your certificate contains the same serial number as another certificate issued by the certificate authority. ...
Solution
Complete the following steps to manually delete and recreate the Oracle Identity Manager trust key store with a new certificate substituting actual paths for the samples shown:
/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 3-12 shows the connections for Oracle Internet Directory:
Table 3-12 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 Administering Oracle Fusion Middleware. |
Oracle Identity Manager - See the Enabling SSL for LDAP Synchronization section in the Oracle Fusion Middleware Administering Oracle Identity Manager. |
Database - See the Enabling Outbound SSL from Oracle Internet Directory to Oracle Database section in the Administering Oracle Fusion Middleware |
Oracle Internet Directory - See the Enabling SSL on Oracle Internet Directory Listeners section in the Administering Oracle Fusion Middleware. |
Oracle Access Manager - See the Outbound SSL from LDAP Authenticator to LDAP section in the Administering Oracle Fusion Middleware. |
Database - See the Enabling Outbound SSL from Oracle Internet Directory to Oracle Database section in the Administering Oracle Fusion Middleware |
Oracle Internet Directory - See the Enabling SSL on Oracle Internet Directory Listeners section in the Administering Oracle Fusion Middleware. |
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. |
Database - See the Enabling Outbound SSL from Oracle Internet Directory to Oracle Database section in the Administering Oracle Fusion Middleware |
Oracle Internet Directory - See the Enabling SSL on Oracle Internet Directory Listeners section in the Administering Oracle Fusion Middleware. |
Oracle Directory Services Manager - See the Logging Into the Directory Server from Oracle Directory Services Manager Using SSL section in the Oracle Internet Directory Administrator's Guide. |
Database - See the Enabling Outbound SSL from Oracle Internet Directory to Oracle Database section in the Administering Oracle Fusion Middleware |
Oracle Internet Directory - See the Enabling SSL on Oracle Internet Directory Listeners section in the Administering Oracle Fusion Middleware. |
Oracle Enterprise Manager - See the Oracle Enterprise Manager Fusion Middleware Control section in the Administering Oracle Fusion Middleware. |
Database - See the Enabling Outbound SSL from Oracle Internet Directory to Oracle Database section in the Administering Oracle Fusion Middleware |
Table 3-13 shows the connections for Oracle Access Manager:
Table 3-13 Connections for Oracle Access Manager and Oracle Identity Federation
Server Component | Inbound Clients to Server | Outbound Clients from Server |
---|---|---|
Oracle Access Manager - 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 Management. |
Oracle Internet Directory - See the Enable Inbound SSL on an Oracle Internet Directory Listener Using Fusion Middleware Control section in the Administering Oracle Fusion Middleware. |
Oracle Access Manager - Configure SSL for Oracle Access Manager |
mod_wl_ohs - See the Enable SSL for Outbound Requests from Oracle HTTP Server section in the Administering Oracle Fusion Middleware. |
Oracle Virtual Directory - See the Enable SSL for Oracle Virtual Directory Using Fusion Middleware Control section in the Administering Oracle Fusion Middleware. |
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 3-14 shows the connections for Oracle HTTP Server (OHS):
Table 3-14 Connections for Oracle HTTP Server
Server Component | Inbound Clients to Server | Outbound Clients from Server |
---|---|---|
OHS Server in Apps Domain - Enable SSL on the Oracle HTTP Server for the Oracle Fusion Applications domain |
mod_ossl Directives for Inbound SSL Configuration to Oracle HTTP Server |
Applications OHS - Configure SSL on the Apps OHS Server on the IDM Domain |
mod_ossl Directives for Inbound SSL Configuration to Oracle HTTP Server |
Applications OHS - Configure SSL on the Apps OHS Server on the IDM Domain |
It is possible to configure the components of Oracle Business Intelligence to communicate over SSL. For configuration details, see SSL Configuration in Oracle Business Intelligence section in the Security Guide for Oracle Business Intelligence Enterprise Edition.
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 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.
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.
To enable SSL on Oracle WebLogic Server:
Configure SSL.
Select the server on which the ECSF application is running.
Make sure that Allow Unencrypted Null Cipher is unchecked (default).
Configure the listen ports to enable the SSL listen port by checking the SSL Listen Port Enabled.
The SSL Listen Port is usually set as 7002
. This port number can be used to access the ECSF servlet through SSL (for example https://mywlsserver.host.com:7002/approot/searchfeedservlet/ConfigFeed
). Also note that the protocol in the URL must be https
.
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.)
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
.
SSL must be enabled on Oracle SES Query and Admin Services. For more information about how to enable SSL, see Oracle Secure Enterprise Search Administrator's Guide.
Since the Oracle SES server's certificate has not been signed by a reputable certificate authority (CA) but instead is a self-signed certificate, the certificate must be extracted from Oracle SES and added to both Oracle WebLogic Server's trust store and ECSF Command Line Administration Utility's trust store using these steps:
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, reconfigure the search engine instance parameters that contain URLs that point to the ECSF server. These parameters are ECSF_DATA_SERVICE
, ECSF_SECURITY_SERVICE
, and ECSF_REDIRECT_SERVICE
.
The protocol must change from http
to https
, and the http port must change from 7101
to 7002
, the SSL port. For example, change http://wlsserver.com:7101/approot/searchfeedservlet
to https://wlsserver.com:7002/approot/searchfeedservlet
.
It is important also to reconfigure the search engine instance parameters that contain URLs that point to the Oracle SES server. These parameters are SES_ADMIN_SERVICE
and SES_QUERY_SERVICE
.
The protocol must change from http
to https
. For example, change http://sesserver.com:7777/search/api/admin/AdminService
to https://sesserver.com:7777/search/api/admin/AdminService
. Do not change the port number because the instructions will switch the current port to be an SSL port instead of adding a separate SSL port.
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:
During the identity provisioning stage of installation, Oracle Fusion Applications require the existence of certain users with specific privileges. These administrative users are defined in the Security Console.
This section contains the following topic:
Implementation users perform the setup tasks in Oracle Enterprise Resource Planning (ERP) Cloud and Oracle Supply Chain Management (SCM) Cloud implementation projects.
Starting on Release 12, the implementation users with their data and provisioning roles, are created using Security Console.
For detailed information on defining implementation users, see topic Define Implementation Users: Overview in the Security Console section within Oracle Help Center (OHC).
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.
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 Plan the Topology and Provisioning of the Installation in Oracle Fusion Applications Installation Guide.
While there are logical sets of "super" administrative groups (a set of two per application family, consisting of the super-user administrator and the application administrator) it is possible to choose to distribute these functions among fewer individuals. The recommended best practice is to carefully plan the separation of duties, taking into account the real-world operational needs of the site.
The Security Console makes possible to add, update, and delete user accounts from applications and directories.
Identities can be created and managed when user records are created through activities such as employee hiring and creation of contacts through Oracle Fusion CRM. In addition, identities can also be created and managed administratively through the Security Console.
On Fusion Applications Release 12, the Authorization Policy Manager was removed and replaced by the Security Console.
Manages application security in the Oracle Applications Cloud service
Security-related tasks pertinent to role management
Role analysis
User-account management
Certificate management
Security Console: Overview
Setting Up the Security Console: Explained
Creating Users: Procedure
Creating Roles in the Security Console: Procedure
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.
To learn more about data masking concepts, see the Oracle Data Masking and Subsetting Guide Enterprise Manager JA.
Data masking is an on-going activity for the Oracle Fusion Applications administrator. This section explains how data masks and masking definitions are created and managed with Oracle Enterprise Manager Cloud Control, how to generate a masked database, and related administration tasks
This section contains the following topics:
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:
It is important to be aware of certain background information, prerequisites, and requirements before undertaking data masking operations in the environment.
This section contains the following topics:
It is essential to understand the data model for the 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 11g Release 1
Oracle Enterprise Manager Cloud Control 11 g or Oracle Enterprise Manager Cloud Control 12c
Oracle Data Masking and Subsetting Pack
For more information on installing and using Enterprise Manager Cloud Control, see Get Started with Enterprise Manager Cloud Control.
Certain steps must be performed before using data masking in an Oracle Fusion Applications environment.
MANDATORY: When using DB Plugin 12.1.0.7 and above, the required format libraries are automatically installed. Ensure the DB Plugin version is 12.1.0.7 or above.
Follow the below steps to configure temp spaces:
Apply any required patches. Data masking requires a specific Oracle Database version and patch set. See Patch Database Artifacts in Oracle Fusion Applications Patching Guide for more information.
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 setting auto-extend is needed, 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 Preliminary Steps it is recommended to auto extend the temp files as masking requires additional space for processing. The amount of additional space needed depends on the 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:
memory_target = 26G pga_aggregate_target = 6G sga_max_size = 26G sga_target = 0
Operating System Configuration (All Platforms)
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 the application.
It is possible to update the standard masking definitions to include additional flex fields and custom data. For details about viewing and updating masking templates, see View and Modify Data Masking Definitions.
Important:
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).
Oracle Fusion Applications identify the common sensitive data types for each product family.
It is possible to use Oracle Enterprise Manager Cloud Control to view the sensitive attributes specified in the masking definitions. The definitions could be updated 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 View and Modify Data Masking Definitions.
A masking definition specifies the columns to be masked and the format of the masked data. Out-of-the-box "template" masking definitions are provided for each family of Oracle Fusion Applications.
Masking definitions in XML format masks enable the data masking utility to identify the database tables, columns, and column formats of the data being masked.
The Software Library contains a collection of common masking templates for Oracle Fusion Applications which can be imported for use in the environment and modified as needed.
The following sections explain how to obtain and manage the data masking templates:
With auto-download enabled in the Self Update feature, the latest templates appear in the Software Library as they become available.
Otherwise, it is possible to access them manually as follows:
Important:
This procedure requires database plug-in 12.1.0.3 or above.
Import the Application Data Model (ADM) and the masking template file as follows.
Log in to Enterprise Manager Cloud Control (EMCC) using credentials that permit data masking.
Import the Application Data Model (ADM) using EMCC.
Note: If there is more than one database, the EMCC method requires that the same job for each database is submitted separately.
Click Action, then Import.
Provide the ADM XML file (for example, ADM_Oracle_Fusion_Applications_Rel<x>_Combined_Template.xm
l). Fill in a name and the fusion database.
If prompted for database credentials, provide the fusion user credentials.
Warnings indicating that duplicate sensitive types were not imported may be displayed; these warnings can be safely ignored.
Create a verification job.
Using EMCC, navigate to Enterprise then, Quality Management, and then Applications Data Model.
Note: If there is more than one database, the EMCC method requires that the same job for each database is submitted separately.
Click the ADM XML file imported and click Verify. (It is also possible to get to this task by navigating to Actions, and then Verify.)
Click Create Verification Job. Provide a job name and a job description.
Click New Credential, and provide the FUSION credentials.
Schedule the job to start immediately, and click Submit.
In EMCC, check the job status.
Navigate to Enterprise, choose Job, and then Activity. Then select All in the Status dropdown.
Click go and check that the job created has completed successfully.
Import the masking template file using EMCC.
Navigate to Enterprise, choose Quality Management, and then Data Masking Definition. The dropdown list contains data masking definitions and formats.
Click Import from the Software Library.
Select the required template and specify appropriate values for the input parameters.
For the ADM name, specify the name of the Fusion ADM created in Step 1.
For the database name, specify the fusion database.
Provide a masking definition name. For example, Oracle Fusion Applications HCM V1.0.
Select the mask definition and click the generate script button.
Script generation can take several hours. The EMCLI command list_masking_definitions
can be used to monitor the status of script generation. The status will be "Script generated" when complete. The script can then be saved or viewed, and the impact report checked.
It is also possible to export a template from the software library (for local editing or other tasks) using these steps:
It is possible to modify the default masks provided with Oracle Fusion Applications, and create preferred masking definitions. Use Oracle Enterprise Manager Cloud Control Console to manage and maintain the data masking definitions.
The procedure in this section assumes that the masking template file has been imported. If it have not been done so already, see Manage the Masking Templates.
MANDATORY: Follow the instructions in Requirements for Data Masking before performing the operations described in this section.
View and modify out-of-the-box data masking definitions as follows with Cloud Control Console:
Likewise, starting at the Edit Masking Definition page (Step 8 above), it is possible to modify the definition of an existing column by clicking its Format icon. This is useful, for example, when customizing the properties of a column's format entry, or specifying a different format entry for the column.
When modifying a data masking definition by adding or removing columns, or by modifying an existing column's mask format, the SQL masking script must be regenerated to incorporate the changes.
Generate the Masking Script
To generate the script:
The format library is a collection of common, ready-to-use masking formats that can be used in masking definitions. Oracle Data Masking enables the default mask format library to be extended by tailoring the existing formats, or creating new formats to meet the business needs.
Take these steps to add a new format:
Similarly, existing formats can be modified or new formats created on the Format Library page.
Identity data can reside in several repositories: the Oracle Database, the production identity store (an LDAP store), and the Oracle Identity Manager database.
In the current release, when implementing data masking, the identity attributes are only masked (anonymized) in the Oracle Fusion Applications database. To preserve masked values, ensure that these best practices are followed when using the masked data for a test database:
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 to maintain close access control to databases holding live cloned data, and make testers aware of their obligations and responsibilities regarding the data. As far as is possible, the processes around test data based on live data should mirror the processes around the live data itself. In particular, testers must not use privileged access to look beyond what they need to perform the required tests. For example, they must not try to work out to whom the data pertains, or try and find private information to satisfy their own curiosity.
To access a detailed data masking tutorial, perform the following steps:
Go to Oracle Technology Network.
Under Essential Links, click Tutorials.
In the search field, enter Replacing Sensitive Data Using the Data Masking Pack
and press Return.
Click the link to the lesson to start the tutorial.
Oracle Web Services Manager (WSM) provides a policy framework to manage and secure Web services consistently across the organization. Oracle WSM is available to the following users:
Developers, at design time through Oracle JDeveloper
System administrators in production environments with 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:
A policy subject is the target resource to which the policies are attached. Examples include Web services endpoints, Web service clients, SOA service endpoints, SOA clients, and SOA components.
Directly attaching one or more policies to a policy subject is referred to as Local Policy Attachment (LPA). The key tasks related to LPAs include:
Attaching policies to a single Web service endpoint
Managing and disabling policies at an endpoint
Removing (detaching) policies from a Web service endpoint
Troubleshooting Web service security
To locate the procedures for these tasks, see Attaching Policies Locally in the Oracle Fusion Applications Developer's Guide .
A policy set, which can contain multiple policy references, enables policies to be attached globally to a range of endpoints of the same type. By attaching policies globally in this way, referred to as Global Policy Attachment (GPA), it is possible to ensure that all subjects are secured by default.
The key tasks related to GPAs include the following:
Creating and managing policy sets
Validating policy sets
Enabling and disabling policy sets globally and for specific endpoints
Determining what policies are enforced when both LPA and GPA are defined
Viewing policies attached to a Web service
Troubleshooting Web service security
To locate the procedures for these tasks, see Attach Policies Globally in the Oracle Fusion Applications Developer's Guide .
Oracle Web Services Manager supports three Web services security profiles:
AuthN Profile
SSL Profile - provides transport-level security
Message Security Profile - provides message-level security
Out-of-the box, Oracle Fusion applications are provisioned with the AuthN profile. You can move your deployment to a different profile if needed.
During provisioning, all Oracle Fusion Applications domains are set up to use a common keystore and credential store, whereas the Oracle Identity Management domain (which includes Oracle Identity Manager) uses a separate keystore, and stores credentials in a logical domain. Provisioning does not set up trust between these keystores. This section explains how to exchange trust with the Oracle Identity Manager domain, enabling Web services security when this domain is involved.
Take these steps to export the keystore alias:
This section describes a variety of measures you can take to secure the Oracle Fusion Applications environment. Topics include:
To enhance security for network traffic to the database, Oracle Advanced Security supports data encryption and integrity for both servers and clients.
Oracle Database supports industry-standard algorithms for protecting the confidentiality of Oracle Net Services traffic. These algorithms:
Encrypt network data provides data privacy so that unauthorized parties are not able to view plaintext data as it passes over the network.
Ensure data integrity so that unauthorized parties are not able to modify data as it passes over the network. Integrity protects against two forms of active attack: Data modification attack and Replay attack.
Oracle Fusion Applications deploys with the following settings for client and server in the sqlnet.ora file:
Encryption Type: REQUIRED Checksum Level: REQUIRED
These settings mean that the encryption and integrity services are enabled.
The following instructions provide an example of how to confirm that only encrypted data is transferred between the database server and other sources:
The sqlnet.ora file on the two systems should contain the following entries:
On the Server
SQLNET.ENCRYPTION_SERVER = [accepted | rejected | requested | required] SQLNET.ENCRYPTION_TYPES_SERVER = (valid_encryption_algorithm ) SQLNET.CRYPTO_SEED = <randomstring_for_this_deployment_up_to_70_characters>
On the Client
SQLNET.ENCRYPTION_CLIENT = [accepted | rejected | requested | required] SQLNET.ENCRYPTION_TYPES_CLIENT = (valid_encryption_algorithm )
Components not in use in a deployment can represent unnecessary security risks. This section explains how to remove or disable such components.
Debug Utilities in a Workspace Web Application
For troubleshooting purposes, Enterprise Performance Manager (EPM) Workspace is delivered with uncrunched JavaScript files. For security, use these steps to remove these JavaScript files from the production environment:
Each subdirectory contains a .js file that bears the name of the directory. For example, Oracle_BI1/common/epmstatic/wspace/js/com/hyperion/bpm/web/common
contains Common.js
. Remove all .js files except the one that bears the name of the directory, in this case, Common.js
.
Operating System Services
The Linux platform provides a variety of operating system services, many of which are not necessary for most deployments. Examples of such services include FTP, TFTP, TELNET and so on.
Be sure to close both the UDP and TCP ports for each service that is being disabled. Disabling one type of port and not the other does not make the operating system more secure.
The back-channel refers to zones and network paths that are not directly accessible to external users or client programs.
In the Oracle Fusion Applications environment, back-channel communication is conducted by:
WebGate in Oracle HTTP Server within the Web Tier, using Oracle Access Protocol (OAP) to communicate with Oracle Access Manager
Managed and administration servers for the various product families in the Application Tier
Database and LDAP servers in the Data Tier
Oracle Fusion Web Services
For implementation details for securing back-channel communications, see Secure Web Services.
This section explains the Web services policies that external clients can use to further secure communication. The first step is to choose the appropriate mechanism for the client application; the second one is to configure the chosen mechanism.
The policy oracle/wss11_saml_or_username_token_with_message_protection_service_policy
contains the following assertions:
oracle/wss11_saml_token_with_message_protection_service_template
: a SAML-based authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard.
oracle/wss11_username_token_with_message_protection_service_template
: a username token authentication for inbound SOAP requests in accordance with the WS-Security 1.1 standard.
oracle/wss_saml_token_bearer_over_ssl_service_template
: a SAML-based authentication using credentials provided in SAML tokens with confirmation method 'Bearer' in the WS-Security SOAP header; it verifies that the transport protocol provides SSL message protection.
oracle/wss_username_token_over_ssl_service_template
: a username token authentication using the credentials in the UsernameToken WS-Security SOAP header to authenticate users against the configured identity store; it verifies that the transport protocol provides SSL message protection.
oracle/wss_http_token_over_ssl_service_template
: HTTP authentication using credentials extracted from the HTTP header to authenticate users against the configured identity store; it verifies that the transport protocol is HTTPS.
To determine the mechanism to use with the client application, consider the following cases:
To set up policy assertions, several configurations are needed, as explained in the following sections:
To set up each of the policy assertions, proceed as follows:
oracle/wss11_saml_token_with_message_protection_service_template
:
Import the service message encryption certificate on the client side, by following the task in Configure the Message Encryption Certificate (Client Side).
Configure the SAML token issuer on the service side, by following the task in Configure the Token Issuer Trust (Server Side) with trusted SAML clients.
oracle/wss11_username_token_with_message_protection_service_template
:
Import the service message encryption certificate on the client side, by following the task in Configure the Message Encryption Certificate (Client Side).
oracle/wss_saml_token_bearer_over_ssl_service_template
:
Configure the SAML token issuer on the service side, by following the task Configure the Token Issuer Trust (Server Side) with trusted STS servers.
oracle/wss_username_token_over_ssl_service_template
oracle/wss_http_token_over_ssl_service_template
To configure the message encryption certificate, an external client must get the certificate of the service, which is described in the Web Services Description Language (WSDL).
To extract the certificate from the WSDL, proceed as follows:
If the client application uses ID propagation or federated authentication, the client must authenticate with a SAML assertion from a SAML toke issuer.
To configure trust for the token issuer on the service side, proceed as follows:
Import the SAML token signing certificates into the domain trust store of the service with the use of the utility keytool
, as illustrated in the following sample invocation:
keytool -importcert -file <sts-signing-cert-file> -trustedcacert -alias <alias> -keystore default-keystore.jks
I f the SAML token signing certificate is issued from a CA, all the certificates in the certification chain must be imported.
Add SAML Issuer to the list of trusted issuers. Specifically, one needs to add the DN (Distinguished Name) of the signing certificate of the SAML Issuer to the list of trusted DNs. To define a list trusted DNs using EM Fusion Middelware Control, proceed as follows:
Select WebLogic Domain then, Web Services and then, Platform Policy Configuration
In that page, select the tab Trusted STS servers if oracle/wss_saml_token_bearer_over_ssl_service_template
if being configured, or the tab Trusted SAML clients, if oracle/wss11_saml_token_with_message_protection_service_template
is being configured.
Add the SAML issuer to the Trusted Issuers section of the page.
Select the trusted issuer for which a DN list will be defined and then add the trusted DN in the Trusted STS server's area of the page.
To further the security of Web Services, keep in mind the following adjustments and recommendations:
Choose a more secure policy appropriate for all the internal Web services; it is possible to choose to not distinguish between internal and external, and use the same policy for all Web services.
When changing the attachment of security policies, note that:
The client policy must be changed accordingly.
The client and callback policies must be compatible with the service being invoked; otherwise the Web service invocation will not work.
In case of exporting setup data, the corresponding Service and Callback policies for all Setup Data services must match the Functional Setup Manager (FSM) Processing Service (MigratorService) and FSM Migrator Callback Service (MigratorCallbackService) policies; these must be the same in all the domains so that FSM export and import are fully functional.
Use the same GPA policy across all the domains if the domain-wide GPA policy is changed.
If a secure sockets layer (SSL) policy is used, verify the following:
The Oracle HTTP Server (OHS) options have been set to propagate the SSL client certificate and settings to the Weblogic Server (WLS) if the SSL terminates at the OHS.
The SSL variables and client have been set to go to OHS and then load balancer (LBR) if the SSL terminates at the LBR level.
The policies for SAML Token (Sender Vouches) have been configured over SSL for two-way SSL. Other authentication tokens such as username token, and SAML bearer token require only one-way SSL.
Oracle Fusion Applications provisioning sets up the keystore with self-signed certificates that can be chosen to replace keys and certificates. For example, if there is an enterprise CA, its can be used to generate keys and certificates, but it is essential to:
Configure the Web services to accept only a configured list of SAML signers by configuring the trusted distinguished names (DN) list for SAML signing certificates in every domain. The private key configured for Oracle Web Services Manager (OWSM) is used for signing SAML Sender Vouches assertions. The certificates placed in the OWSM keystore are for verifying SAML assertions.
If the enterprise CA is put in the OWSM keystore, every certificate issued by the enterprise is acceptable for verifying assertion unless Web services is configured to accept only the list of SAML signers. For detailed information, see Configure the Token Issuer Trust (Server Side).
Enable hostname verification by setting the value of wsm.ignore.hostname.verification
to false. By default, host name verification is turned off in OWSM.
FA environments include the following two important administrator roles:
The FMWAdmin role, which has privileges to administer and monitor middleware components.
The FAAdmin role, which has privileges to do functional setup after the environment has been stood up.
Typically, the above two roles are granted to different users. But in bare-metal environments, during FA Provisioning, both roles can be granted to a single user and it is possible to choose that user to be FAAdmin or a different user in the Identity Store; this user is called the super user. If the super user is different from FAAdmin, then FAAdmin becomes a plain user with no special privileges.
The tools available to manage various passwords and certificates are the following:
The Password Reset Tool (PRT)
The Password Change Utility (PCU)
The Certificate Renewal Utility (CRU)
Password and certificate management tasks include the following typical ones:
Changing the FMWAdmin User password
Changing the FAAdmin User password with PRT
Changing the OAMAdmin User password with PRT
Changing the passwords of bind users used by Fusion Applications
Regenerating random passwords of application id users with PRT
Changing DB schema passwords with PCU
Updating certificates with CRU
The above tasks are explained in the following sections:
During the Oracle Fusion Applications installation, a password for the Oracle Fusion Middleware administration user must be provided; this account is used to log in to Fusion Applications Control and to the Oracle WebLogic Server Administration Console.
In environments where the FMWAdmin user and the FAAdmin user are different users, the password of the FMWAdmin user can be changed using either the Oracle WebLogic Server Administration Console or the WLST command line, as explained in Change the Oracle Fusion Middleware Administrative User Password Using the Command Line, and Change the Oracle Fusion Middleware Administrative User Password Using the Administration Console.
In environments where those two users are the same user (that is, the FAAdmin user), then use PRT to change the password of the FAAdmin user, as explained in Invoke PRT in Interactive Mode.
To change the Oracle Fusion Middleware administrative user password (or any other user password) using the command line, invoke the method UserPasswordEditorMBean.changeUserPassword
which is extended by the security realm's AuthenticationProvider MBean.
To change the password of the Oracle Fusion Middleware administrative user using the Oracle WebLogic Server Administration Console, proceed as follows:
FA installations need periodically to change passwords stored in the Identity Store. The Password Reset Tool meets this need by allowing to:
Change the password of the FAAdmin user
Change the password of the OAMAdmin user
Change the passwords of bind users used by Fusion Applications
Regenerate random passwords for all application id users
Application id user passwords are not used for login in, but internally by the system, for example, when wiring connections between components. Application id user passwords are set randomly during provisioning and can be reset randomly with PRT.
PRT changes the password of the FA administration user only if that user is FAAdmin; if the FA administration user has been set (during FA provisioning) to a user different than FAAdmin, then PRT will not change that user's password.
The use of this tool is explained in the following sections:
Before running PRT, make sure that perform a full system backup, and have exclusive access to the whole environment.
Note the following points about PRT execution:
The tool is not re-entrant; the system may reach an unstable state if the execution fails; re-running the tool will not fix a possibly unstable state.
The tool should be run by just a single user at a given time; it is not designed to be run concurrently.
The tool uses the default font type from the following location:
/usr/share/X11/fonts/TTF
The above location is required to exist. If such a location is not present in the system, then locate the path where the true type fonts are installed and create a symbolic link to the directory /usr/share/X11/fonts/TTF
.
The location of the true type fonts directory varies with systems but, typically, it is found in the following directories:
Linux x86-64: /usr/X11R6/lib/X11/fonts/TTF
Oracle Solaris: /usr/X11R6/lib/X11/fonts/TrueType
Before using PRT in the Oracle Fusion Applications environment, ensure that:
Java is installed on the system and that the JAVA_HOME environment variable is set.
ANT is installed on the system and that the ANT_HOME environment variable is set.
The password for the orcladmin user (the administrative user for Oracle Identity Management) is known.
Typically, a system outage is scheduled while PRT is running.
The Password Change Utility (PCU) is the tool that must be used to reset database schema passwords in a provisioned Fusion Application environment.
Using this tool, it is possible to update:
Database schema passwords
Datasource passwords using the schema users listed under schemas section of the input configuration (INI) file
Credential store keys
The ESS wallet and the ESS registry password
The ESSBase password
The BI repository password (and activate the new repository)
The ODI password
The IIR password.
The search schema FUSION_DISCUSSIONS_CRAWLER password for Announcement and Jive Forums User defined sources using searchadmin API
In release 12 , for IDM decoupled environments, PCU updates the schema password of FUSION_OPSS in bootstrap wallets in the following location <APPLTOP>/instance/domains/<domainhost>/<domainname>/config/fmwconfig/bootstrap/cwallet.sso
In addition, this tool also allows to:
Seed new CSF keys for new schemas and new system user CSF keys
Validate passwords stored in the LDAP store
Use a complexity check for the submitted passwords.
Details about PCU features and usage are found in the following sections:
By default, there are 90-100 database schemas (with user identities and passwords) delivered with a Fusion Applications environment. These should be updated periodically for security purposes, using PCU. The default PCU process will update all schemas (full mode); use subset mode to change the password for only a subset of schemas.
To use PCU, proceed as follows:
PCU can be used to update passwords separately in a DB, in WLS data sources, and in IDM data sources by using different targets; in the STANDARD mode, all these targets are updated.
The environment variable JAVA_HOME must be set to a JDK7 folder; the default folder is $APPBASE/fusionapps/jdk
.
The password complexity validation enables the passwords to be set according to complexity policies that define the characteristics a password must have. One policy is the following, for example: the password must contain a combination of at least two numeric characters, two alphabetic characters, and two special characters.
Each schema has its own password complexity validation function; to define a validation function that implements a particular schema policy, the password complexity functions and helper function must be installed in the Fusion Applications environment. If such a function is not defined for a given schema, then PCU uses the standard Java function to validate passwords for that schema.
To find out if a password complexity validation function is defined for a given schema, run the following SQL query:
select p.limit from dba_users u, dba_profiles p where u.profile=p.profile and u.username = <valid_schema_name> and p.resource_name= 'PASSWORD_VERIFY_FUNCTION';
If the above query returns a NULL limit, then no validation is defined for the schema. Otherwise, if it returns a DEFAULT limit, then run the following SQL query to get the name of the validation function from the DEFAULT profile:
select p.limit from dba_profiles p where p.profile = 'DEFAULT' and p.resource_name= 'PASSWORD_VERIFY_FUNCTION';
The returned non-null p.limit value specifies the name of the password complexity validation function, such as adm_dba_verify_function, for example.
To use a password complexity validation function, the helper function adm_dba_validate_pw
must be installed. This function takes the following arguments: the name of the password complexity validation function; the schema name; the new password to validate; and the existing schema password. adm_dba_validate_pw
invokes the password complexity validation function and returns TRUE, if the new schema password complies with the password complexity rules; or FALSE, if it does not.
templateGen
generates template files used by PCU, and needs to be run just once. templateGen
is run in either full or subset mode. In full mode, it generates a list of six templates, one of which the administrator must copy and use in subsequent steps. In subset mode, it generates only one template.
Use full mode (the default) when all 90-100 database schemas delivered with Fusion Applications need to be changed. Note that full mode would also change any custom schemas that may have been added to the own Fusion Applications environment.
In full mode, templateGen
has the following syntax. Note that the optional argument is shown in between square brackets. Also, if outputdir
is not specified, the generated files are located in $APPLICATION_CONFIG/lcm/admin/pcu
.
tempateGen Full Mode Syntax:
(UNIX)./templateGen.sh -appbase <APPTOP> [-outputdir <location of generated files>]
(WINDOWS) cd <APPTOP>\fusionapps\applications\lcm\util\bin
templateGen.cmd -appbase <APPTOP> [-outputdir <location of generated files>]
The tool generates the following template files:
standard_template.ini: This is the template used in the subsequent iniGen step.
csf_template.ini
validation_template.ini
system_user_template.ini
standard_template.properties
csf_template.properties
MANDATORY: In local domain configurations, the BIDomain section of templates is not auto-populated and must be manually filled in.
After generating standard_template.ini
, proceed to Run iniGen.
Subset mode is used when the passwords for only certain schemas will be changed. Sample use cases include:
Running PCU on all schemas except certain custom schemas created. In this case, exclude certain schema names.
The company policy calls for updating database passwords once annually, but the DBA wants to update the SYS password every two months. In this case, override a single (SYS) schema.
IMPORTANT:
Exclude means to change all passwords except the designed exclusions.
Override means to change only the listed schema passwords.
The syntax for excludelist
or overridelist
arguments supports specifying the necessary schemas in one of two ways: If the number of schemas is small, it is possible to itemize the schema names in a comma-separated list. If the number is unwieldy, it may be more practical to create a text file that lists the schemas together, and then add the text file in place of the comma-separated list of schemas. List each schema on a separate line in the text file.
Here are examples of each method:
Exclude a comma-separated list: ./templateGen.sh -appbase /u01/APPLTOP -loglevel finest -excludelist FUSION_BI,FUSION_DQ,FUSION
Exclude a list of schemas in a text file: ./templateGen.sh -appbase /u01/APPLTOP -loglevel finest -excludelist /u01/APPLTOP/instance/lcm/admin/pcu/exclude_schemas.txt
Specify one schema only: ./templateGen.sh -appbase /u01/APPLTOP -loglevel finest -overridelist FUSION_RO
Specify a list of schemas in a text file: ./templateGen.sh -appbase /u01/APPLTOP -loglevel finest -overridelist /u01/APPLTOP/instance/lcm/admin/pcu/override_schemas.txt
Running one of these four arguments results in the file subset_template.ini
being generated in /u01/APPLTOP/instance/lcm/admin/pcu
After generating subset_template.ini
, proceed to Run iniGen.
PCU requires an encrypted INI file that specifies the new database schema passwords and other important information about the Fusion Applications installation. This file is generated by iniGen
using template files produced by templateGen
.
The default location for the generated file is the directory $APPTOP/instance/lcm/admin/pcu
, and the default name of the generated file has the format input<time-in-millis>.ini, such as input1335820380736.ini
. However, it is possible to specify other location and name using the (optional) tool argument -outputfile.
iniGen
can execute in interactive or non-interactive mode. During an interactive execution, it is required to provide a password for the encryption program which uses the PBE algorithm to encrypt passwords.
During a non-interactive execution, start by editing a copy of the template file, as follows. In the entry master_password=ignore_me, replace ignore_me with a master password which will be used for the encryption; in all other properties that contain text token (#text#) or password token (#password#), replace those tokens with the appropriate values. Once the editing is finished, create an encrypted version of the file using some standard encryption tool. The recommended encryption tool is the provided lcmcrypt
, but its use is not required. For details about lcmcrypt
, see section Encrypt and Decrypt with lcmcrypt.
Note the following important points:
This document explains how to perform encryption and decryption using lcmcrypt
only.
In a non-interactive execution, ensure that the input file is synchronized with the template file.
The following lines illustrate how to run iniGen
in two modes of execution.
In interactive mode:
./iniGen.sh -appbase <APPTOP> -outputfile <ini file location> ./iniGen.sh -appbase <APPTOP> -template <template file location> -outputfile <ini file location>
In non-interactive mode:
step 1: echo <password> | ./lcmcrypt.sh -encrypt -inputfile <file that needs encryption> -nonInteractive step 2: echo <password> | ./lcmcrypt.sh -decrypt -inputfile <file that needs decryption> -nonInteractive | ./iniGen.sh -appbase <APPTOP> -nonInteractive
Running PCU offline allows changing passwords without bringing down the IDM administration server.
To invoke PCU offline, proceed as follows:
This section describes additional optional uses of PCU in the following section:
PCU can be run from a directory (other than the APPTOP directory) by using the -codebase
optional argument. If unspecified, the directory defaults to APPTOP; otherwise, it loads the PCU binaries and configurations from the specified directory.
MANDATORY: The only modes for which this feature is supported are CSF and CSF_CUSTOM. In particular, PCU in STANDARD mode must be run from the APPTOP directory.
The following procedure describes how to run PCU from a directory other than APPTOP.
Oracle provides lcmcrypt
, a tool to perform encryption and decryption on all platforms. When encrypting, lcmcrypt
reads the specified file and encrypts the file contents using the password supplied; then it generates an encrypted file (.enc extension) in the same directory as that of the input file and deletes the text file (provided as input). When decrypting, lcmcrypt
reads the supplied encrypted file and decrypts the file contents using the password supplied. The decrypted text is output to STDOUT and a text file is not generated.
The following lines illustrate the use of lcmcrypt
to encrypt a file:
echo pa55w0Rd | ./lcmcrypt.sh -encrypt -inputfile $APPTOP/instance/lcm/admin/pcu/standard_slcac574.ini --nonInteractive
The following lines illustrate the use of lcmcrypt to decrypt a file:
echo pa55w0Rd | ./lcmcrypt.sh -decrypt -inputfile $APPTOP/instance/lcm/admin/pcu/standard_slcac574.ini.enc --nonInteractive echo pa55w0Rd | lcmcrypt.cmd -decrypt -inputfile %APPTOP%\instance\lcm\admin\pcu\standard_slcah286.ini.enc -nonInteractive
Oracle Fusion Applications Release 12 introduces robust support for Pluggable Databases by separating management of local schema passwords from management of common schema passwords.
Local schema passwords are managed by the schema password change tool (PCU), which is the same tool that manages all schema passwords in Release 11 and lower. In Release 12, PCU only changes the passwords for local schemas. It continues to run on the FA middle tier and continues to store local schema passwords in Credential Store Framework (CSF) on the FA middle tier.
Common schema passwords are managed by a new Release 12 utility called Common User Password Change utility (CCU). CCU runs on one of the DB hosts and stores common user passwords in a wallet file in the DB oracle home called the Database Credential Store wallet file (the DBCS wallet file). After running CCU on one DB host, the DBCS wallet file must be copied to the DB oracle homes on the other DB hosts so that all DB hosts have the same contents in their DBCS wallet files.
During the upgrade to Release 12 common user credentials are copied from CSF into the DBCS wallet file.
Any program that needs a common user credential can either run on the DB host or require as input a local wallet file containing the required common user credentials.
This new Release 12 architecture applies for all configurations:
Both SaaS and non-SaaS
Both 11g and 12c database versions
For the 12c database, it applies to both non-CDB and CDB/PDB databases.
Starting in Oracle Fusion Applications Release 12, DB users are divided into the following two groups for both non-CDB and CDB/PDB:
Common users
Local users
Common Users
The common users are all the default schemas created as part of the database install.
FA also creates some additional common users such as C##DVOWNER and C##DVACCTMGR which are Data Vault related common users in CDB/PDB that do not exist in non-CDB.
Some important common users include: SYS, SYSTEM, C##DVOWNER, and C##DVACCTMGR.
Local Users
The local users are all the Fusion Apps and middleware schemas created by Provisioning.
Some important local users include: FUSION, FUSION_RUNTIME, FUSION_RO, and the four LCM admin schemas (LCM_*_ADMIN).
Table 3-15 Key Schemas
Schema | User Type | Store Location |
---|---|---|
SYS |
Common |
DBCS wallet |
SYSTEM |
Common |
DBCS wallet |
Other Common Schemas |
Common |
DBCS wallet |
FUSION |
Local |
CSF |
FUSION_RUNTIME |
Local |
CSF |
FUSION_RO |
Local |
CSF |
Other Local Schemas |
Local |
CSF |
Download and install the latest JAVA version from Oracle on all DB host
Set the JAVA_HOME environment variable pointing to it, or specify its location using the javahome argument to cpcu.sh. as follows:
echo welcome123! | ./cpcu.sh -pcubundle /scratch/aime/manskhan/pcubundle.zip -dbcswalletdir /scratch/aime/wallet -jdbcconnectstring jdbc:oracle:thin:@cdrmdb.us.oracle.com:1619/ems1198 -javahome /net/slc07rsb/scratch/aime/work/APPTOP/fusionapps/jdk6/ -oraclehome /slot/ems10923/oracle/db/tech_st/11.2.0/ -skipsys
General Instructions for Running CCU
skipsys
option. If you run it without the skipsys
, it will cause the SYS password in the CSF to be out of sync. Note that the above command will not change the SYS password to avoid causing an inconsistency with the CSF.Common users are not referenced by any pod-level configuration files and are not used during normal applications runtime or standard LCM activities. Therefore, common user passwords can be changed while the Fusion Apps environments are running in production.
CCU will read the DBCS wallet and create an encrypted INI file with the passwords from the DBCS wallet if the passwords are present for schemas; or random passwords will be considered if they are not present. This way full list of common users are handled. This approach is analogous to the P2T backup on the PDB. Restore then restores the passwords from the encrypted file.
pcubundle.zip
to the DB host.DB_CONNECT_STRING from the $APPTOP/instance/fapatch/FUSION_env.properties.
To restore the common user passwords to their backed-up values:
Run CCU.
Specify the INI file created by CCU backup as the CCU input file.
# export necessary properties
export STAGE_DIR=~
export APP_BASE=$STAGE_DIR/cdbpcu
export MASTER_PASSWORD=password # This is an illustration, you need to pass password in a secure way
export ZIP_LOC=$STAGE_DIR
export CODE_BASE=$APP_BASE/instance/tmp/pcu
export CDB_JDBC_CONNECT_STRING="jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.242.158.67)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=10.242.158.68)(PORT=1521))(LOAD_BALANCE=YES)(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=fdat)))"
export INPUT_WALLET=~/manskhan/wallet/cwallet.sso
export ENCRYPTED_FILE=$CODE_BASE/fusionapps/applications/lcm/util/config/cdb_backup_encrypted.ini
# setup pcu bundle in codebase mode on the database host + setup common driver schema
cd $STAGE_DIR
rm -rf lcm
rm -rf $APP_BASE
cp $ZIP_LOC/pcubundle.zip .
unzip pcubundle.zip
cd lcm/util/bin/
# For non-cdb, -inputwallet should contain DVOWNER and DVACCTMGR creds. For CDB, not required, an empty wallet should be passed nonetheless
echo $MASTER_PASSWORD | ./cpcu.sh -setup -pcubundle $ZIP_LOC/pcubundle.zip -jdbcconnectstring $CDB_JDBC_CONNECT_STRING -inputwallet $INPUT_WALLET -oh $ORACLE_HOME
cd $CODE_BASE/fusionapps/applications/lcm/util/bin/
pwd
### RESTORE
cd $CODE_BASE/fusionapps/applications/lcm/util/bin/
echo $MASTER_PASSWORD | ./schemaPasswordChangeTool.sh -cdb -appbase $APP_BASE/ -codebase $CODE_BASE -inputfile $ENCRYPTED_FILE -loglevel finest
### COPY DBCS WALLET from DB Host #1 to DB Host #2
# This step will be executed after every P2T restore so that both the DBCS wallets are in sync across RAC nodes
P2T and Cloning processes require this backup and restore feature as during these processes several updates and changes can be done, and the restore feature enables going back to the previous state.
The steps of backup-restore, mirror the steps of backup-restore on the PDB except that the -CDB argument is passed. Note that steps 1, 2, 3, and 4 are common to both backup and restore.
The Common User Password Change Utility always creates a backup copy of the DBCS wallet file prior to making any changes to it so that it will be possible to recover in case the wallet gets corrupted.
CCU creates backup copies of the DBCS wallet file in the directory:
$ORACLE_HOME/dbs/dbcs/<db_unique_name>/backup/<timestamp>/<wallet_file>
The name of the <timestamp> subdirectory that contains a backup copy of the DBCS wallet file is based on the time CCU is run.
Here are some sample <timestamp> subdirectory names:
A backup taken at Apr 20 10:42 will be stored in a folder 2016_04_20_10_42_53.
[oracle@slc03php ~]$ ls -lart /u01/app/oracle/product/11.2.0/dbhome_1/dbs/dbcs/ORCL800/backups/
total 188
drwxr-xr-x 2 oracle oinstall 4096 Apr 20 10:34 2016_04_20_10_34_37
drwxr-xr-x 4 oracle oinstall 4096 Apr 20 10:34 ..
drwxr-xr-x 2 oracle oinstall 4096 Apr 20 10:42 2016_04_20_10_42_53
drwxr-xr-x 2 oracle oinstall 4096 Apr 20 10:48 2016_04_20_10_48_47
drwxr-xr-x 2 oracle oinstall 4096 Apr 20 10:52 2016_04_20_10_52_54
drwxr-xr-x 2 oracle oinstall 4096 Apr 20 11:43 2016_04_20_11_43_18
drwxr-xr-x 2 oracle oinstall 4096 Apr 20 11:44 2016_04_20_11_44_03
drwxr-xr-x 2 oracle oinstall 4096 Apr 20 11:44 2016_04_20_11_44_38
The Certificate Renewal Utility (CRU) updates weblogic and OWSM self signed certificates.
The utility details are explained in the following sections:
CRU updates and replaces old self-signed certificates with new self-signed certificates. WLS certificates will be updated with 10 years validity (configurable) and OWSM certificates are updated with 5 years validity by default. The utility updates the following keystores/certificates:
OWSM self signed certificate under KSS (Key Store Service).
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
or APPLICATIONS_CONFIG/keystores
.
In a multi-host environment, there are as many host
_fusion_identity
.jks
files as there are hosts.
CRU is located at:
(UNIX) APPLICATIONS_BASE/fusionapps/applications/lcm/facertsutil
CRU uses the properties file located at:
(UNIX)
APPLICATIONS_BASE/fusionapps/applications/lcm/facertsutil/config/crutil.properties
CRU logs can be located at:
APPLICATIONS_BASE/instance/lcm/logs/certsutil/
Before using CRU for fa/weblogic certificates, proceed as follows:
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
or
(UNIX) WL_HOME/server/lib
Run keytool
to check the validity of current certificates in the keystore as illustrated in the following sample invocation:
keytool -list -keystore fusion_trust.jks -alias fa-internal.example.com_fusion -v
keytool
will request the store password.
Ensure that the properties file is configured with the correct paths required during utility execution.
Here is an example of a properties file:
# For all the paths append _path as suffix so that the validation # will be done at the time of loading the properties # Best practice to use '/' as path separator # fusion trust, cwallet_sso and *_fusion identity keystore locations # Old path #wlks_path=/scratch/aime/work/APPTOP/fusionapps/wlserver_10.3/server/lib # New path with flex clone changes wlks_path=%appnconfig_path%/keystores # Instance specific files FUSION_env and FUSION_prov properties files # Old path #fusion_props_path=/scratch/aime/work/APPTOP/fusionapps/applications/admin # New path with flex clone changes fusion_props_path=%appnconfig_path%/fapatch # path to get list of all domains configured on different hosts # for default and owc_discussions keystore files domainks_domains_path=%appnconfig_path%/domains domainks_nm_path=%appnconfig_path%/nodemanager # Certificate validity period configured for 10 years by default. # This value can be changed as per the renewal requirement validity_period=3650 # location of faInst.loc file fainst_loc_path=%appbase%/fusionapps/faInst.loc # 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=%appnconfig_path%/lcm/admin/certsutil/ # hosts for which nodemanager.domains do not exist # delimiter is ':' skip_hosts_for_nm=appohs.oracleoutsourcing.com # Domains for which domain certs do not exist # delimiter is ':' skip_domains_for_domain_certs=OSNDomain # This is the host from which we consider default_keystore.jks # Note: It is just a standard to always pick default_keystore.jks from admin host # This is optional and can be left empty if no standard host should be considered for default keystore admin_host=
Note the following points:
appbase
and appconfig_path
are variables used to replace the actual paths implicitly.
Paths can be hard coded explicitly if they do not match the requirement.
(UNIX) APPLICATIONS_BASE/fusionapps/applications/lcm/facertsutil/bin
JAVA_HOME
environment variable to:
(UNIX) APPLICATIONS_BASE/fusionapps/jdk6
(UNIX) ./facertsutil.sh -inputfile path_to_properties_file -appbase APPLICATIONS_BASE
./facertsutil.sh -inputfile ../config/crutil.properties -appbase APPLICATIONS_BASE
fusion_trust.jks
, either:
(UNIX) APPLICATIONS_CONFIG/keystores
or
(UNIX) 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 request 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.
For Rel10 or newer, run the Certifcate Renewal Utility for OWSM certificate renewal (notice the extra paramter -owsm true):
Navigate to: (UNIX) APPLICATIONS_BASE/fusionapps/applications/lcm/facertsutil/bin
Set the JAVA_HOME
environment variable to: (UNIX) APPLICATIONS_BASE/fusionapps/jdk6
Run the certificate renewal utility using one of the following syntax: (UNIX) ./facertsutil.sh -inputfile path_to_properties_file -appbase APPLICATIONS_BASE
-owsm true
./facertsutil.sh -inputfile ../config/crutil.properties -appbase APPLICATIONS_BASE
-owsm true
Use the following WLST commands to verify the validity period of OWSM certificates in the key store service (KSS):
Invoke WLST: APPLICATIONS_BASE/fusionapps/oracle_common/common/bin/wlst.sh
connect("FAAdmin", FAAdminPassword, "t3 ://<fa admin host>:<fa admin port>")
svc=getOpssService(name='KeyStoreService')
svc.getKeyStoreCertificates(appStripe='owsm', name='keystore', password='', alias='orakey', keypassword='')
svc.listExpiringCertificates(days=xxxx,autorenew=false)