This chapter describes how applications can specify the seeding of application-specific security artifacts in the domain security store when a domain is created or extended. It also describes the procedure to upgrade to 12.1.2.
This chapter is divided into the following sections:
In 11g domains, the specification of product-specific security artifacts would typically be bundled in the application EAR file and those artifacts would be migrated to the security store at application deployment, provided the deployment descriptors were set appropriately.
In 12c domains, the bundling of product-specific security artifacts in a product template provides a way to seed those artifacts to the domain security store.
A domain created or extended using the JRF template is called an FMW domain; the template specifies the provisioning of security artifacts in the domain security store. Specifically, during creation or extension of an FMW domain, the following tasks are accomplished automatically:
Creation of OPSS security artifacts.
Creation of a bootstrap wallet seeded with an encryption key.
Creation, out-of-the-box, of a keystore service that includes:
a domain trust store
a demo CA keystore
a domain identity key store to be used by the Oracle WebLogic Server
Creation, out-of-the-box, of a trust service wired to the keystore service.
In expanded domains, in addition to the above, the following is also provided:
Configuration, out-of-the-box, of a DB-based security store.
Configuration, by default, of a DB-based audit repository.
Important Note:
The JRF template does not create managed servers. In a domain that has been created or expanded with the JRF template, all resources are targeted only to the administration server. If later on a managed server is added to the domain, you must invoke the utilityapplyJRF so that resources are targeted to the manage server too.
Therefore, in order for OPSS and audit data sources to be targeted to managed servers after reconfiguration, applyJRF needs to be run with the following format:
applyJRF('managedServer1', '<domain_dir>')
For details on component templates, see Layered Component Security Artifacts.
A production FMW domain must be an expanded domain, and an expanded domain requires a DB-based OPSS security store. This database can be a brand new database or a shared database, that is, an existing database associated with some other FMW domain. In regards to resources targeted to manage servers and the use of the utility applyJRF, see Important Note in FMW Domains.
The following sections explain how to create an FMW domain:
To create or expand an FMW domain associated with a brand new database, proceed as follows:
Create a new database schema. For details, see Section 9.3.1, "Prerequisites to Using a DB-Based Security Store."
Use the Configuration Wizard to create or expand a domain, as explained in chapter 5, Configuration Screens, in Oracle Fusion Middleware Creating WebLogic Domains Using the Configuration Wizard.
This task includes, among others, supplying information about the database schema to use, such as the one created in step 1, and selecting to use the JFR Template.
Note 1:
The database schema associated with the domain being created must be brand new and cannot be one that has been previously used.Note 2:
When the JRF Template is processed, during creation or extension of a domain, three datasources are automatically created, namely, one for the OPSS schema, another for the OPSS audit viewer schema, and another for the OPSS audit append schema. For more information about other features of the JRF Template, see FMW Domains.For details about all the tools to use create, extend, or upgrade a domain, see section Template Tools in Oracle Fusion Middleware Domain Template Reference.
To create an expanded FMW domain to be associated with an existing database in a domain, proceed as follows:
Note:
In contrast with the previous procedure, which allows the use of the Configuration Wizard, the following procedure allows using WLST commands only.Assuming that the domain domain1 is using the existing database db1, (to which other domains want to joint) use the WLST Offline command exportEncryptionKey to export the encrypt key from domain1 to a specified location, as illustrated in the following called:
exportEncryptionKey(location, password)
For command details see Oracle Fusion Middleware Infrastructure Security WLST Command Reference.
Use WLST commands to create a new FMW domain, which is to share the database db1; the script used in this case is similar to the script used to create an expanded domain, except that it must include the following line:
setSharedSecretStoreWithPassword(location, password)
where location and password have the same values as those used in the call to exportEncryptionKey. The placing of the call above within the script is just before the call to updateDomain. For command syntax details, see Oracle Fusion Middleware Infrastructure Security WLST Command Reference.
To streamline the seeding and processing of security artifacts, components consuming OPSS need to provide a template during domain creation or extension. This template defines and bundles artifacts specific to just a component that are require for the component's execution, and includes the files listed in Table 7-1.
Table 7-1 Files in a Component Template Used by OPSS
| File name | Description | Location relative to the template root folder |
|---|---|---|
|
component-security-info.xml |
Required. Specifies the lifecycle of security artifacts. |
./security/component-security-info.xml |
|
jazn-data.xml |
Optional. Specifies authorization policies. |
./security/authorization/jazn-data.xml |
|
keystore.xml |
Optional. Specifies the keystore metadata. |
./security/keystore/keystore.xml |
|
credentials.xml |
Optional. Specifies the credential metadata used by the component. |
./security/credential/credentials.xml |
|
component_events.xml |
Optional. Specifies the audit metadata. |
./security/audit/component_events.xml |
|
component_events_xlf.jar |
Optional. Specifies the localized audit metadata. |
./security/audit/component_events_xlf.jar |
Note:
OPSS security artifacts bundled with a product template, require acomponent-security-info.xml file to indicate how artifacts are handled.This section explains the procedure to upgrade security artifacts from release 11.1.1.6 or 11.1.1.7 to release 12.1.2.
Upgrading OPSS to 12.1.2 involves:
Use of Oracle Fusion Middleware Upgrade Assistant to upgrade the OPSS schema (upgrades the OPSS security store schema and the audit schema).
Use of the Reconfiguration Wizard to:
Upgrade the Policy Store Directory Information Tree, where the policy store data is stored.
Upgrade data in the OPSS security store.
Upgrade configuration of services in the files jps-config.xml and jps-config-jse.xml. If the OPSS security store is DB-based, it also sets the audit log repository to be DB-based.
If the OPSS security store to be upgraded is LDAP- or DB-based, then make sure to back it up so that it can be used for recovery in case the upgrade fails. For details, see Backing Up and Recovering the OPSS Security Store.
To upgrade an OID-based or DB-based OPSS security store from 11.1.1.6 or 11.1.1.7 to 12.1.2, proceed as follows:
Run Oracle Fusion Middleware Upgrade Assistant to upgrade the OPSS schema. In the Available Components page, be sure to select Oracle Platform Security Services. For details about Upgrade Assistant, see Oracle Fusion Middleware Upgrading with the Upgrade Assistant.
Run the Repository Creation Utility (RCU) to create just the service table schema. The details of this table are automatically inserted in the Database Configuration Type page. For details about RCU, see Creating Schemas with the Repository Creation Utility.
Run the Reconfiguration Wizard to effect the domain reconfiguration and to upgrade OPSS data, DIT, configuration and product security artifacts.
Note the following points about this step:
In the Database Configuration Type page, select RCU Data and enter the service table schema created in step 2, and then click Get RCU Configuration.
In the Component Datasources page, select the following components and enter the schema details:
OPSS Audit Schema - IAU_APPEND
OPSS Audit Viewer - IAU_VIEWER
OPSS Schema - OPSS
Product reconfiguration templates are automatically selected and processed. For details about templates, see Section 7.4, "Layered Component Security Artifacts."
If, and only if, you are upgrading from a 11.1.1.6 domain, then copy the 11g JAR file ${common.components.home}/modules/oracle.jps_11.1.1/jps-wls-trustprovider.jar to ${domain.home}/lib/mbeantypes in the upgraded domain.
Note:
Joining from a 12c expanded domain to a 12c-upgraded domain is not supported.For complete details about upgrading Oracle Fusion Middleware, see Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware.
To upgrade a file-based OPSS security store from 11.1.1.6 or 11.1.1.7 to 12.1.2, proceed as follows:
Reassociate the file-based security store to an OID-based or DB-based security store using the command reassociateSecurityStore; for details, see Section 10.3.1, "reassociateSecurityStore."
Upgrade the reassociated (OID-based or DB-based) security store to 12.1.2 as explained in the procedure above.
This section describes how to backup and recover a domain's OPSS security store. The procedure varies according to the type of OPSS store to process (DB-based or OID-based).
In addition to backing up the security store, note that the following security store configuration and data files must also be saved for a possible recovery (a star stands for all files in the directory):
{domain}/Config/config.xml
{domain}/Config/Fmwconfig/jps-config.xml
{domain}/Config/Fmwconfig/jps-config-jse.xml
{domain}/Config/Fmwconfig/cwallet.sso
{domain}/Config/Fmwconfig/keystores.cml
{domain}/Config/Fmwconfig/audit-store.xml
{domain}/Config/Fmwconfig/system-jazn-data.xml
{domain}/Config/Fmwconfig/ids-config.xml
{domain}/Config/Fmwconfig/mbeans/jps_mbeans.xml
{domain}/Config/Fmwconfig/bootstrap/cwallet.sso
The above files are typically backed up as part of an Oracle WebLogic Server domain backup. For details about an Oracle WebLogic domain backup, see the following topics in the Administering Oracle Fusion Middleware:
This section contains the following topics:
The procedure described in this section uses the Oracle Database client Recovery Manager (RMAN) that allows active database duplication, a tool that is typically also used to automate backup strategies and recoveries. For full details about RMAN, see the following topics in the Oracle Database Backup and Recovery User's Guide:
Getting Started with RMAN
Performing Complete Database Recovery
The following procedure describes how to backup a domain DB-based security store instance in host A to an instance in host B; it assumes that the security store in host A has a jdbc url set to proddb, and the goal is to get that same domain to work with a (cloned) DB-based store with jdbc url set to testdb (in host B).
Under the above assumptions, to backup a DB-based security store, proceed as follows:
Prepare the instance testdb in host B, as follows:
Create a pfile for the new instance: that is, create the file inittestdb.ora with a contents as illustrated be the following lines:
# db_name=testdb #
Add testdb to listener.ora, as illustrated in the following line:
SID_LIST_LISTENER = (SID_LIST=(SID_DESC=(SID_NAME=testdb)(GLOBAL_DBNAME=testdb)(ORACLE_HOME=/ade/b/3882746433/oracle))
Add testdb/proddb in tnsnames.ora, as illustrated in the following lines:
proddb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostA.com)(PORT=XXXX))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME= proddb)))
testdb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostB.com)(PORT=YYYY))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=testdb)))
Restart the listener, as illustrated in the following line:
lsnrctl stop, lsnrctl start
Start the new instance using the pfile in nomount mode, as illustrated in the following lines:
$ export ORACLE_SID=testdb
$ sqlplus / as sysdba
SYS@testdb SQL>startup nomount pfile=/scratch/rdbms/dbs/inittestdb.ora
Use RMAN to clone proddb to testdb, as follows:
Add add testdb/proddb in tnsnames.ora, as illustrated in the following lines:
proddb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhostA.com)(PORT=XXXX))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME= proddb)))
testdb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhostB.com)(PORT=YYYY))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=testdb)))
Make sure that instance proddb is using the spfile. If this is not yet the case, generate a binary spfile from the init file by login in as sysdba and running "create spfile from pfile". Then, restart the server.
Restart the listener, as illustrated in the following line:
lsnrctl stop, lsnrctl start
Decide how to generate the names for the duplicate database files; specifically, decide how to name the control files, the datafiles, the online redo log files, and the tempfiles.
For example, if in proddb, the files on host A are in the directory /oradata/proddb, and you want the them to be saved in /oradata/testdb on host B, then you would specify DB_FILE_NAME_CONVERT '/proddb',' /testdb', as in the sequence below.
Run RMAN to clone proddb to testdb as illustrated in the following lines:
$rman
RMAN> CONNECT TARGET SYS@proddb
RMAN> CONNECT AUXILIARY SYS@testdb
RMAN> DUPLICATE TARGET DATABASE TO testdb
FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT '/proddb','/testdb'
SPFILE
PARAMETER_VALUE_CONVERT '/proddb','/testdb'
SET LOG_FILE_NAME_CONVERT '/proddb','/testdb';
Make sure that the RMAN sequence above completes successfully.
(Optional) Verify the backed up DB instance testdb works as expected, by switching your domain to use the just backed up database as the OPSS security store:
Stop the Oracle WebLogic Server
Change the jdbc url from proddb to testdb in the files {domain}/config/fmwconfig/jps-config.xml and {domain}/config/jdbc/*xml
Restart the Oracle WebLogic Server
Ensure that the domain security works as expected
To backup a source Oracle Internet Directory store to a destination Oracle Internet Directory store proceed as follows:
In the system where the source Oracle Internet Directory is located, produce an LDIF file by running ldifwrite as illustrated in the following line:
>ldifwrite connect="srcOidDbConnectStr" basedn="cn=jpsnode" ldiffile="srcOid.ldif"
This command writes all entries under the node cn=jpsnode, c=us to the file srcOid.ldif. Then move this file to the destination Oracle Internet Directory file system so it is available to the commands that follow.
In the destination Oracle Internet Directory system, ensure that the JPS schema has been seeded.
In the destination Oracle Internet Directory system, verify that there are no schema errors or bad entries by running bulkload as illustrated in the following line:
>bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"
If duplicated DNs (common entries between the source and the destination directories) are detected, review them to prevent unexpected results.
Load data into the destination Oracle Internet Directory, by running bulkload as illustrated in the following line:
>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
For more details about the above commands, see the following topics in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory:
It is recommended that the OPSS security store be backed up periodically, according to a schedule appropriate to your enterprise. In addition, an unscheduled backup is recommended soon after the following events:
a new encryption key has been (automatically) generated for the domain
new policies have been created
new binding credentials are set