Fusion Middleware Documentation
Advanced Search


Securing Applications with Oracle Platform Security Services
Close Window

Table of Contents

Show All | Collapse

7 Lifecycle of Security Artifacts

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:

7.1 Introduction

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.

7.2 FMW Domains

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

7.3 Creating an FMW Domain

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:

7.3.1 Using a New Database Instance

To create or expand an 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:

Note:

In contrast with the previous procedure, which allows the use of the Configuration Wizard, the following procedure allows using WLST commands only.

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

7.4 Layered Component Security Artifacts

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 a component-security-info.xml file to indicate how artifacts are handled.

7.5 Upgrading to 12.1.2

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.

7.5.1 Before Upgrading

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.

7.5.2 Upgrading Procedure

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:

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

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

  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

    Product reconfiguration templates are automatically selected and processed. For details about templates, see Section 7.4, "Layered Component Security Artifacts."

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

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

  2. Upgrade the reassociated (OID-based or DB-based) security store to 12.1.2 as explained in the procedure above.

7.6 Backing Up and Recovering the OPSS Security Store

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:

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:

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