7 Lifecycle of Security Artifacts

7.3.1 Using a New Database Instance

To create or expand a FMW domain associated with a brand new database, proceed as follows:

1. Create a new database schema. For details, see Section 9.3.1, "Prerequisites to Using a DB-Based Security Store."

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

7.3.2 Sharing a Database Instance

To create an expanded FMW domain to be associated with an existing database in a domain, proceed as follows:

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

2. Use a WLST script like the following to create an expanded FMW domain, which is to share the database db1:

   ## 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()
   

   where location and password have the same values as those used in the call to exportEncryptionKey. For syntax details, see Oracle Fusion Middleware Infrastructure Security WLST Command Reference.

3. Start all servers in domain1 and in the domain just created with the WLST script. Both domains share the same security store.

7.5.1 Before Upgrading

Before upgrading the OPSS security store, back it up so that it can be recovered in case the upgrade fails. For details about backing up the security store, see Backing Up and Recovering the OPSS Security Store.

The upgrade procedure varies depending on the type of security store you start from. The security store to be upgraded can be file-, OID-, or DB-based. Note the procedures below vary according to the type of source audit data store (file- or DB-based).

• Upgrading a DB-Based Security Store

• Upgrading an OID-Based Security Store

• Upgrading a Shared Security Store

• Upgrading a File-Based Security Store

7.5.2 Upgrading a DB-Based Security Store

To upgrade a DB-based security store from 11.1.1.6, or 11.1.1.7, or 12.1.2 to 12.1.3, proceed as follows:

1. Run Oracle Fusion Middleware Upgrade Assistant to upgrade the OPSS schema and, if the source audit data store is DB-based, to upgrade the audit 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.

2. If you are upgrading from 12.1.2, skip this step and continue to step 3; otherwise, run the Repository Creation Utility (RCU) to create just the service table schema. For details about RCU, see Creating Schemas with the Repository Creation Utility.

3. If the source audit data store is file-based, run RCU to create an audit schema.

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

5. If the source audit data store is file-based, an audit data source must exist. For details, see Section 14.2.2.

OPSS supports Edition-Based Redefinition (EBR). For details about setting the default edition before using OPSS, see the procedures in the following sections:

• Section 2.7.5, in Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware.

• Section 1.6.3, in Oracle Fusion Middleware Upgrading with the Upgrade Assistant.

For complete details about upgrading Oracle Fusion Middleware, see Oracle Fusion Middleware Planning an Upgrade of Oracle Fusion Middleware.

7.5.3 Upgrading an OID-Based Security Store

To upgrade an OID-based security store from 11.1.1.6, or 11.1.1.7, or 12.1.2 to 12.1.3, proceed as follows:

1. Run Oracle Fusion Middleware Upgrade Assistant to upgrade the OPSS schema and, if the source audit data store is DB-based, to upgrade the audit 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.

2. Run the Repository Creation Utility (RCU) to create the OPSS schema. The details of this schema are automatically inserted in the Database Configuration Type page. (If the audit schema is not present, it is also created in this step.) For details about RCU, see Creating Schemas with the Repository Creation Utility.

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

4. If the source audit data store is file-based, an audit data source must exist. For details, see Section 14.2.2, "About Audit Data Sources."

7.5.4 Upgrading a Shared Security Store

This section explains the extra steps necessary to upgrade a security store shared (joined) by several domains. The procedures below vary according to the version of the shared the security store.

Before upgrading the OPSS security store, back it up so that it can be recover in case the upgrade fails. For details about backing up the security store, see Backing Up and Recovering the OPSS Security Store.

This section contains the following topics:

• Upgrading a Shared 12.1.2 Security Store

• Upgrading a Shared 11g Security Store

7.5.5 Upgrading a File-Based Security Store

To upgrade a file-based security store from 11.1.1.6, or 11.1.1.7, to 12.1.3, proceed as follows:

1. If the source audit data store is file-based, run RCU version 11g to create both the OPSS schema and the OPSS Audit schema. Otherwise, if the audit data store is DB-based, run RCU version 11g to create just the OPSS schema.

2. If the audit data store is file-based, the target store must have an audit data source. See Section 14.2.2.

3. Reassociate the file-based security store to a DB-based security store using the command reassociateSecurityStore; for details, see Section 10.4.1, "reassociateSecurityStore."

4. Upgrade the reassociated DB-based security store to 12.1.3 as explained in section Upgrading a DB-Based Security Store.

7.6.1 Backing Up and Recovering a DB-Based Security Store

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:

1. Prepare the instance testdb in host B, as follows:

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

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

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

   4. Restart the listener, as illustrated in the following line:

      lsnrctl stop, lsnrctl start

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

2. Use RMAN to clone proddb to testdb, as follows:

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

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

   3. Restart the listener, as illustrated in the following line:

      lsnrctl stop, lsnrctl start

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

3. (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:

   1. Stop the Oracle WebLogic Server

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

   3. Restart the Oracle WebLogic Server

   4. Ensure that the domain security works as expected

7.6.2 Backing Up and Recovering an OID-Based Security Store

To backup a source Oracle Internet Directory store to a destination Oracle Internet Directory store proceed as follows:

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

2. In the destination Oracle Internet Directory system, ensure that the JPS schema has been seeded.

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

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

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

• 37.2.1 Migrating LDAP Data by Using an LDIF File and bulkload

7.6.3 Recommendations

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