1. Securing Applications with Oracle Platform Security Services
  2. OPSS Services
  3. Configuring the Security Store

9 Configuring the Security Store

The security store is the central repository of system and application-specific policies, credentials, keys, and audit data used by all applications running in a WebLogic Server domain.

This chapter includes the following sections:

Parent topic: OPSS Services

About the Security Store

The security store is the central repository of system and application-specific policies, credentials, and keys. This centralization facilitates the administration and maintenance of policies, credentials, and keys.

The type of the security store can be file, LDAP, or database. You can reassociate it from file to LDAP or database, from database to LDAP or database, or from LDAP to LDAP or database. Ready-to-use, the security store is a database store.

In Java EE applications, the security data is packaged with the application Enterprise ARchive (EAR) file, and it can be migrated to the security store when you deploy the application.

When a WebLogic Server domain uses policies from the security store, Java Authorization Contract for Containers (JACC) policies and the Java Security Manager become unavailable to all Managed Servers in that domain.

All permission classes used in policies must be included in the class path so the policy provider can load them when a service instance is initialized.

See also:

Reassociating the Security Store with Fusion Middleware Control

Reassociating the Security Store with reassociateSecurityStore

Migrating the Security Store with Fusion Middleware Control

Migrating the Security Store with migrateSecurityStore

Java EE and WebLogic Security in Understanding Security for Oracle WebLogic Server

Parent topic: Configuring the Security Store

Environments with Multiple Servers

Production WebLogic Server domains with several server instances (Administration and Managed Servers) on the same host or distributed across multiple machines, must use an LDAP or a database security store. File-based providers are not supported in production environments.

See also:

Policy Store Service Properties

Credential Service Properties

Parent topic: About the Security Store

Using an LDAP Security Store

Production environments typically use LDAP security stores. The only LDAP supported is Oracle Internet Directory.

OPSS does not support enabling referential integrity on LDAP servers. The server will not work as expected if referential integrity is enabled. To disable a server's referential integrity, use Oracle Enterprise Manager Fusion Middleware Control to:

  1. Choose first Administration, then Shared Properties, and then General.

  2. In the Enable Referential Integrity list, choose Disabled.

Note:

Depending on the version, the following Oracle Internet Directory patches are required:

  • Patch 10.1.4 to fix bug 9093298

  • Patch 11.1.x to fix bug 8736355

  • Patch 11.1.x and 10.1.4.3 to fix bug 8426457

  • Patch 10.1.4.3 to fix bug 8351672

  • Patch 10.1.4.3 to fix bug 8417224

  • Patch 11.1.1.6.0 to fix bug 13782459

For information about supported Oracle Internet Directory versions, see Oracle Fusion Middleware Supported System Configurations.

The following sections explain how to set up an LDAP security store:

See also:

Setting Up One-Way SSL to the LDAP Security Store in Administering Oracle Fusion Middleware

Properties Common to All LDAP Servers

Parent topic: Configuring the Security Store

Prerequisites to Using the LDAP Security Store

To ensure the proper access to LDAP, set a node in the server directory as explained in this section.

When you use Fusion Middleware Control to reassociate to an LDAP store, the tool automatically provides bootstrap credentials in the cwallet.sso file.

To set a node in an LDAP server:

  1. Create an LDAP Data Interchange format (LDIF) file (jpstestnode.ldif) specifying the following entries:
    dn: cn=jpsroot
cn: jpsroot
objectclass: top
objectclass: OrclContainer

    The distinguished name of the root node jpsroot must be distinct from any other distinguished name. Some LDAP servers enforce case-sensitivity by default. Multiple WebLogic Server domains can share a root node. This node need not be created at the top level, but the LDAP administrator must have read and write access to all nodes below it.

  2. Import this data into the LDAP server with the ldapadd utility:
    >ldapadd -h ldap_host -p ldap_port -D cn=orcladmin -w password -v -f  jpstestnode.ldif
  3. Verify that the node has been successfully inserted with the ldapsearch utility:
    >ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin -w password -s base 
-b "cn=jpsroot" objectclass="orclContainer"
  4. Run oidstats.sql to generate database statistics for optimal database performance:
    >$ORACLE_HOME/ldap/admin/oidstats.sql

    You need to run this utility only once after the initial provisioning.

