Skip Headers
Oracle® Fusion Middleware Application Security Guide
11g Release 1 (11.1.1)

Part Number E10043-12
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

8 Configuring the OPSS Security Store

The OPSS security store is the repository of system and application-specific policies, credentials, and keys. For an introduction to policies, credentials, keys and certificates, see the following sections:

This chapter explains the features of the OPSS security store common to policies, credentials, and keys, and it is divided into the following sections:

For details about Java EE and WebLogic Security, see section Java EE and WebLogic Security in Oracle Fusion Middleware 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.

8.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 file-based.

The security data relevant to a Java EE application is typically packaged with the application and it 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.

8.2 Using an LDAP-Based OPSS Security Store

An LDAP-based policy store is typically used in production environments. The only LDAP server supported in this release 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.0

  • Patch to fix bug 8351672 in Oracle Internet Directory 10.1.4.3.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 OPSS scripts.

Important:

OPSS does not support enabling referencial integrity on Oracle Internet Directory servers. The server will not work as expected if referencial integrity is enabled.

To disable a server's referencial 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 referencial 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."

The information in this section is divided into the following topics:

8.2.1 Multiple-Node Server Environments

In domains where several server instances are distributed across multiple machines, it is highly recommended that the OPSS security store be LDAP- or DB-based.

Typically, applications do not change policy, credential, or key data. When they do, however, it is crucial that these changes be correctly propagated to all managed servers and clusters in a domain and, therefore, it is recommended that any such changes be performed in the domain administration server (and not in managed servers).

In a single-node server domain, the propagation of local changes to security data is irrelevant: in this scenario, local changes are equivalent to global changes.

In a multiple-node server domain, however, the JMX framework propagates local changes to a file-based policy to each runtime environment, so that the data is refreshed based on caching policies and configuration. For details about properties you can set on policies and credentials, see sections Appendix F, "Policy Store Properties," and Appendix F, "Credential Store Properties."

In a multiple-node server environment, it is highly recommended that both the policy and credential stores be centralized in a LDAP- or DB-based store and configured in the administration server.

8.2.2 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 21.4.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 the LDAP Oracle Internet Directory 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 User Reference for Oracle Identity Management.

    To reassociate a policy store, see Reassociating the OPSS Security Store.

8.2.3 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 Oracle Fusion Middleware Administrator's Guide.

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

    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 policy 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 same for both the identity and the policy store services.

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

    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>
    

8.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 is Oracle RDBMS (releases 10.2.0.4 or later; releases 11.1.0.7 or later; and releases 11.2.0.1 or later).

To use a DB-based OPSS security store the domain administrator must configure it, as appropriate, using Oracle Enterprise Manager Fusion Middleware Control or OPSS scripts. In case any checks are needed before the server completes its initialization, see Section L.14, "Permission Failure Before Server Starts."

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

This section contains the following topics:

8.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. This setup is also required before reassociating the OPSS security store to a DB-based security store.

For details about RCU, see chapters Repository Creation Utility Overview and Running Repository Creation Utility in Oracle Fusion Middleware Repository Creation Utility User's Guide.

The creation the schema and seeding of initial data are explained in the following sections:

8.3.1.1 Creating the OPSS Schema in an Oracle Database

To create the OPSS schema in an Oracle database with RCU, proceed as follows:

  1. Start RCU to display the RCU Welcome page; in this page, click Next to display the Create Repository page.

  2. In that page, select the radio button Create; then click Next to display the Database Connections Details page.

  3. In that page, enter the appropriate connectivity information: Database Type, Host Name, Port, Service Name, Username, Password, and Role.

    Then click Next to have RCU check the entered data and perform pre-creation operations; once this check is successfully completed, RCU displays the Select Components dialog.

  4. In that dialog, choose to use an existing schema prefix or create a new prefix, and pick the OPSS component to install the schema.

    When finished selecting components, click Next to display the Schema Passwords dialog where you supply passwords, and then click Next to display the Map Tablespaces dialog which shows the tablespace summary. Use one default tablespace and one temporary tablespace; the default tablespace names are PREFIX_IAS_OPSS and PREFIX_IAS_TEMP, respectively.

    To create a non-default tablespace or datafile, click the button Manage Tablespaces to display the Manage Tablespaces dialog, where you can specify the information to create them. When finished, click OK. If the specified tablespaces are not yet in the database, RCU creates them and informs about this in the Creating Tablespaces; click OK to display the Summary dialog, which displays the summary of data you have entered, and then click Create to effect the creation of the additional tablespace(s) or datafile(s).

  5. When the creation is completed, RCU displays the Completion Summary, which shows the database details.

  6. Invoke the SQLPlus command illustrated below to verify that the database schema has been properly created:

    SQL> desc jps_dn;
    

