9 Configuring the OPSS Security Store

The OPSS security store is the repository of system and application-specific policies, credentials, keys, and audit metadata.

This chapter explains the features of the OPSS security store in the following sections:

For details about Java EE and WebLogic Security, see section Java EE and WebLogic Security in Understanding Security for Oracle WebLogic Server.

Note:

When a WebLogic domain is setup to use policies based on the OPSS security store, JACC policies and the Java Security Manager become unavailable on all managed servers in that domain.

Important:

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

9.1 Introduction to the OPSS Security Store

The OPSS security store is the repository of system and application-specific policies, credentials, and keys. This centralization facilitates the administration and maintenance of policy, credential, and key data.

The OPSS security store can be file-, LDAP-, or DB-based depending on the choice of repository type, and it can be reassociated (that is, the repository type can be changed) from file-based to LDAP- or DB-based; from DB-based to LDAP- or DB-based; and from LDAP-based to LDAP- or DB-based. No other reassociation is supported. For details about the tools and procedures available to reassociate the OPSS security store, see sections Reassociating with Fusion Middleware Control and Reassociating with the Script reassociateSecurityStore. Out-of-the-box, the OPSS security store is DB-based for production WebLogic domains.

The security artifacts relevant to a Java EE application are typically packaged with the application and they can be migrated at deploy time to the OPSS security store. For details about the tools and procedures available to migrate to the OPSS security store, see sections Migrating with Fusion Middleware Control and Migrating with the Script migrateSecurityStore.

9.1.1 Multi-Server Environments

Production WebLogic domains with several server instances (administration and managed servers) on the same host or distributed across multiple machines, must use an OID- or an Oracle RDBMS-based OPSS security store.

Note:

File-based providers are not supported in production environments.

For details about the properties you can set on policies and credentials, see sections Appendix F, "Policy Store Properties," and Appendix F, "Credential Store Properties."

9.2 Using an LDAP-Based OPSS Security Store

An LDAP-based OPSS security store is typically used in production environments. The only LDAP server supported is the Oracle Internet Directory (release 10.1.4.3 or later).

Note:

Depending on the version, the following patches to Oracle Internet Directory are required:
  • Patch to fix bug 9093298 in Oracle Internet Directory 10.1.4

  • Patch to fix bug 8736355 in Oracle Internet Directory 11.1.x

  • Patch to fix bug 8426457 in Oracle Internet Directory 11.1.x and 10.1.4.3

  • Patch to fix bug 8351672 in Oracle Internet Directory 10.1.4.3

  • Patch to fix bug 8417224 in Oracle Internet Directory 10.1.4.3

  • Patch to fix bug 13782459 in Oracle Internet Directory 11.1.1.6.0

To apply a patch, proceed as follows:

  1. Visit Oracle Automated Release Updates.

  2. Click the Patches tab.

  3. Enter the bug number in the Request Number box, and click Search.

  4. Apply the patch.

To use a domain LDAP-based OPSS security store the domain administrator must configure it, as appropriate, using Oracle Enterprise Manager Fusion Middleware Control or WLST commands.

Important:

OPSS does not support enabling referential integrity on Oracle Internet Directory 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 as follows:

  1. Select Administration, then Shared Properties from the Oracle Internet Directory menu, and then select General.

  2. Select Disabled from the Enable referential Integrity list.

For a list of properties that can be specified in a service instance, see Appendix F, "Properties Common to All LDAP-Based Instances."

9.2.1 Prerequisites to Using an LDAP-Based Security Store

The only supported LDAP-based OPSS security store is Oracle Internet Directory. In order to ensure the proper access to the Oracle Internet Directory, you must set a node in the server directory as explained below.

Fusion Middleware Control automatically provides bootstrap credentials in the file cwallet.sso when that tool is used to reassociate to an LDAP-based repository. To specify these required credentials manually, see section Section 18.5.7, "Specifying Bootstrap Credentials Manually."

Setting a Node in an Oracle Internet Directory Server