See also:

Specifying Bootstrap Credentials Manually

About Oracle Internet Directory Database Statistics Collection Tool in Reference for Oracle Identity Management

Parent topic: Using an LDAP Security Store

Resetting the LDAP User Password

Use the procedure in this section to reset the LDAP user password.

  1. Create an LDIF file with a content that specifies the new password:
    dn: <UserDN>
changetype: modify
replace: userPassword
userPassword: new_password

    where userDN stands for the distinguished name of the administrator.

  2. Use ldapmodify to apply the specifications in the created file as in the following example, which uses specifications in the updatePassword.ldif file:
    ldapmodify -h oid_hostName -p oid_port -D “cn=orcladmin" -w orcladmin_password -f updatePassword.ldif
  3. Run modifyBootStrapCredential to update the password in the bootstrap wallet.

See also:

Parent topic: Using an LDAP Security Store

Using a Database-Based Security Store

A database-based security store is recommended in production environments. To configure the security store, use Fusion Middleware Control or WebLogic Scripting Tool (WLST). The database security store and the domain must be in the same data center.

For information about the database versions supported, see Oracle Fusion Middleware Supported System Configurations.

For information about the OPSS and audit schemas support of Edition-Based Redefinition (EBR), see Creating an Edition on the Server for Edition-Based Redefinition (Optional) in Upgrading to the Oracle Fusion Middleware Infrastructure.

The following sections explain how to set up a database security store:

Parent topic: Configuring the Security Store

Prerequisites to Using the Database Security Store

To use a database repository for the security store, first use Oracle Fusion Middleware Repository Creation Utility to create the required OPSS schema and to seed some initial data. See About the Repository Creation Utility in Creating Schemas with the Repository Creation Utility.

When using Repository Creation Utility to create the OPSS schema, choose all schemas whose names contain the following suffixes:

  • _OPSS

  • _IAU

  • _IAU_APPEND

  • _IAU_VIEWER

  • _STB

Parent topic: Using a Database-Based Security Store

Maintaining a Database Security Store

This section describes some of the tasks that you follow to maintain a database security store.

A database security store maintains a change log that should be periodically purged. To purge it, use the provided SQL opss_purge_changelog.sql script, which will purge change logs older than 24 hours, or connect to the database and run the delete utility (with the appropriate arguments): 

SQL>delete from jps_changelog where createdate < (select(max(createdate) - 1) from jps_changelog);
SQL>Commit;

To enhance performance when accessing a database security store, run the DBMS_STATS package to gather statistics about the physical storage of database tables and indexes. This information, stored in the data dictionary, is then used to optimize the execution plan for SQL statements accessing analyzed objects.

When loading large amount of data into a database security store, such as when creating thousands of new application roles, it is recommended that your run DBMS_STATS within short periods and concurrently with the loading activity. Otherwise, when the loading activity is small, then run DBMS_STATS just once or according to your needs.

The following example illustrates the use of DBMS_STATS: 

EXEC DBMS_STATS.GATHER_SCHEMA_STATS('DEV_OPSS', DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);

where DEV_OPSS denotes the name of the database schema created with Repository Creation Utility.

Script Examples

The following example runs the DBMS_STATS command every 10 minutes: 

#!/bin/sh
i=1
while [ $i -le 1000 ]
do
echo $i
sqlplus dev_opss/password@inst1 @opssstats.sql
sleep 600
i=`expr $i + 1`
done

where opssstats.sql contains the following text: 

EXEC DBMS_STATS.gather_schema_stats('DEV_OPSS',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);
QUIT;

The following example also runs DBMS_STATS every 10 minutes: 

variable jobno number;
BEGIN
DBMS_JOB.submit
(job => :jobno,
what => 'DBMS_STATS.gather_schema_stats(''DEV_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE,no_invalidate=>FALSE);',
interval => 'SYSDATE+(10/24/60)');
COMMIT;
END;
/

To stop the DBMS_STATS started by this SQL script, first find out its job number by issuing the following commands: 

sqlplus '/as sysdba'
SELECT job FROM dba_jobs WHERE schema_user = 'DEV_OPSS' AND what = 'DBMS_STATS.gather_schema_stats(''DEV_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);';