8.3.1.2 Dropping the OPSS Schema in an Oracle Database

Dropping the OPSS schema is required only if one no longer wishes to use that DB for storing OPSS security policies.

After the OPSS schema has been successfully created, use RCU to drop the OPSS schema as follows:

  1. Start RCU to display the RCU Welcome page; in this page, click Next to display the Drop Repository page.

  2. In that page, select the radio button Drop; then click Next to display the Database Connections Details page.

  3. In that page, enter the appropriate connectivity information: Database Type, Host Name, Port, Service Name, Username, Password, and Role. Then click Next to display the Select Components dialog.

  4. In that dialog, select the prefix and, in the Component hierarchy, check AS Common Schemas and Oracle Platform Security Services; then click Next to display the Summary page.

  5. In that page, verify that the details gathered are correct, and click Drop to trigger the dropping; when the operation is successfully completed, RCU displays the Completion Summary page detailing the schema dropped.

8.3.1.3 Creating a Data Source Instance

To create a JDBC data source in a WebLogic domain using the Oracle WebLogic Administration Console, proceed as follows:

  1. Login to the Console and navigate to Services > DataSources and select New > Generic Data Source.

  2. Enter the JNDI Name and then click Next. Note that this name is used when configuring a DB-based store in the file jps-config.xml.

  3. In the Database Driver pull-down, select Oracle's Driver (Thin) for Instance connections; Versions:9.0.1 and later (this is a non-XA JDBC driver) and then click Next.

  4. Make sure that Supports Global Transactions is deselected and then click Next.

  5. In the area Connection Properties, enter data for Database Name, Host Name, Port, Database User Name, and Password. Then click Next.

  6. Inspect and test your settings and, when satisfied, click Finish.

  7. Deploy the just created data source on the appropriate server.

For more details on the above procedure, see section Creating a JDBC Data Source in Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server.

To set up a data source on WebSphere Application Server, see Oracle Fusion Middleware Third-Party Application Server Guide.

Note:

11.2 Oracle JDBC driver deprecated the following time zones: Etc/UCT, UCT, Etc/UTC, Etc/Universal, Etc/Zulu, and Universal. When setting a time zone for your Oracle JDBC driver, make sure that it is a non-deprecated time zone.

8.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 during the RCU setup (see section Creating the OPSS Schema in an Oracle Database). 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);

8.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 Oracle Fusion Middleware Administrator's Guide .

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

8.4 Configuring the OPSS Security Store

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

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

For details about configuring other artifacts, see Configuring the Identity Provider, Property Sets, and SSO.

8.5 Reassociating the OPSS Security Store

Reassociating the OPSS security store consists in relocating the policy, credential, and key stores 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 DB_ORACLE.

Reassociation changes the repository preserving the integrity of the data stored. For each security artifact, reassociation searches the target store and, if it finds a match for it, it updates the matching artifact; otherwise, creates a new artifact.

Reassociation is typically performed, for example, when setting a domain to use an LDAP- or DB-based OPSS store instead of the out-of-the-box file-based store. This operation can take place at any time after the OPSS store has been configured and instantiated, and it is carried out using either Fusion Middleware Control or reassociateSecurityStore as explained in the following sections:

8.5.1 Reassociating with Fusion Middleware Control

Reassociation migrates the OPSS policy store (policies, credentials, and keys) 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 the Identity Provider, Property Sets, and SSO.

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 (if connected to Oracle WebLogic Server) or to Cell > Security > Security Provider Configuration (if connected to WebSphere Application Server), 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; see Creating a Data Source Instance for details. 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 L.9, "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 L.2, "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.

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

8.5.2 Reassociating with the Script reassociateSecurityStore

The OPSS store can be reassociated with the OPSS script reassociateSecurityStore. For details, see Section 9.3.29, "reassociateSecurityStore."

8.6 Migrating the OPSS Security Store

A domain includes one and only one policy store. Applications can specify their own policies, but these are stored as policies in the policy store when the application is deployed to a server. All applications deployed in a domain use a common policy store, the policy store. The policy 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 consists in relocating the policy, credential, and key stores 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 policy store must have compatible versions; for details, see Section L.21, "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 policy 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 in 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.

8.6.1 Migrating with Fusion Middleware Control

Application policies are specified in the application file jazn-data.xml and can be migrated to the policy store when the application is deployed to a server in the WebLogic environment with Fusion Middleware Control; they can also be removed from the policy 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.5.2, "Migrating Policies and Credentials at Deployment."

8.6.2 Migrating with the Script migrateSecurityStore

Application-specific policies or system policies can be migrated manually from a source repository to a target repository using the OPSS script 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.5.2.3, "Migrating Large Volume Policy and Credential Stores.".

For further details about OPSS scripts and their syntax, see section Overview of WLST Command Categories, in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

