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:
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 at 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
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.
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:
Choose first Administration, then Shared Properties, and then General.
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 12c Certifications at http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html.
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
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:
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.
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
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"
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
oidstats.sql in Reference for Oracle Identity Management
Use the procedure in this section to reset the LDAP user password.
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.
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
Run modifyBootStrapCredential to update the password in the bootstrap wallet.
See also:
Administrator's Guide for Oracle Internet Directory
modifyBootStrapCredential in WLST Command Reference for Infrastructure Security
A database 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 12c Certifications at http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html.
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 in Upgrading to the Oracle Fusion Middleware Infrastructure.
The following sections explain how to set up a 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
This section describes some of the tasks that you follow to maintain a database security store, including changing the OPSS schema password.
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.
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);
To reset the OPSS schema password:
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.
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.
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
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.
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:
Reassociating the Security Store with Fusion Middleware Control
Reassociating the Security Store with reassociateSecurityStore
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.
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:
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).
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
The security store can be reassociated with the reassociateSecurityStore WLST command. For information about this command, see reassociateSecurityStore.
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:
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:
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.
Notes:
ThemigrateSecurityStore 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:
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.
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.
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 policy matching a source policy should be overwritten by or merged with the source policy. Set to true to overwrite the target policy. Set to false to merge matching policies. Optional. If unspecified, then defaults to false.
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.
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.
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]
[-srcConfigFile alternConfigFileLocation]
[-overWrite trueOrFalse]
[-skip trueOrFalse]
migrateSecurityStore(type="folderCred",
configFile="jpsConfigFileLocation",
src="srcJpsContext",
dst="dstJpsContext",
[srcFolder="map1"],
[dstFolder="map2"],
[srcConfigFile="alternConfigFileLocation"],
[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 specifies the location of an alternate configuration file, and it is used in the special case in which credentials are not configured in the file passed to configFile. Optional. If unspecified, then it defaults to the value passed to configFile. If specified, then the value passed to configFile is ignored.
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.
Use the migrateSecurityStore WLST command to migrate audit data to a different security store. For information about the procedure, see Migrating Audit Data
For complete examples illustrating the use of migrateSecurityStore, see the following sections:
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
Expand Security Store Provider and Security Stores.
Click Change Store Type. The Configure Security Stores page is displayed. In this page, enter the target repository parameters.
Click OK.
Task 3, Configuring the Identity Store Provider
Expand Security Store Provider and Identity Store Provider.
Click the Configure button. The Identity Store Configuration page is displayed. In this page, enter add or edit properties, as appropriate.
Click OK.
Task 4, Configuring Security Services
Expand Security Store Provider and Security Services.
Click a pencil icon to configure a provider. The provider's page is displayed.
In this page, enter the required fields.
Click OK.
Task 5, Managing Login Modules
Expand Security Store Provider and Login Modules. The table of configured login modules is displayed.
Click Create to create a new login module. The Create Login Module page is displayed. Enter the login module parameters and click OK.
Click Edit to modify a login module. The Edit Login Module page is displayed. Modify parameters and click OK.
Click Delete to remove a login module. Confirm deletion.
Task 6, Managing Properties and Property Sets
Expand Security Store Provider and Advanced Properties.
Click the Configure button. The Advanced Properties page is displayed.
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.