Then run a command like the following (which assumes that the query returned the job number 31):

EXEC DBMS_JOB.remove(31);

Parent topic: Using a Database-Based Security Store

Resetting the OPSS Schema Password

To reset the OPSS schema password:

  1. Use the database ALTER USER command to reset the password in the database. Remember the new password entered, as it will be used in the next two steps.
  2. Use Oracle WebLogic Server Administration Console to update the password that the data source uses to connect to the OPSS schema with the new password.
  3. Use the modifyBootStrapCredential WLST command to update the cwallet.sso bootstrap file with the new password.

See also:

Creating a JDBC Data Source in Administering JDBC Data Sources for Oracle WebLogic Server

modifyBootStrapCredential in WLST Command Reference for Infrastructure Security

Parent topic: Using a Database-Based Security Store

Setting Up an SSL Connection to the Database Security Store

Establishing a one- or two-way SSL connection to a database security store is optional and explained in section Configuring SSL for the Database in Administering Oracle Fusion Middleware.

Parent topic: Using a Database-Based Security Store

Reassociating the Security Store

Reassociating the security store is the process that relocates security data from one repository to another one. The source type can be file, LDAP, or database. The target type can be LDAP or database.

Reassociation changes the repository while preserving the integrity of the data stored. This operation can take place at any time after the domain has been created, and it is carried out with either Fusion Middleware Control or the reassociateSecurityStore WLST command as explained in the following sections:

Parent topic: Configuring the Security Store

Reassociating the Security Store with Fusion Middleware Control

Reassociation migrates the security store (policies, credentials, keys, and audit data) from one repository to another and reconfigures security providers. For information about the procedure, see Task 2, Migrating the Security Store.

Note the following points:

  • Before reassociating to a target LDAP store, ensure that your setup satisfies the Prerequisites to Using the LDAP Security Store.

  • Before reassociating to a target database store, ensure that your setup satisfies the Prerequisites to Using the Database Security Store.

  • Before reassociating and if a one-way SSL to a target LDAP is required, then follow the instructions in Setting Up One-Way SSL to the LDAP Security Store in Administering Oracle Fusion Middleware.

  • After reassociating to an LDAP store, to secure access to the root node of the LDAP store, follow the instructions in Securing Access to LDAP Nodes.

  • Reassociation updates the jps-config.xml and jps-config-jse.xml files with the new configuration: it deletes old provider configuration, inserts the new provider configuration, and moves data from the source to the target store.

  • If the target store is LDAP, then the information is stored under the domain distinguished name according to the following format:

    cn=<domain_name>,cn=JpsContext,<JPS ROOT DN>

    If your configuration relies on the domain distinguished name, then do not delete this node from the LDAP Server.

Parent topic: Reassociating the Security Store

Securing Access to LDAP Nodes

The procedure explained in this section is optional and performed only to enhance the security to access LDAP servers.

An access control list (ACL) is a list that specifies who can access information and what operations are allowed on the LDAP objects. The control list is specified at a node, and its restrictions apply to all entries under that node.

Use ACL to control the access to data stored in an LDAP repository. Typically, you specify this list at the root node of the store.

To specify an ACL at a node in the LDAP repository:

  1. Create an LDIF file with a content that specifies the ACL:
    dn: <storeRootDN>
changetype: modify
add: orclACI
access to entry by dn="<userDN>" (browse,add,delete) by * (none)
access to attr=(*) by dn="<userDN>" (search,read,write,compare) by * (none)

    where storeRootDN stands for the root node of the store, and userDN stands for the distinguished name of the administrator (the same distinguished name that was entered to perform reassociation).

  2. Use ldapmodify to apply these specifications to the Oracle Internet Directory:
    dn: cn=jpsRootNode
changetype: modify
add: orclACI
access to entry by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (browse,add,delete) by * (none)
access to attr=(*) by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (search,read,write,compare) by * (none)

See also:

ldapmodify in Reference for Oracle Identity Management

Reassociating the Security Store with reassociateSecurityStore

The security store can be reassociated with the reassociateSecurityStore WLST command. For information about this command, see reassociateSecurityStore.

Parent topic: Reassociating the Security Store