The following procedure is carried out by an Oracle Internet Directory administrator.

To set a node in an LDAP Oracle Internet Directory, proceed as follows:

  1. Create an LDIF file (assumed jpstestnode.ldif, for illustration purpose) specifying the following DN and CN entries:

    dn: cn=jpsroot
    cn: jpsroot
    objectclass: top
    objectclass: OrclContainer
    

    The distinguished name of the root node (illustrated by the string jpsroot above) must be distinct from any other distinguished name. Some LDAP servers enforce case sensitivity by default. One root node can be shared by multiple WebLogic domains. It is not required that this node be created at the top level, as long as read and write access to the subtree is granted to the Oracle Internet Directory administrator.

  2. Import this data into the LDAP server using the command ldapadd, as illustrated in the following example (there should be no line break in the command invocation):

    >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 using the command ldapsearch, as illustrated in the following example (there should be no line break in the command invocation):

    >ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin -w password -s base 
    -b "cn=jpsroot" objectclass="orclContainer"
    
  4. Run the utility oidstats.sql to generate database statistics for optimal database performance, as illustrated in the following example:

    >$ORACLE_HOME/ldap/admin/oidstats.sql
    

    The above utility must be run just once after the initial provisioning. For details about this utility, consult the Oracle Fusion Middleware Reference for Oracle Identity Management.

    To reassociate the OPSS security store, see Reassociating the OPSS Security Store.

9.2.2 Setting Up a One- Way SSL Connection to the LDAP

This section describes how to set up a one-way SSL channel between Oracle WebLogic server or a Java SE application and the LDAP Oracle Internet Directory. Such connection may be required, for example, when reassociating to an LDAP-based target store.

Prerequisite: Configuring the Oracle Internet Directory Server

To configure the Oracle Internet Directory server to listen in one-way SSL mode, see section Enabling SSL on Oracle Internet Directory Listeners in Administering Oracle Fusion Middleware.

Exporting Oracle Internet Directory's Certificate Authority (CA)

The use of orapki to create a certificate is needed only if the CA is unknown to the Oracle WebLogic server.

The following sample illustrates the use of this command to create the certificate serverTrust.cert:

>orapki wallet export -wallet CA -dn "CN=myCA" -cert serverTrust.cert

The above invocation prompts the user to enter the keystore password.

Before You Begin

Before configuring SSL, note that:

  • The following procedures are required if the type of SSL being established is server-auth, and they are not required in any other case (no-auth or client-auth).

  • If the flags specified in the procedures below are used in a multi-application environment, then the trust store must be shared by all those applications.

Setting Up the WebLogic Server in Case of a Java EE Application

The difference in the following procedures is because the identity store service and the OPSS security store service use different socket factories.

To establish a one-way SSL connection between the server and the identity store, proceed as follows (if applicable, the trust CA is assumed exported):

  1. If the CA is known to the Oracle WebLogic server, skip this step; otherwise, use the utility keytool to import the Oracle Internet Directory's CA into the WebLogic trust store.

    The following invocation, which outputs the file myKeys.jks, illustrates the use of this command to import the file serverTrust.cert:

    >keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
    
  2. Modify the script (typically startWebLogic.sh) that starts the server to include a line like the following, and then restart the server:

    -Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
    

To establish a one-way SSL connection between the server and the OPSS security store, proceed as follows (if applicable, the trust CA is assumed exported):

  1. Use the utility keytool to import trust CA to the trust key store, as illustrated in the following invocation:

    >keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
    
  2. Modify the script (typically startWebLogic.sh) that starts the server to include a line like the following, and then restart the server:

    -Dweblogic.security.SSL.trustedCAKeyStore=<absolute path name to file myKeys.jks>
    
  3. If the OID server uses a wild card in the SSL certificate, then add the following line to the script that starts the WebLogic server:

    -Dweblogic.security.SSL.ignoreHostnameVerification=true
    

Setting Up the WebLogic Server in Case of a Java SE Application

