This chapter explains the security artifacts that your application can specify to seed in the security store when you create or extend a WebLogic Server domain. It also includes the procedure to upgrade the security store to version 12.2.1.x.
This chapter includes the following sections:
In 11g domains, the specification of product-specific security artifacts is bundled in the application Enterprise ARchive (EAR) file and those artifacts are migrated to the security store at application deployment, provided the deployment descriptors are set appropriately.
In 12c domains, the specification of product-specific security artifacts is configured in a product template, which provides a way to seed those artifacts to the security store when the domain is created.
See also:
Fusion Middleware domains are created or extended with the Java Required Files (JRF) template. The template specifies the provisioning of artifacts in the security store. Specifically, the process creates:
OPSS security artifacts.
The cwallet.sso bootstrap file seeded with an encryption key.
Keystores, including the truststore, a demonstration keystore, and a domain identity keystore used by Oracle WebLogic Server.
A trust service wired to the truststore.
Three data sources: one for the OPSS schema, one for the OPSS audit viewer schema, and one for the OPSS audit append schema.
Configurations for database security and audit stores.
The JRF template does not create Managed Servers. In Fusion Middleware domains, all resources are targeted only to the Administration Server. If, at a later time, you add a Managed Server to the domain, then you must apply the JRF template to the target resources to that Managed Server also. To target OPSS and audit data sources to a Managed Servers after domain reconfiguration, use the applyJRF WebLogic Scripting Tool (WLST) command.
See also:
Layered Component Security Artifacts
applyJRF in WLST Command Reference for Infrastructure Components
Production Fusion Middleware domains require database security stores. The database can be a new database or a database associated with some other Fusion Middleware domain.
The following sections explain how to create Fusion Middleware domains:
To create or expand Fusion Middleware domains associated with a new database:
Create a new database schema. For information about DB security stores, see Section 9.3.1, "Prerequisites to Using the DB Security Store".
Use the Fusion Middleware Configuration Wizard to create or expand a domain, as explained in "Creating a WebLogic Domain" in Oracle Fusion Middleware Creating WebLogic Domains Using the Configuration Wizard.
This task includes supplying information about the database schema to use, such as the one created in step 1, and choosing to use the JRF Template. The database schema associated with the domain you create must be a new schema.
When you use the JRF template, three data sources are automatically created: one for the OPSS schema, one for the OPSS audit viewer schema, and one for the OPSS audit append schema.
The following procedure uses WLST commands only. To create an expanded Fusion Middleware domain associated with a domain database:
Assuming that domain1 uses the db1 database (to which other domains want to join), use the exportEncryptionKey command to export the encrypt key from domain1 to a specified location:
exportEncryptionKey(location, password)
Create a script similar to the following that will create a domain that shares the db1 database:
## arg1 - wls.jar loc
## arg2 - jrf.jar loc
## arg3 - domain home
## arg4 - adminserver port
## arg5 - Db host
## arg6 - db port
## arg 7 - DB service name (pdb)
## arg8 - STB schema user,
readTemplate(sys.argv[1],"Expanded")
cd('/Security/base_domain/User/weblogic')
cmo.setName('weblogic')
cmo.setPassword('welcome1')
writeDomain(sys.argv[3])
closeTemplate()
#Set AdminServer Port
readDomain(sys.argv[3])
cd('/Servers/AdminServer')
set('ListenAddress','')
set('ListenPort', int(sys.argv[4]))
updateDomain()
closeDomain()
readDomain(sys.argv[3])
addTemplate(sys.argv[2])
cd('/JDBCSystemResource/LocalSvcTblDataSource/JdbcResource/LocalSvcTblDataSource')
cd('JDBCDriverParams/NO_NAME_0')
set('DriverName','oracle.jdbc.OracleDriver')
set('PasswordEncrypted', 'myPassw')
set('URL','jdbc:oracle:thin:@'+sys.argv[5]+':'+sys.argv[6]+'/'+sys.argv[7])
set('UsePasswordIndirection', 'false')
set('UseXADataSourceInterface', 'false')
create('myProps','Properties')
cd('Properties/NO_NAME_0/Property/user')
cmo.setValue(sys.argv[8])
getDatabaseDefaults()
setSharedSecretStoreWithPassword(location, password)
updateDomain()
Note:
In thesetSharedSecretStoreWithPassword command, use the same values for location and password that you used in the exportEncryptionKey command in step 1.Run the script that you created in step 2 to start all the servers in domain1 and in the new domain. Both domains now share the same security store.
Note:
You can also use this script to create other Fusion Middleware domains likedomain1. To do so, delete the lines starting with setSharedSecretStoreWithPassword from the script.See also:
exportEncryptionKey in Infrastructure Security WLST Command Reference
To streamline the seeding and processing of security artifacts, components consuming OPSS must provide a template during domain creation or extension. This template defines and bundles artifacts specific to just the components that are required 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 |
|---|---|---|
|
|
Required. Specifies the life cycle of security artifacts. |
./security/component-security-info.xml |
|
|
Optional. Specifies policies. |
./security/authorization/jazn-data.xml |
|
|
Optional. Specifies the keystore metadata. |
./security/keystore/keystore.xml |
|
|
Optional. Specifies the credential metadata used by the component. |
./security/credential/credentials.xml |
|
|
Optional. Specifies the audit data. |
./security/audit/component_events.xml |
|
|
Optional. Specifies the localized audit data. |
./security/audit/component_events_xlf.jar |
OPSS security artifacts bundled with a product template require the component-security-info.xml file that indicates how artifacts are handled.
The following sections explain how to upgrade security artifacts from release 11.1.1.7, 11.1.1.9, 12.1.2, or 12.1.3 to release 12.2.1.x:
An upgraded system does not use old data sources but only newly created ones. After upgrading from 11g, you may see duplicate OPSS data sources: one that existed before upgrading and another created during the upgrade process. This duplication poses no functional impact and the old data source is not used by the upgraded system.
After upgrading, consider moving the keystore from Java Keystore (JKS) to the keystore service (KSS) keystore. In domains upgraded to 12.2.1.x, KSS keystores under the system stripe differ from those in previous releases. For information about certificates, see Section 12.4, "About Certificates".
Before upgrading the security store:
Perform a readiness check on the older version of Fusion Middleware to determine if it is suitable for upgrading to version 12.2.1.x. For more information, see "About Running a Pre-Upgrade Readiness Check with the Upgrade Assistant" in Upgrading with the Upgrade Assistant.
Create a backup so that you can recover it in case the upgrade fails. For more information, see Backing Up and Recovering the Security Store.
The following tables describe the steps you take to upgrade a system according to the type of security and audit stores. All of the procedures assume that your binaries have been upgraded to 12.2.1.x Oracle Fusion Middleware binaries.
The supported databases that can be updated are listed in Section 4.1, "Supported File, LDAP, and Database Stores".
Note:
If, during the upgrade process, you perform any OPSS runtime operations on any of the servers before you restart them, you may get errors related to operations being performed against the OPSS Security store. These errors can occur if the binary and schema have been upgraded, but the server process that is being run is still using the old classes that have not been updated or refreshed. Therefore, Oracle recommends that you always restart all of the Managed Servers in the domain after the upgrade process is complete.Table 7-2 Upgrading from 12.1.2 or 12.1.3 to 12.2.1.x
| Security Store Type | Audit Store Type | To upgrade to 12.2.1.x: |
|---|---|---|
|
Oracle Internet Directory |
Database |
|
|
Database |
Database |
|
Note:
Upgrading from a 12c file security store is not supported.Table 7-3 Upgrading from 11.1.1.7 or 11.1.1.9 to 12.2.1.x
| Security Store Type | Audit Store Type | To upgrade to 12.2.1.x: |
|---|---|---|
|
File |
File |
|
|
File |
Database |
|
|
Oracle Internet Directory |
File |
|
|
Oracle Internet Directory |
Database |
|
|
Database |
File |
|
|
Database |
Database |
|
Note:
An 11g file security store is automatically upgraded to a database-based security store.Run the procedure in this section to reconfigure a domain using the Fusion Middleware Reconfiguration Wizard. For complete details about the Reconfiguration Wizard, see "Reconfiguring WebLogic Domains" in Upgrading Oracle WebLogic Server.
Note:
In some configurations, you may get an invalid key size exception when running the Reconfiguration Wizard. For more information about this exception, see Section J.10.6, "Invalid Key Size". Oracle recommends that you check your configuration before running the Reconfiguration Wizard, and if necessary, install the JCE Unlimited Strength Jurisdiction Policy Files.Start the Fusion Middleware Reconfiguration Wizard:
> cd oracle_common/common/bin > ./reconfig.sh
In the Select Domain page, specify the directory of the domain to reconfigure, and then click Next.
In the Database Configuration Type page, select RCU Data, enter the database connection details, and click Get RCU Configuration. The results of the retrieval are displayed.
Click Next.
The JDBC Component Schema page displays the table of schemas affected. Check rows as appropriate, and then click Next.
In the JDBC Component Schema Test page, click Test Selected Connections. The results of the test are displayed. Click Next.
In the Advanced Configuration page, check boxes as appropriate, and then click Next.
Additional pages are displayed depending on the options you selected.
When you have finished providing all the required information in the remaining pages, the Configuration Summary page displays the options you chose. Click Reconfigure.
To upgrade a security store shared (joined) by several domains, use one of the following tasks:
Run the procedure in this section to upgrade to 12.2.1.x from a 12.1.2 or 12.1.3 shared security store.
Shut down all domains that share the store you want to upgrade.
Run the Upgrade Assistant to upgrade the OPSS schema of the shared security store and the audit schema if the source audit data is a database store. See Upgrading with the Upgrade Assistant.
In each of the domains sharing the security store, run Fusion Middleware Reconfiguration Wizard to reconfigure the domain and to upgrade OPSS data, directory information tree, and product security artifacts. See Reconfiguring Domains with the Fusion Middleware Reconfiguration Wizard.
Restart all domains sharing the security store.
Run the procedure in this section to upgrade to 12.2.1.x from an 11.1.1.7 or 11.1.1.9 shared security store.
Shut down all domains sharing the store you want to upgrade.
Run the Upgrade Assistant to upgrade the OPSS schema of the shared security store, and the audit schema if the source audit is a database store. See Upgrading with the Upgrade Assistant.
Run the Fusion Middleware Reconfiguration Wizard in each of the domains sharing the security store. When first run, it upgrades the data of the security store and configuration of the domain. When run from any other domain, it will upgrade only the configuration of that domain. See Reconfiguring Domains with the Fusion Middleware Reconfiguration Wizard.
Restart all upgraded domains.
This section describes how to back up and recover the security store. In addition to backing up the security store, note that the following configuration and data files must also be saved:
{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
This section contains the following topics:
Note:
You can use themigrateSecurityStore WLST command to back up and recover security data. To back up security data, migrate security data to a file store. To recover it, migrate the file store to the target security store.See also:
Performing a Backup in Administering Oracle Fusion Middleware
Recovering an Oracle WebLogic Server Domain in Administering Oracle Fusion Middleware
The procedure in this section uses Oracle Database Utility Recovery Manager (RMAN), a tool used to automate backup strategies and recoveries, and to duplicate databases.
Use the following procedure to back up a DB security store on host A to a DB security store on host B. The security store on host A has the jdbc URL set to proddb, and the security store in host B has the jdbc URL set to testdb. The procedure sets the domain to work with the cloned DB security store on host B.
To back up the DB security store:
Set up the testdb database on host B:
Create the inittestdb.ora file to contain the following lines:
# db_name=testdb #
Add testdb to the listener.ora file:
SID_LIST_LISTENER = (SID_LIST=(SID_DESC=(SID_NAME=testdb)(GLOBAL_DBNAME=testdb)(ORACLE_HOME=/ade/b/3882746433/oracle))
Add testdb/proddb to the tnsnames.ora file:
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:
lsnrctl stop, lsnrctl start
Start the new instance using the pfile file in the nomount mode:
$ export ORACLE_SID=testdb
$ sqlplus / as sysdba
SYS@testdb SQL>startup nomount pfile=/scratch/rdbms/dbs/inittestdb.ora
Use RMAN to clone the proddb database to the testdb database:
Add add testdb/proddb to the tnsnames.ora file:
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 the proddb database is using the spfile file. If it is not, then generate a binary spfile from the init file by login in as the sysdba user and running create spfile from pfile. Then, restart the server.
Restart the listener:
lsnrctl stop, lsnrctl start
Decide how to generate the names for the duplicate database files. Specifically, how to name the control files, data files, online redo log files, and temporary files.
For example, if in the proddb database the files on host A are in the directory /oradata/proddb, and you want to saved them in the /oradata/testdb directory on host B, then you would specify DB_FILE_NAME_CONVERT /proddb, /testdb, as in the sequence below.
Run RMAN to clone the proddb database to the testdb database:
$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 RMAN completes with no errors.
Verify that the testdb database works as expected by switching your domain to use the backed up database as the security store:
Stop WebLogic Server.
Change the jdbc URL from proddb to testdb in the {domain}/config/fmwconfig/jps-config.xml and {domain}/config/jdbc/*xml files.
Restart WebLogic Server.
Ensure that the domain security works as expected.
Use the procedure in this section to back up a source LDAP store to a target LDAP store.
In the source LDAP system create an LDAP Data Interchange format (LDIF) file by running ldifwrite:
>ldifwrite connect="srcOidDbConnectStr" basedn="cn=jpsnode" ldiffile="srcOid.ldif"
This command writes all entries under the cn=jpsnode, c=us node to the srcOid.ldif file.
Move this file to the target LDAP system.
In the target LDAP system, ensure that the schema has been seeded.
In the target LDAP system, verify that there are no schema errors or bad entries by running bulkload:
>bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"
If duplicated distinguished names (common entries between the source and the target directories) are detected, then review them to prevent unexpected results.
Load data into the target LDAP, by running bulkload:
>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
See also:
In Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory:
Oracle recommends that you back up the security store periodically, according to a schedule appropriate to your enterprise. In addition, unscheduled backups are recommended soon after a new encryption key is (automatically) generated for the domain, and soon after you create new security data such as policies or credentials.
Components using the audit static model can upgrade the audit definitions to the audit dynamic model used in Release 12c with AuditSchemaUpgradeTool. This tool supports audit static definition files containing no more than one component definition.
Before upgrading a component, add the displayName component to the AuditConfig property in the component_events.xml file:
<AuditConfig componentType="SOA-HCFP"
xmlns="http://xmlns.oracle.com/ias/audit/audit.xsd"
displayName="Oracle SOA Suite Integration">
java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool -s source_file -t target_file_or_directory [, -v component_def_version]
where:
source_file is the audit definition file, such as component_events.xml.
target_file_or_directory is either a) the file in which the 12g definition file will be stored, or b) a target directory and the model definition file is placed in this directory with the default file name source_file_dynamic.xml.
component_def_version is the version number of the generated 12c definition. If unspecified, then it defaults to 1.0.
The following example illustrates upgrading the OPSS component definition to the Release 12c dynamic model using the default version number and the target component_events_OPSS.xml file:
java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool -s component_events.xml -t component_events_OPSS.xml
The following example illustrates upgrading the OPSS component definition to the Release 12c dynamic model with a specific version number and a target directory. The command uses the default target file name component_events_dynamic.xml:
java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool -s component_events.xml -t /scratch/example -v 2.0