Migrating the Security Store

Applications can specify their own policies and these policies are stored in the application stripe (in the security store) when you deploy the application to WebLogic Server. Each application running in the domain uses one stripe, and more than one application can use the same stripe. In a file security store, stripes are specified in the $DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml file under the element <applications>.

Migrating the security store is the process that relocates the policies, credentials, audit data, and keys from one repository to another one. The source type can be file, LDAP, or database. The target type can be LDAP or DB. The OPSS binaries and the target security store must have compatible versions. For information about version issues, see Incompatible Versions of Binaries and Security Store.

The following sections explain how to migrate application security to the security store:

Parent topic: Configuring the Security Store

Migrating the Security Store with Fusion Middleware Control

Applications can migrate security data specified in the jazn-data.xml application file to the security store when you deploy the application to WebLogic Server with Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control). Policies can also be removed from the security store when the application is undeployed and updated when the application is redeployed.

Set the jps.deployment.handler.disabled system property to true to disable the migration of policies and credentials at deployment for all applications regardless of particular settings in the weblogic-application.xml files.

See also:

Task 2, Migrating the Security Store

Parent topic: Migrating the Security Store

Migrating the Security Store with migrateSecurityStore

You can migrate identities, policies, system policies, and credentials, from a source repository to a target repository with the migrateSecurityStore WLST command.

This command does not require a connection to a running server to operate. Therefore, the configuration file passed to the configFile argument need not be an actual domain configuration file, but assembled only to specify the source and target repositories of the migration.

Note:

The migrateSecurityStore command re-creates GUIDs and takes a long time to migrate a large volume of data. Consider using instead Oracle Internet Directory bulk operations to migrate large volume stores. For information about the procedure, see Backing Up and Recovering LDAP Security Stores.

If migrating a large volume of data to an IBM DB2-based security store, you need to set the following configuration parameters on the DB2 database:

  • update db cfg using MAXLOCKS AUTOMATIC

  • update db cfg using LOCKLIST AUTOMATIC

The following sections explain how to use this command:

See also:

Managing Policies with WLST

migrateSecurityStore Usage Examples

Parent topic: Migrating the Security Store

Migrating All Policies with migrateSecurityStore

To migrate all policies (system and application policies, for all applications) use one of the following syntaxes: 

migrateSecurityStore.py -type policyStore
                        -configFile jpsConfigFileLocation
                        -src srcJpsContext
                        -dst dstJpsContext
                        [-skip trueOrfalse]
                        [-overwrite trueOrfalse]

migrateSecurityStore(type="policyStore", 
                     configFile="jpsConfigFileLocation", 
                     src="srcJpsContext", 
                     dst="dstJpsContext" 
                     [,skip="trueOrfalse"] 
                     [,overwrite="trueOrfalse"])

where:

  • configFile specifies the location of a configuration file relative to the directory where the command is run. This configuration file should be specially assembled and must contain a contexts that specify:

    • The source store

    • The target store

    • The bootstrap credentials

    The bootstrap context specifies the location of the cwallet.sso file, which contains the keys needed to access the source and target stores, and to decrypt and encrypt security data.

    For information about extracting the keys used in a domain, see the exportEncryptionKey command in WLST Command Reference for Infrastructure Security.

    For information about storing a key into a wallet, see the importEncryptionKey command in WLST Command Reference for Infrastructure Security.

    For information about creating wallets, see Common Wallet Operations in Administering Oracle Fusion Middleware.

  • src specifies the name of a context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • dst specifies the name of another context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • skip specifies whether the migration should skip migrating incompatible artifacts or to terminate upon encountering an incompatible artifact in the source repository. Set to true to skip migrating incompatible artifacts and not to terminate. Set to false to terminate when an incompatible artifact is detected. Optional. If unspecified, then it defaults to false.

  • overwrite specifies whether to overwrite data in the target store. Set to true to overwrite target data. Set to false not to overwrite target data. Optional. If unspecified, then it defaults to false.

The contexts you specify in src and dst must be defined in the passed configuration file, have distinct names, and the case of the passed contexts must match the case of the contexts in the configuration file. From these two contexts, the command determines the locations of the source and the target repositories involved in the migration.