The setting up in the case of Java SE applications is the identical for both the identity store and the OPSS security store.

  1. If the CA is known to the Oracle WebLogic server, skip this step; otherwise, use the utility keytool to import the Oracle Internet Directory's CA into the WebLogic trust store.

    The following invocation, which outputs the file myKeys.jks, illustrates the use of this command to import the file serverTrust.cert:

    >keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
    
  2. Modify the script that starts the JMV to include a line like the following:

    -Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
    

9.3 Using a DB-Based OPSS Security Store

A DB-based security store is typically used in production environments. The only supported DB-based security store in production environments is Oracle RDBMS (releases 11.1.0.7 or later; and releases 11.2.0.3 or later).

Note:

In development environments only, the OPSS security store can be Oracle RDBMS Express, Oracle RDBMS Standard Edition, and Oracle RDBMS Standard Edition One.

To use a DB-based OPSS security store the domain administrator must configure it, as appropriate, using Oracle Enterprise Manager Fusion Middleware Control or WLST commands. In case any checks are needed before the server completes its initialization, see Section J.3.6, "Permission Failure Before Server Starts." The OPSS schema supports Edition-Based Redefinition (EBR).

For a list of properties that can be configured, see Appendix F, "OPSS Configuration Properties."

This section contains the following topics:

9.3.1 Prerequisites to Using a DB-Based Security Store

To use a database repository for the OPSS security store, one must first use Oracle Fusion Middleware Repository Creation Utility (RCU) to create the required schema and to seed some initial data.

For details about this task, see appendix A, Understanding Repository Creation Utility Screens, in Creating Schemas with the Repository Creation Utility. To create the OPSS schema, select the following schemas:

  • <prefix>_OPSS

  • <prefix>_IAU

  • <prefix>_IAU_APPEND

  • <prefix>_IAU_VIEWER

9.3.2 Maintaining a DB-Based Security Store

This section describes a few tasks that an administrator can follow to maintain a DB-based security store.

A DB-based security store maintains a change log that should be periodically purged. To purge it, an administrator can use the provided SQL script opss_purge_changelog.sql, which will purge change logs older than 24 hours, or connect to the database and run SQL delete (with the appropriate arguments) as illustrated in the following lines:

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

If the OPSS management API performs slowly while accessing the DB-based security store, run the DBMS_STATS package to gather statistics about the physical storage of a DB table, index, of cluster. This information is stored in the data dictionary and can be used to optimize the execution plan for SQL statements accessing analyzed objects.

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

The following sample 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 DB schema created withRCU. For details about the DBMS_STATS package, see the Oracle Database Administrator's Guide.

To run DBMS_STATS periodically, use a shell script or an SQL script, as described next.

The following sample script runs the command DBMS_STATS every 10 minutes:

#!/bin/sh
i=1
while [ $i -le 1000 ]
do
echo $i
sqlplus dev_opss/welcome1@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 sample SQL script also runs the command 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 periodic invocation of DBMS_STATS by the above 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 issue a command like the following, in which it is assumed that the query above returned the job number 31:

EXEC DBMS_JOB.remove(31);

9.3.3 Setting Up an SSL Connection to the DB

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

For additional information about SSL-related topics see the following document:

9.4 Configuring the OPSS Security Store

For examples of store configurations for Java SE applications, see Section 20.1, "Policy and Credential Stores in Java SE Applications."

For examples of store configurations for Java EE applications, see Example 1.

For details about configuring other artifacts, see Configuring Services Providers with Fusion Middleware Control.

9.5 Reassociating the OPSS Security Store

Reassociating the OPSS security store is the process of relocating security artifacts from one repository to another one. The source can be file-, LDAP-, or DB-based; the target can be LDAP- or DB-based. The only type of LDAP target supported is Oracle Internet Directory; the only type of DB target supported is Oracle database.