For platform-specific requirements to run an OPSS script, see Important Note.

To migrate all policies (system and application-specific, for all applications) on WebLogic use the script (first) or interactive (second) syntaxes (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 jps-config.xml relative to the directory where the script is run. Typically, this configuration file is created just to be used with the script and serves no other purpose. This files contains two jps-contexts that specify the source and destination stores.

    In addition, if the migration involves one or two LDAP-based stores, then this file must contain a bootstrap jps-context that refers to the location of a cwallet.sso file where the credentials to access the LDAP based involved in the migration are kept.

  • src specifies the name of a jps-context in the configuration file passed to the argument configFile.

  • dst specifies the name of another jps-context in the configuration file passed to the argument configFile.

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.

8.6.2.1 Examples of Use

For complete examples illustrating the use of this script, see Section 6.5.2.1, "Migrating Policies Manually."

8.7 Configuring the Identity Provider, Property Sets, and SSO

This section explains how to use Fusion Middleware Control to configure parameters used by the User and Role APIs, property and property sets, and to specify the Single Sign-On Provider, in the following sections:

Note:

The area of the page Security Provider Configuration 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.

For details about the login modules available, their parameters, and the keystore for those components, see chapter 9 in Oracle Fusion Middleware Security and Administrator's Guide for Oracle Web Services.

8.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, or to Cell > 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.

8.7.2 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, or to Cell > 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, in which you can enter properties and property sets.

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

8.7.3 Specifying a Single Sign-On Solution

This section explains the OPSS Single Sign-On (SSO) Framework and how to configure an SSO solution using Fusion Middleware Control, in the following sections:

8.7.3.1 The OPSS SSO Framework

The OPSS SSO Framework provides a way to integrate applications in a domain with an SSO solution. Specifically, it provides applications a common set of APIs across SSO products, to handle login, logout and auto login.

One of these solutions, the OAM solution, is available out-of-the-box, and it includes the following features:

  • Dynamic authentication - Upon accessing a part of a secured artifact that requires authentication, the application triggers authentication and redirects the user to be authenticated by the appropriate solution.

  • Auto login - A user who has initially accessed an application anonymously registers an account with the application; upon a successful registration, the user is redirected to the authentication URL; the user can also be automatically logged in without being prompted.

  • Global logout - When a user logs out of one application, the logout propagates across to any other application that is enabled by the solution.

For a configuration example of an OAM solution, see OAM Configuration Example.

An SSO solution must provide a standard way for applications to login and logout users. After successful authentication, the SSO service is responsible to redirect the user to the appropriate URL.It is assumed that the domain where the solution is applied has been configured to allow the Subject to contain the anonymous user and role before login and after logout, and authenticated roles after login. It is also assumed that the SSO provider has implemented a Credential Mapping Service. In the case of the out-of-the-box OAM solution, the provider implements CredentialMapperService that produces the appropriate OAM token.

The OPSS SSO framework does not support multi-level authentication.

Integration with the desired SSO solution requires a separate installation and appropriate configuration of the solution. For details about recommended solutions, see Part IV, "Single Sign-On Configuration".

8.7.3.2 Configuring an SSO Solution with Fusion Middleware Control

To specify the SSO solution used by a domain, proceed as follows:

  1. Log in to Fusion Middleware Control and navigate to Domain > Security > Security Provider Configuration or Cell > 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 Provider Type from the pull-down list, and enter the corresponding data for the selected provider (the data required changes with the type selected).

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

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

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

8.7.3.3 OAM Configuration Example

The SSO service configuration entered with the procedure described in Configuring an SSO Solution with Fusion Middleware Control is written to the file jps-config.xml. The data specified includes:

  • A particular SSO service

  • The auto-login and auto-logout URIs

  • The authentication level

  • The query parameters contained in the URLs returned by the selected SSO service

  • The appropriate settings for token generation

The following fragment of a jps-config.xml file illustrates the configuration of an OAM SSO provider:

<propertySets>
  <propertySet name = "props.auth.url">
    <property name = "login.url.BASIC" value = "http://host:port/oam_login.cgi?level=BASIC"/>
    <property name = "login.url.FORM" value = "http://host:port/oam_login.cgi?level=FORM"/>
    <property name = "login.url.DIGEST" value = "http://host:port/oam_login.cgi?level= DIGEST"/>
    <property name = "autologin.url" value = " http://host:port/obrar.cgi"/>
    <property name = "logout.url" value = "http://host:port/logout.cgi"/>
    <property name = "param.login.successurl"  value = "successurl"/>
    <property name = "param.login.cancelurl"   value = "cancelurl"/>
    <property name = "param.autologin.targeturl" value = "redirectto"/>
    <property name = "param.autologin.token"   value = "cookie"/>
    <property name = "param.logout.targeturl"   value = "targeturl"/>
  </propertySet>

  <propertySet name="props.auth.uri">
    <property name="login.url.BASIC" value="/${app.context}/adfauthentication?level=BASIC" /> 
    <property name="login.url.FORM" value="/${app.context}/adfauthentication?level=FORM" /> 
    <property name="login.url.DIGEST" value="/${app.context}/adfauthentication?level=DIGEST" /> 
    <property name="autologin.url" value="/obrar.cgi" /> 
    <property name="logout.url" value="/${app.context}/adfauthentication?logout=true" /> 
  </propertySet>

  <propertySet name = "props.auth.level">
    <property name = "level.anonymous" value = "0"/>
    <property name = "level.BASIC"    value = "1"/>
    <property name = "level.FORM"    value = "2"/>
    <property name = "level.DIGEST"   value = "3"/>
  </propertySet>
<propertySets>

<serviceProviders>
  <serviceProvider name = "sso.provider"
    class = "oracle.security.jps.internal.sso.SsoServiceProvider" 
    type = "SSO">
    <description>SSO service provider</description>
  </serviceProvider>
</serviceProviders>

<serviceInstances>
  <serviceInstance name = "sso" provider = "sso.provider">
    <propertySetRef ref = "props.auth.url"/>
    <propertySetRef ref = "props.auth.level"/>
    <property name = "default.auth.level" value = "2"/>
    <property name = "token.type" value = "OAMSSOToken"/>
    <property name = "token.provider.class" value = "oracle.security.jps.wls.internal.sso.WlsTokenProvider"/>
    <property name="sso.provider.class" value="oracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImpl"/>
  </serviceInstance>
</serviceInstances>

<jpsContexts default = "default">
  <jpsContext name = "default">
    <serviceInstanceRef ref = "sso"/>
  </jpsContext>
</jpsContexts>

Table 8-1 describes the meaning of the properties involved in the configuration of an SSO provider.

Table 8-1 SSO Provider Properties

Property Name Description

logout.url

The SSO provider logout URL.

login.url.BASIC

The SSO provider BASIC logout URL.

login.url.FORM

The SSO provider FORM logout URL.

login.url.DIGEST

The SSO provider DIGEST logout URL.

autologin.url

The self-registration URL for auto-login.

logout.url

The SSO provider logout URL.

param.login.successurl

The URL redirect after a succesful login.

param.login.cancelurl

The URL redirect after a query cancelation.

param.autologin.targeturl

The URL redirect after auto-login.

param.autologin.token

The token for auto-login.

param.logout.targeturl

The URL redirect after loggin out.


Regarding the configuration of an SSO provider, note the following important remarks:

  • Any SSO provider must define the URI for at least the FORM login with the property login.url.FORM. The value need not be a URL.

  • If the application supports a self-registration page URI or URL, it must be specified with the property autologin.url.

  • If the SSO solution supports a global logout URI or URL, it must be specified with the property logout.url. The OAM solution supports global logout.

  • The following properties, illustrated in the preceding example, are optional:

    • param.login.successurl

    • param.login.cancelurl

    • param.autologin.targeturl

    • param.login.token

    • param.logout.targeturl

  • The use of the variable app.context in URI specifications, illustrated in values within the property set props.auth.uri in the preceding example, is allowed for only ADF applications when integrating with the OAM solution.

  • The property set props.auth.level is required.

  • The reference to props.auth.url is required.

  • The property sso.provider.class within a service instance of the SSO provider is the fully qualified name of the class implementing a specific SSO solution.

    In the case of the OAM solution, the provided class name is oracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImpl.

  • The property name default.auth.level within a service instance of the SSO provider must be set to 2, as illustrated in the preceding example.

  • The property token.type within a service instance of the SSO provider is required.

    This token type identifies the token set on the HTTP request by the SSO provider upon a successful authentication; the SSO provider uses this token, after the first time, to ensure that the user does not need to be reauthenticated and that his sign-on is still valid. In the case of the OAM solution, the token type must be OAMSSOToken, as illustrated in the preceding example.

  • The property token.provider.class within a service instance of the SSO provider is the fully qualified name of the token class, and it is provider-specific.

  • If an application implements a self-registration logic and wants to auto login a user after successful self-registration, it must call the OPSS autoLogin API; in turn, to allow this call, it must grant that application a code source permission named CredentialMapping with class JpsPermission.

    The following fragment of the file system-jazn-data.xml illustrates the specification of this permission to the application MyApp:

    <grant>
      <grantee>
        <codesource>
         <url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}
         </url>
        </codesource>
      </grantee>
      <permissions>
        <permission>
          <class>oracle.security.jps.JpsPermission</class>
          <name>CredentialMapping</name>
        </permission>
      </permissions>
    </grant>
    

    Note the use of system variables in the URL specification. For details, see Example in <url>.