Migrating System Policies with migrateSecurityStore

To migrate just system policies use one of the following syntaxes: 

migrateSecurityStore.py -type globalPolicies
                        -configFile jpsConfigFileLocation
                        -src srcJpsContext
                        -dst dstJpsContext
                        [-overwrite trueOrfalse]

migrateSecurityStore(type="globalPolicies", 
                     configFile="jpsConfigFileLocation", 
                     src="srcJpsContext", 
                     dst="dstJpsContext" 
                     [,overwrite="trueOrfalse"])

where:

  • configFile specifies the location of a configuration file relative to the directory where the command is run. This configuration file should be specially assembled and must contain contexts that specify:

    • The source store

    • The target store

    • The bootstrap credentials

    The bootstrap context specifies the location of the cwallet.sso file, which contains the keys needed to access the source and target stores, and to decrypt and encrypt security data.

    For information about extracting keys used by a domain, see exportEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about storing a key into a wallet, see importEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about creating wallets, see Common Wallet Operations in Administering Oracle Fusion Middleware.

  • src specifies the name of a context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • dst specifies the name of another context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • skip specifies whether the migration should skip migrating incompatible artifacts or to terminate upon encountering an incompatible artifact in the source repository. Set to true to skip migrating incompatible artifacts and not to terminate. Set to false to terminate if an incompatible artifact is detected. Optional. If unspecified, then it defaults to false.

  • overwrite specifies whether to overwrite data in the target store. Set to true to overwrite target data. Set to false not to overwrite target data. Optional. If unspecified, then it defaults to false.

The contexts you specify in src and dst must be defined in the configuration file, have distinct names, and the case of the passed contexts must match the case of the contexts in the configuration file. From these two contexts, the command determines the locations of the source and the target repositories involved in the migration.

Migrating Application Policies with migrateSecurityStore

To migrate just application-specific policies for an application, use one of the following syntaxes: 

migrateSecurityStore.py -type appPolicies
                        -configFile jpsConfigFileLocation
                        -src srcJpsContext
                        -dst dstJpsContext
                        -srcApp srcAppName
                        [-dstApp dstAppName]
                        [-overWrite trueOrfalse]
                        [-migrateIdStoreMapping trueOrfalse]
                        [-mode laxOrstrict]
                        [-skip trueOrfalse]

migrateSecurityStore(type="appPolicies", 
                     configFile="jpsConfigFileLocation", 
                     src="srcJpsContext", 
                     dst="dstJpsContext", 
                     srcApp="srcAppName", 
                     [dstApp="dstAppName"], 
                      [overWrite="trueOrfalse"], 
                      [migrateIdStoreMapping="trueOrfalse"], 
                      [mode="strict"], 
                      skip="trueOrfalse")

where:

  • configFile specifies the location of a configuration file relative to the directory where the command is run. This configuration file should be specially assembled and must contain contexts that specify:

    • The source store

    • The target store

    • The bootstrap credentials

    The bootstrap context specifies the location of the cwallet.sso file, which contains the keys needed to access the source and target stores, and to decrypt and encrypt security data.

    For information about extracting keys used by a domain, see exportEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about storing a key into a wallet, see importEncryptionKey in WLST Command Reference for Infrastructure Security

    For information about creating wallets, see Common Wallet Operations in Administering Oracle Fusion Middleware.

  • src specifies the name of a context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • dst specifies the name of another context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • skip specifies whether the migration should skip migrating incompatible artifacts or to terminate upon encountering an incompatible artifact in the source repository. Set to true to skip migrating incompatible artifacts and not to terminate. Set to false to terminate if an incompatible artifact is detected. Optional. If unspecified, then it defaults to false.

  • srcApp specifies the name of the application whose policies are migrated.

  • dstApp specifies the name of the application whose policies are being written. If unspecified, then it defaults to the name of the source application. Optional.

  • migrateIdStoreMapping specifies whether enterprise policies should be migrated. The default value is true. To migrate just application policies, set it to false. Optional.

  • overWrite specifies whether a target application policy stripe matching a source application policy stripe should be overwritten by or merged with the source application policy stripe.

    Set to true to overwrite the target application policy stripe; set to false to merge the new policy artifacts in the source application policy stripe into the target application policy stripe. If unspecified, it defaults to false.

    During merging, if a policy artifact with the same name exists in the target application stripe, then the migration of the policy artifact is skipped. Only  the new resource actions added to a permission set, new members added to an application role, and new actions added to a resource type are merged into the target policy artifact.

  • mode specifies whether the migration should stop and signal an error upon encountering a duplicate principal or a duplicate permission in a policy. Either do not specify or set to lax to allow the migration to continue when it encounters duplicate items, to migrate just one of the duplicated items, and to log a warning to this effect. Optional.