Reassociation changes the repository while preserving the integrity of the data stored. All security artifacts are migrated from the existing security store to the new target store. This operation can take place at any time after the domain has been created, and it is carried out using either Fusion Middleware Control or reassociateSecurityStore as explained in the following sections:

9.5.1 Reassociating with Fusion Middleware Control

Reassociation migrates the OPSS security store (policies, credentials, keys, and audit metadata) from one repository to another and reconfigures the appropriate security store providers. This section explains how to perform reassociation with Fusion Middleware Control pages.

For information about other uses of the Security Provider Configuration page, see Configuring Services Providers with Fusion Middleware Control.

Important Points

To reassociate the OPSS security store with Fusion Middleware Control, proceed as follows:

  1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration, to display the Security Provider Configuration page, partially illustrated in the following graphic:

    Surrounding text describes emsecprovconf.gif.

    The table in the area Security Stores shows the characteristics of the current provider configured in the domain.

  2. Click the button Change Association to display the Set Security Provider page, and choose the Store Type from the pull-down list. The text displayed on this page depends on the store type selected. The following graphic partially illustrates this page when Oracle Internet Directory is selected.

    Surrounding text describes emsetsecprvdr.gif.
  3. If you have selected Database, enter the name of the data source in the Datasource Name box. This should be the name of the JDBC data source entered when the data source was created. If needed, click Select to obtain a list of configured data source names.

  4. If you have selected Oracle Internet Directory, in the LDAP Server Details area, specify details and connection information about the target LDAP server:

    1. Enter the host name and port number of your target Oracle Internet Directory LDAP server.

    2. Optionally, check the box Use SSL to Connect to establish an anonymous SSL transmission to the LDAP server.

      When checking this box, keep in mind the following points:

      The port of the target LDAP server must be configured to handle an anonymous SSL transmission; this port is distinct from the default (non-secure) LDAP server port.

      If the reassociation is to use a one-way SSL to a target LDAP store, be sure to follow the instructions in Setting Up a One- Way SSL Connection to the LDAP before completing this step. Among other things, that setup identifies the port to support a one-way SSL channel, and it is that port that should be specified in this step. Reassociation through a two-way SSL channel is not supported in this release.

      Fusion Middleware Control modifies the file weblogic.policy by adding the necessary grant to support the anonymous SSL connection.

    3. In the text box Connect DN, enter the full distinguished name, a string containing between 1 and 256 characters. For example, cn=orcladmin,dc=us,dc=oracle,dc=com.

    4. In the box Password, enter the user password, also a string containing between 1 and 256 characters.

    5. To verify that the connection to the LDAP server using the entered data works, click the button Test LDAP Authentication. If you run into any connection problem, see Section J.5.5, "Failure to Establish an Anonymous SSL Connection."

  5. In the Root Node Details area, enter the root DN in the box Root DN, which identifies the top of the tree that contains the data in the LDAP repository. The Domain Name defaults to the name of the selected domain.

    To solve most common errors arising from the specifications in these two fields, see Section J.2.1, "Reassociation Failure."

  6. Optionally, in the Policy Store Properties and Credential Store Properties areas, enter service instance properties, such as Enable Lazy Load and Role Member Cache Size.

    To add a new property: click Add to display the Add New Property dialog; in this dialog, enter strings for Property Name and Value; click OK. The added property-value pair is displayed in the table Custom Properties.

    These properties are typically used to initialize the instance when it is created.

    A property-value pair you enter modifies the domain configuration file jps-config.xml by adding a <property> element in the configuration of the LDAP service instance.

    To illustrate how a service instance is modified, suppose you enter the property name foo and value bar; then the configuration for the LDAP service instance changes to contain a <property> element as illustrated in the following excerpt:

    <serviceInstance name="myNewLDAPprovider" provider="someProvider"
      ...
      <property name="foo" value="bar"/>
      ...
    </serviceInstance>
    
  7. When finished entering your data, click OK to return to the Security Provider Configuration page. The system displays a dialog notifying the status of the reassociation. The table in the Security Stores area is modified to reflect the provider you have specified.

  8. Restart the application server. Changes do not take effect until it has been restarted.

