This chapter explains the security artifacts that can be seeded in the security store when you create or extend a WebLogic Server domain. It also describes how to backup and recover security stores.
This chapter includes the following sections:
Note:Procedures for upgrading security artifacts from earlier releases to 12.2.1.x and for upgrading a shared security store are described in Securing Datastores in Planning an Upgrade of Oracle Fusion Middleware.
How Security Artifacts Are Seeded
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.
About Fusion Middleware Domains
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.
cwallet.ssobootstrap 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.
Creating Fusion Middleware Domains
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:
Using a New Database Instance
To create or expand Fusion Middleware domains associated with a new database:
- Create a new database schema. For information about database-based security stores, see Prerequisites to Using the Database Security Store.
- Use the Fusion Middleware Configuration Wizard to create or expand a domain, as explained in Creating a WebLogic Domain in 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.
Sharing a Database Instance
The following procedure uses WLST commands only. To create an expanded Fusion Middleware domain associated with a domain database:
- Assuming that
db1database (to which other domains want to join), use the
exportEncryptionKeycommand to export the encrypt key from
domain1to a specified location:
- Create a script similar to the following that will create a domain that shares the
## 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,"Expanded") cd('/Security/base_domain/User/weblogic') cmo.setName('weblogic') cmo.setPassword('password') writeDomain(sys.argv) closeTemplate() #Set AdminServer Port readDomain(sys.argv) cd('/Servers/AdminServer') set('ListenAddress','') set('ListenPort', int(sys.argv)) updateDomain() closeDomain() readDomain(sys.argv) addTemplate(sys.argv) 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+':'+sys.argv+'/'+sys.argv) set('UsePasswordIndirection', 'false') set('UseXADataSourceInterface', 'false') create('myProps','Properties') cd('Properties/NO_NAME_0/Property/user') cmo.setValue(sys.argv) getDatabaseDefaults() setSharedSecretStoreWithPassword(location, password) updateDomain()
setSharedSecretStoreWithPasswordcommand, use the same values for
passwordthat you used in the
exportEncryptionKeycommand in step 1.
- Start all the servers in
domain1and in the new domain. Both domains now share the same security store.
You can also use this script to create other Fusion Middleware domains like
domain1. To do so, delete the lines starting with
setSharedSecretStoreWithPasswordfrom the script.
Be sure to backup the encryption key for the domain using the
exportEncryptionKeyWLST command and keep it in a secure location in case the domain fails and needs to be recreated.
exportEncryptionKey in WLST Command Reference for Infrastructure Security
Layered Component Security Artifacts
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.
Optional. Specifies policies.
Optional. Specifies the keystore metadata.
Optional. Specifies the credential metadata used by the component.
Optional. Specifies the audit data.
Optional. Specifies the localized audit data.
OPSS security artifacts bundled with a product template require the
component-security-info.xml file that indicates how artifacts are handled.
Backing Up and Recovering the Security Store
This section describes how to back up and recover the security store.
This section contains the following topics:
You can use the
migrateSecurityStore 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.
Configuration Files for Backup
In addition to backing up the security store, you must also back up the following configuration and data files:
DOMAIN_HOME/config/config.xml DOMAIN_HOME/config/fmwconfig/jps-config.xml DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml DOMAIN_HOME/config/fmwconfig/cwallet.sso DOMAIN_HOME/config/fmwconfig/keystores.cml DOMAIN_HOME/config/fmwconfig/audit-store.xml DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml DOMAIN_HOME/config/fmwconfig/ids-config.xml DOMAIN_HOME/config/fmwconfig/mbeans/jps_mbeans.xml DOMAIN_HOME/config/fmwconfig/bootstrap/cwallet.sso
In these path names, DOMAIN_HOME represents the directory in which you created your domain. The default domain home location is
Backing Up and Recovering a Database-Based Security Store
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 database-based security store on host A to a database-based 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 database-based security store on host B.
To back up the database-based security store:
Set up the
testdbdatabase on host B:
inittestdb.orafile to contain the following lines:
# db_name=testdb #
SID_LIST_LISTENER = (SID_LIST=(SID_DESC=(SID_NAME=testdb)(GLOBAL_DBNAME=testdb)(ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1))
Restart the listener:
lsnrctl stop, lsnrctl start
Start the new instance using the
pfilefile in the
$ export ORACLE_SID=testdb
$ sqlplus / as sysdba
SYS@testdb SQL>startup nomount pfile=/scratch/rdbms/dbs/inittestdb.ora
Use RMAN to clone the
proddbdatabase to the
Make sure that the
proddbdatabase is using the
spfilefile. If it is not, then generate a binary
initfile by login in as the
sysdbauser 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
proddbdatabase the files on host A are in the directory
/oradata/proddb, and you want to saved them in the
/oradata/testdbdirectory on host B, then you would specify
/proddb, /testdb, as in the sequence below.
Run RMAN to clone the
proddbdatabase to the
$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
testdbdatabase works as expected by switching your domain to use the backed up database as the security store:
Stop WebLogic Server.
Restart WebLogic Server.
Ensure that the domain security works as expected.
Backing Up and Recovering LDAP Security Stores
LDAP security store is not recommended for 12c release. It may be used in environments upgraded from 11g.
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 connect="srcOidDbConnectStr" basedn="cn=jpsnode" ldiffile="srcOid.ldif"
This command writes all entries under the
cn=jpsnodenode to the
Move this file to the target LDAP system.
The Oracle Internet Directory Database Password Utility is prompted to complete the ldifwrite command.
- 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 connect="dstOidDbConne ctStr" 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.
The Oracle Internet Directory Database Password Utility is prompted to complete the bulkload command.
- Load data into the target LDAP, by running
>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
Administering Oracle Internet Directory:
Oracle recommends that you back up the security store and the configuration files periodically, and when any of the following events occurs:
After first install.
Before and after an upgrade.
Any time you run the
After you create new security data such as policies, credentials, or keys and keystores.
For more information on the configuration files, see Configuration Files for Backup.