The contexts you specify in src and dst must be defined in the configuration file, have distinct names, and the case of the passed contexts must match the case of the contexts in the configuration file. From these two contexts, the command determines the locations of the source and the target repositories involved in the migration.

If the input does not follow these syntax requirements, then the command execution fails. In particular, the input must satisfy the following requisites: (a) the jps-config.xml file is found in the passed location, (b) the jps-config.xml file includes the passed contexts, and (c) the source and the target context names are distinct.

Migrating All Credentials with migrateSecurityStore in the Same Domain

To migrate all credentials use one of the following syntaxes: 

migrateSecurityStore.py -type credStore
                        -configFile jpsConfigFileLocation
                        -src srcJpsContext
                        -dst dstJpsContext
                        [-skip trueOrfalse]
                        [-overwrite trueOrfalse]

migrateSecurityStore(type="credStore", 
                     configFile="jpsConfigFileLocation", 
                     src="srcJpsContext", 
                     dst="dstJpsContext", 
                     [skip="trueOrfalse"], 
                     [overwrite="trueOrfalse"])

where:

  • configFile specifies the location of a configuration file relative to the directory where the command is run. This configuration file should be specially assembled and must contain contexts that specify:

    • The source store

    • The target store

    • The bootstrap credentials

    The bootstrap context specifies the location of the cwallet.sso file, which contains the keys needed to access the source and target stores, and to decrypt and encrypt security data.

    For information about extracting keys used by a domain, see exportEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about storing a key into a wallet, see importEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about creating wallets, see Common Wallet Operations in Administering Oracle Fusion Middleware.

  • src specifies the name of a context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • dst specifies the name of another context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • skip specifies whether the migration should skip migrating incompatible artifacts or to terminate upon encountering an incompatible artifact in the source repository. Set to true to skip migrating incompatible artifacts and not to terminate. Set to false to terminate if an incompatible artifact is detected. Optional. If unspecified, it defaults to false.

  • overwrite specifies whether to overwrite data in the target store. Set to true to overwrite target data. Set to false not to overwrite target data. Optional. If unspecified, then it defaults to false.

The contexts you specify in src and dst must be defined in the configuration file, have distinct names, and the case of the passed contexts must match the case of the contexts in the configuration file. From these two contexts, the command determines the locations of the source and the target repositories involved in the migration.

Migrating One Credential Map with migrateSecurityStore in the Same Domain

To migrate just one credential map, use one of the following syntaxes: 

migrateSecurityStore.py -type folderCred
                        -configFile jpsConfigFileLocation
                        -src srcJpsContext
                        -dst dstJpsContext
                        [-srcFolder map1]
                        [-dstFolder map2]
                        [-overWrite trueOrFalse]
                        [-skip trueOrFalse]

migrateSecurityStore(type="folderCred", 
                     configFile="jpsConfigFileLocation", 
                     src="srcJpsContext", 
                     dst="dstJpsContext", 
                     [srcFolder="map1"], 
                     [dstFolder="map2"], 
                     [overWrite="trueOrFalse"], 
                     [skip="trueOrFalse"])