Reassociation modifies the domain configuration file $DOMAIN_HOME/config/fmwconfig/jps-config.xml: it deletes any configuration for the old store provider, inserts a configuration for the new store provider, and moves the policy and credential information from the source to the destination store.

If the destination store is LDAP-based, the information is stored under the domain DN according to the following format:

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

As long as the configuration of the installation relies upon the above domain DN, that node should not be deleted from the LDAP Server.

9.5.1.1 Securing Access to Oracle Internet Directory Nodes

The procedure explained in this section is optional and performed only to enhance the security to access an Oracle Internet Directory.

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

ACL can be used to control the access to policy and credential data stored in an LDAP Oracle Internet Directory repository, and it is, typically, specified at the top, root node of the store.

To specify an ACL at a node in an Oracle Internet Directory repository, proceed as follows:

  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 a node (typically the root node of the store), and userDN stands for the DN of the administrator data (the same userDN that was entered to perform reassociation).

  2. Use the Oracle Internet Directory utility ldapmodify to apply these specifications to the Oracle Internet Directory.

Here is an example of an LDIF file specifying an ACL:

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)

For more information about access control lists and the command ldapmodify, see chapter 18 in Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory.

9.5.2 Reassociating with the Script reassociateSecurityStore

The OPSS store can be reassociated with the WLST command reassociateSecurityStore. For details, see Section 10.3.1, "reassociateSecurityStore."

9.6 Migrating the OPSS Security Store

A domain includes one and only one security store. Applications can specify their own policies, and these are stored as application policies in the appropriate stripe in the security store when the application is deployed to a server. All applications deployed or redeployed to a domain use a common security store, the domain security store. This store is logically partitioned in stripes, one for each application name specified in the file $DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml under the element <applications>.

Migrating the OPSS security store is the process that relocates the policies, credentials, audit metadata, and keys from one repository to another one. The source can be file-, LDAP-, or DB-based; the target can be LDAP- or DB-based. The OPSS binaries and the target OPSS security store must have compatible versions; for details, see Section J.8.1, "Incompatible Versions of Binaries and Policy Store."

During application development, an application specifies its own policies, and these can be migrated to the OPSS security store when the application is deployed with Fusion Middleware Control. Policies can also be migrated manually; in addition, each application component can specify the use of anonymous user and role, authenticated role, and JAAS mode.

The configuration of the OPSS security store is performed by an administrator.

These topics are explained in the following sections:

Note:

Use the system property jps.deployment.handler.disabled to disable the migration of application policies and credentials for applications deployed on a WebLogic Server.

When this system property is set to TRUE, the migration of policies and credentials at deployment is disabled for all applications regardless of the particular application settings in the application file weblogic-application.xml.

9.6.1 Migrating with Fusion Middleware Control

Application policies are specified in the application file jazn-data.xml and can be migrated to the OPSS security store when the application is deployed to a server in the WebLogic environment with Fusion Middleware Control; they can also be removed from the OPSS security store when the application is undeployed or be updated when the application is redeployed.

All three operations, the migration, the removal, and the updating of application policies, can take place regardless of the type of policy repository, but they do require particular configurations.

For details, see procedure in Section 6.6.2, "Migrating Policies and Credentials."

9.6.2 Migrating with the Script migrateSecurityStore

Application-specific policies, system policies, and credentials can be migrated manually from a source repository to a target repository using the WLST command migrateSecurityStore.

This script is offline, that is, it does not require a connection to a running server to operate; therefore, the configuration file passed to the argument configFile need not be an actual domain configuration file, but it can be assembled just to specify the source and destination repositories of the migration.

Note:

Since the script migrateSecurityStore recreates GUIDs and takes a long time to migrate large volume of data, you may want to consider migrating stores with an alternate procedure that uses Oracle Internet Directory bulk operations. For details, see Section 6.6.2.3, "Migrating Large Volume Policy and Credential Stores.".

