7 Life Cycle of Security Artifacts

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:

• How Security Artifacts Are Seeded

• About Fusion Middleware Domains

• Creating Fusion Middleware Domains

• Layered Component Security Artifacts

• Backing Up and Recovering the Security Store

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.

See also:

Layered Component Security Artifacts

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.

• 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

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

• Sharing a Database Instance

Using a New Database Instance

To create or expand Fusion Middleware domains associated with a new database:

1. Create a new database schema. For information about database-based security stores, see Prerequisites to Using the Database Security Store.
2. 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.

See also:

Template Tools in Domain Template Reference

About Fusion Middleware Domains

Sharing a Database Instance

The following procedure uses WLST commands only. To create an expanded Fusion Middleware domain associated with a domain database:

1. 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)
   

2. 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('password')
   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 the setSharedSecretStoreWithPassword command, use the same values for location and password that you used in the exportEncryptionKey command in step 1.

3. 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 like domain1. To do so, delete the lines starting with setSharedSecretStoreWithPassword from the script.

• Be sure to backup the encryption key for the domain using the exportEncryptionKey WLST command and keep it in a secure location in case the domain fails and needs to be recreated.

See also:

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
component-security-info.xml	Required. Specifies the life cycle of security artifacts.	./security/component-security-info.xml
jazn-data.xml	Optional. Specifies 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 data.	./security/audit/component_events.xml
component_events_xlf.jar	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.

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:

• Configuration Files for Back Up

• Backing Up and Recovering a Database-Based Security Store

• Backing Up and Recovering LDAP Security Stores

• Recommendations

Note:

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.

See also:

Administering Oracle Fusion Middleware

• Performing a Backup

• Recovering an Oracle WebLogic Server Domain

Migrating Identities

Migrating Policies and Credentials

Migrating Audit Data

Migrating Keys and Certificates with migrateSecurityStore

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 ORACLE_HOME/user_projects/domains/domain_name.

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:

1. Set up the testdb database on host B:

   1. Create the inittestdb.ora file to contain the following lines:

      # 
      db_name=testdb
      #
      

   2. Add testdb to the listener.ora file:

      SID_LIST_LISTENER = (SID_LIST=(SID_DESC=(SID_NAME=testdb)(GLOBAL_DBNAME=testdb)(ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1))

   3. 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)))

   4. Restart the listener:

      lsnrctl stop, lsnrctl start

   5. 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

2. Use RMAN to clone the proddb database to the testdb database:

   1. 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)))

   2. 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.

   3. Restart the listener:

      lsnrctl stop, lsnrctl start

   4. 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.

3. Verify that the testdb database works as expected by switching your domain to use the backed up database as the security store:

   1. Stop WebLogic Server.

   2. Change the jdbc URL from proddb to testdb in the {domain}/config/fmwconfig/jps-config.xml, {domain}/config/fmwconfig/jps-config-jse.xml, and {domain}/config/jdbc/*xml files.

   3. Restart WebLogic Server.

   4. 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.

1. 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 node to the srcOid.ldif file.

   Move this file to the target LDAP system.

   The Oracle Internet Directory Database Password Utility is prompted to complete the ldifwrite command.

2. In the target LDAP system, ensure that the schema has been seeded.
3. In the target LDAP system, verify that there are no schema errors or bad entries by running bulkload:

   >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.

4. Load data into the target LDAP, by running bulkload:

   >bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
   

See also:

Administrator's Guide for Oracle Internet Directory:

• Dumping Data from Oracle Internet Directory to a File by Using ldifwrite

• Migrating LDAP Data Using LDIF File and Bulk Loader

Recommendations

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 rolloverEncryptionKey WLST command.

• 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.