where:

  • configFile specifies the location of a configuration file relative to the directory where the command is run. This configuration file should be specially assembled and must contain contexts that specify:

    • The source store

    • The target store

    • The bootstrap credentials

    The bootstrap context specifies the location of the cwallet.sso file, which contains the keys needed to access the source and target stores, and to decrypt and encrypt security data.

    For information about extracting keys used by a domain, see exportEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about storing a key into a wallet, see importEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about creating a wallet, see Common Wallet Operations in Administering Oracle Fusion Middleware.

  • src specifies the name of a context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • dst specifies the name of another context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • skip specifies whether the migration should skip migrating incompatible artifacts or to terminate upon encountering an incompatible artifact in the source repository. Set to true to skip migrating incompatible artifacts and not to terminate. Set to false to terminate if an incompatible artifact is detected. Optional. If unspecified, then it defaults to false.

  • srcFolder specifies the name of the map containing the credentials to migrate. Optional. If unspecified, then the credential store is assumed to have only one map and the value of this argument defaults to the name of that map.

  • dstFolder specifies the map where the source credentials are migrated. Optional. If unspecified, then it defaults to the map passed to srcFolder.

  • overWrite specifies whether a target credential matching a source credential should be overwritten by or merged with the source credential. Set to true to overwrite target credentials. Set to false to merge matching credentials. Optional. If unspecified, then it defaults to false. When false and if a matching is detected, then the source credential is disregarded and a warning is logged.

The contexts you specify in src and dst must be defined in the configuration file, have distinct names, and the case of the passed contexts must match the case of the contexts in the configuration file. From these two contexts, the command determines the locations of the source and the target repositories involved in the migration.

Migrating All Credentials with migrateSecurityStore Across Domains

To migrate all credentials across domains, use one of the following syntaxes: 

migrateSecurityStore.py -type credStore
                        -configFile "/target_domain/config/fmwconfig/jps-config.xml
                        -src srcJpsContext
                        -dst dstJpsContext
                        [-skip trueOrfalse]
                        -srcConfigFile “/source_domain/config/fmwconfig/jps-config.xml
                        [-overwrite trueOrfalse]

migrateSecurityStore(type="credStore", 
                     -configFile "/target_domain/config/fmwconfig/jps-config.xml, 
                     src="srcJpsContext", 
                     dst="dstJpsContext", 
                     [skip="trueOrfalse"],
								 [srcConfigFile="alternConfigFileLocation"], 
                     [overwrite="trueOrfalse"])

where:

  • configFile refers to the configuration file in the destination domain where credentials are being migrated to. This configuration file should be specially assembled and must contain contexts that specify:

    • The target store

    • The bootstrap credentials

    The bootstrap context specifies the location of the cwallet.sso file, which contains the keys needed to access the source and target stores, and to decrypt and encrypt security data.

    For information about extracting keys used by a domain, see exportEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about storing a key into a wallet, see importEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about creating wallets, see Common Wallet Operations in Administering Oracle Fusion Middleware.

  • src specifies the name of a context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • dst specifies the name of another context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • skip specifies whether the migration should skip migrating incompatible artifacts or to terminate upon encountering an incompatible artifact in the source repository. Set to true to skip migrating incompatible artifacts and not to terminate. Set to false to terminate if an incompatible artifact is detected. Optional. If unspecified, it defaults to false.

  • srcConfigFile refers to the  configuration file on the source domain from where credentials are copied.

  • overwrite specifies whether to overwrite data in the target store. Set to true to overwrite target data. Set to false not to overwrite target data. Optional. If unspecified, then it defaults to false.

The contexts you specify in src and dst must be defined in the configuration file, have distinct names, and the case of the passed contexts must match the case of the contexts in the configuration file. From these two contexts, the command determines the locations of the source and the target repositories involved in the migration.

Migrating One Credential Map with migrateSecurityStore Across Domains

To migrate just one credential map, use one of the following syntaxes: 

migrateSecurityStore.py -type folderCred
                        -configFile "/target_domain/config/fmwconfig/jps-config.xml
                        -src srcJpsContext
                        -dst dstJpsContext
                        [-srcFolder map1]
                        [-dstFolder map2]
                        -srcConfigFile “/source_domain/config/fmwconfig/jps-config.xml
                        [-overWrite trueOrFalse]
                        [-skip trueOrFalse]

migrateSecurityStore(type="folderCred", 
                     -configFile "/target_domain/config/fmwconfig/jps-config.xml, 
                     src="srcJpsContext", 
                     dst="dstJpsContext", 
                     [srcFolder="map1"], 
                     [dstFolder="map2"], 
                     -srcConfigFile “/source_domain/config/fmwconfig/jps-config.xml, 
                     [overWrite="trueOrFalse"], 
                     [skip="trueOrFalse"])