For platform-specific requirements to run an WLST command, see note in Section 10.3, "Managing Application Policies with WLST commands." For usage details, see Examples of Use.

To migrate all policies (system and application-specific, for all applications) on WebLogic use the script (first) or interactive (second) syntax (arguments are written in separate lines for clarity):

migrateSecurityStore.py -type policyStore
                        -configFile jpsConfigFileLocation
                        -src srcJpsContext
                        -dst dstJpsContext
migrateSecurityStore(type="policyStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")
                     

The meanings of the arguments (all required) are as follows:

  • configFile specifies the location of a configuration file relative to the directory where the script is run. This configuration file should be specially assembled and must contain the following elements:

    • a context specifying the source store

    • a context specifying the destination store

    • a context specifying the bootstrap credentials

    The bootstrap context refers to the location of a cwallet.sso file where the keys needed to access the source and destination stores, and to decrypt and encrypt security data in them are expected to be.

    For information about extracting keys used by a domain, see exportEncryptionKey; for information about storing a key into a wallet, see importEncryptionKey.

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

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

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

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

To migrate just system policies on WebLogic, use the script (first) or interactive (second) syntaxes (arguments are written in separate lines for clarity):

migrateSecurityStore.py -type globalPolicies
                        -configFile jpsConfigFileLocation
                        -src srcJpsContext
                        -dst dstJpsContext
migrateSecurityStore(type="globalPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")

The meanings of the arguments (all required) are identical to the previous case.

To migrate just application-specific policies on WebLogic, for one application, use the script (first) or interactive (second) syntaxes (arguments are written in separate lines for clarity):

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

The meanings of the arguments configFile, src, and dst are identical to the previous cases. The meaning of other five arguments is as follows:

  • srcApp specifies the name of the source application, that is, the application whose policies are being migrated.

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

  • migrateIdStoreMapping specifies whether enterprise policies should be migrated. The default value is True. To filter out enterprise policies from the migration, that is, to migrate just application policies, set it to False.

  • 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, defaults to false.

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

If the input does not follow the syntax requirements above, the script execution fails and returns an error. In particular, the input must satisfy the following requisites: (a) the file jps-config.xml is found in the passed location; (b) the file jps-config.xml includes the passed jps-contexts; and (c) the source and the destination context names are distinct.

To migrate all credentials use either of the script (first) or interactive (second) syntaxes (arguments are written in separate lines for clarity):

migrateSecurityStore.py -type credStore
                        -configFile jpsConfigFileLocation
                        -src srcJpsContext
                        -dst dstJpsContext

migrateSecurityStore(type="credStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")

The meanings of the arguments configFile, src, and dst are identical to the previous case.

To migrate just one credential map, use either of the script (first) or interactive (second) syntaxes (arguments are written in separate lines for clarity):

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

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

The meanings of the arguments configFile, src, and dst are identical to the previous case. The meanings of the last four arguments (all optional) are as follows:

  • srcFolder specifies the name of the map containing the credentials to be migrated. Optional. If unspecified, 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, 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, it defaults to the value passed to configFile; if specified, 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 not specified, defaults to false. When set to false, if a matching is detected, the source credential is disregarded and a warning is logged.

9.6.2.1 Migrating Audit Metadata

You can use the script migrateSecurityStore to migrate audit metadata into a domain security store, or migrate audit metadata into an XML file.

See Section 6.6.3 for details.

9.7 Configuring Services Providers with Fusion Middleware Control

This section explains how to use Fusion Middleware Control to configure several service providers in the following sections:

Note:

The area of the Security Provider Configuration page labeled Web Services Manager Authentication Providers pertains to the configuration of Login Modules and the Keystore for Web Services Manager only and is not relevant to ADF or Java EE applications.

To configure policies, credentials, keys, and audit, see the following sections:

9.7.1 Configuring the Identity Store Provider

To configure the parameters used by the User and Role API that interact with the identity store, proceed as follows:

  1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration to display the Security Provider Configuration page.

  2. Expand, if necessary, the area Identity Store Provider, and click Configure to display the page Identity Store Configuration.

  3. Manage custom properties, as appropriate, using the buttons Add and Delete.

  4. When finished, click OK to save your settings and to return to the Security Provider Configuration page.

9.7.2 Configuring the Single Sign-On Provider

To configure the SSO provider used by a domain, proceed as follows:

  1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration to display the Security Provider Configuration page.

  2. In that page, click the Configure in the Single Sign-On Provider area to display the Single Sign-On Provider page.

  3. In that page, check the box Configure Single Sign-On, to allow entering data for the provider. All boxes are grayed out until this box is checked.

  4. Select the Store Type from the pull-down list, and enter the corresponding data for the selected provider (the data required changes with the type selected).

  5. Enter the Login URL, Autologin URL, and Logout URL in the text boxes.

  6. Select the Authentication Level from the pull-down list.

  7. Optionally, manage the provider Custom Properties using the buttons Add, Edit, and Delete, at the bottom of the page.

  8. When finished, click OK to save the entered data.

9.7.3 Configuring the Trust Service Provider

To configure the trust service provider used by a domain, proceed as follows:

  1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration to display the Security Provider Configuration page.

  2. In that page, the Trust Service Provider area shows whether the service is configured; to configure the service, click the Configure to display the Trust Service Provider page.

  3. That page contains the following areas:

    • Provider, where the name of the chosen provider is displayed.

    • Trust Store, where you select a stripe and a trust store, from the available ones.

    • Keystore and Alias, where you select a certificate by picking a stripe and a keystore, and an alias from the list of available trust aliases. The read-only entries at the bottom of the area (Issuer Name and Expiration Date) give information about the certificate selected.

    • Trust Service Configuration, where you enter the following values:

      • Clock Skew, the number of seconds that the clocks of the two systems (involved in the use of the trust service) may differ; the default is 60.

      • Token Validity Period, the number of seconds that the token is valid; the default is 1800.

      • Include Certificate, a boolean stating whether the certificate should be included in the token.

    • Codesource Permission, specifying the URL of the client code (that will access the trust store); no default value provided; this information translates into a codesource permission granted to the specified code.

  4. Click OK to save the entered data and to return to the Security Provider Configuration page; the values you entered are saved in the file $DOMAIN_HOME/config/fmwconfig/jps-config.xml.

9.7.4 Configuring Properties and Property Sets

A property set is collection of properties typically used to define the properties of a service instance or generic properties of the domain.

For a list of OPSS configuration properties, see Appendix F, "OPSS Configuration Properties."

The elements <property> and <properySet> in the file $DOMAIN_HOME/config/fmwconfig/jps-config.xml are used to define property and property sets. Property sets can be referenced by the element <propertySetRef>.

To define a property or a property set, proceed as follows:

  1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration to display the Security Provider Configuration page.

  2. Expand, if necessary, the area Advanced Properties, and click Configure to display the Advanced Properties page.

  3. To enter a property, click Add in the Properties area to display the dialog Add New Property, and enter a property name and value. When finished, click OK. The entered property appears on the Properties table.

  4. To enter a property set, click Add Property Set in the Property Sets area to display the dialog Add Property Set, and enter the property set name.

  5. To enter a property in a property set, select a property set from the existing ones, then click Add Property to display the dialog Add New Property, and then enter a property name and value. The entered property is added to the list of properties in the selected property set.

  6. Use the button Delete to remove a selected item from any table. When finished entering or editing properties and property sets, click OK.

  7. Restart the Oracle WebLogic Server. Changes do not take effect until the server has been restarted.

The addition or deletion of property sets modifies the domain configuration file $DOMAIN_HOME/config/fmwconfig/jps-config.xml; the changes do not take effect until the server is restarted.

The elements <property> and <propertySet> added by the previous procedure are inserted directly under the element <jpsConfig>.