where:

  • configFile specifies the location of a configuration file relative to the directory where the command is run. This configuration file should be specially assembled and must contain contexts that specify:

    • The source store

    • The target store

    • The bootstrap credentials

    The bootstrap context specifies the location of the cwallet.sso file, which contains the keys needed to access the source and target stores, and to decrypt and encrypt security data.

    For information about extracting keys used by a domain, see exportEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about storing a key into a wallet, see importEncryptionKey in WLST Command Reference for Infrastructure Security.

    For information about creating a wallet, see Common Wallet Operations in Administering Oracle Fusion Middleware.

  • src specifies the name of a context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • dst specifies the name of another context in the configuration file passed to the configFile argument. The case of the string passed must match the case of the context in the configuration file.

  • skip specifies whether the migration should skip migrating incompatible artifacts or to terminate upon encountering an incompatible artifact in the source repository. Set to true to skip migrating incompatible artifacts and not to terminate. Set to false to terminate if an incompatible artifact is detected. Optional. If unspecified, then it defaults to false.

  • srcFolder specifies the name of the map containing the credentials to migrate. Optional. If unspecified, then the credential store is assumed to have only one map and the value of this argument defaults to the name of that map.

  • dstFolder specifies the map where the source credentials are migrated. Optional. If unspecified, then it defaults to the map passed to srcFolder.

  • srcConfigFile refers to the configuration file on the source domain from where credentials are copied.

  • overWrite specifies whether a target credential matching a source credential should be overwritten by or merged with the source credential. Set to true to overwrite target credentials. Set to false to merge matching credentials. Optional. If unspecified, then it defaults to false. When false and if a matching is detected, then the source credential is disregarded and a warning is logged.

The contexts you specify in src and dst must be defined in the configuration file, have distinct names, and the case of the passed contexts must match the case of the contexts in the configuration file. From these two contexts, the command determines the locations of the source and the target repositories involved in the migration. For more examples, see Migrating Credentials with migrateSecurityStore.

Migrating Audit Data with migrateSecurityStore

Use the migrateSecurityStore WLST command to migrate audit data to a different security store. For information about the procedure, see Migrating Audit Data

migrateSecurityStore Usage Examples

Configuring Security Providers with Fusion Middleware Control

Follow the instructions in this section to migrate the security store, to configure the identity store provider and security services, and to manage login modules and properties with Fusion Middleware Control.

Task 1, Opening the Security Provider Configuration Page

Log in to Fusion Middleware Control and go to Domain, then to Security, and then to Security Provider Configuration. The Security Provider Configuration page is displayed.

Task 2, Migrating the Security Store

  1. Expand Security Store Provider and Security Stores.

  2. Click Change Store Type. The Configure Security Stores page is displayed. In this page, enter the target repository parameters.

  3. Click OK.

Task 3, Configuring the Identity Store Provider

  1. Expand Security Store Provider and Identity Store Provider.

  2. Click the Configure button. The Identity Store Configuration page is displayed. In this page, enter add or edit properties, as appropriate.

  3. Click OK.

Task 4, Configuring Security Services

  1. Expand Security Store Provider and Security Services.

  2. Click a pencil icon to configure a provider. The provider's page is displayed.

  3. In this page, enter the required fields.

  4. Click OK.

Task 5, Managing Login Modules

  1. Expand Security Store Provider and Login Modules. The table of configured login modules is displayed.

  2. Click Create to create a new login module. The Create Login Module page is displayed. Enter the login module parameters and click OK.

  3. Click Edit to modify a login module. The Edit Login Module page is displayed. Modify parameters and click OK.

  4. Click Delete to remove a login module. Confirm deletion.

Task 6, Managing Properties and Property Sets

  1. Expand Security Store Provider and Advanced Properties.
  2. Click the Configure button. The Advanced Properties page is displayed.
  3. In this page, do any of the following:

    • Click Add to add a new property.

    • Click Edit to modify a property.

    • Click Delete to removed a property.

    • Click Add Property Set to add a new property set.

    • Click Add Property to add a property to a set.

    • Click Edit Property to modify a property in a property set.

    • Click Delete to remove a property set or a property in a property set.

Parent topic: Configuring the Security Store