Querying the Identity Store Programmatically

Configuring the OPSS Security Store 8-3 For a list of properties that can be specified in a service instance, see Appendix F.2.4, Properties Common to All LDAP-Based Instances. The information in this section is divided into the following topics: ■ Multiple-Node Server Environments ■ Prerequisites to Using an LDAP-Based Security Store

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.2.1, Policy Store Properties, and Appendix F.2.2, Credential Store Properties. To summarize, in a multiple-node server environment, it is highly recommended that: ■ Both the policy and credential stores be centralized in a LDAP-based store and configured in the administration server. ■ Or, if they are file-based, then local changes to policy or credential data be performed only by the domain administration server to ensure that they are correctly propagated from the administration server to all managed servers in the domain.

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 8-4 Oracle Fusion Middleware Application Security Guide 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_HOMEldapadminoidstats.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.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. For a list of properties that can be configured, see Appendix F.2, OPSS Configuration Properties. This section contains the following topics: ■ Prerequisites to Using a DB-Based Security Store ■ Maintaining a DB-Based Security Store ■ Setting Up an SSL Connection to the DB

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. Configuring the OPSS Security Store 8-5 For details about RCU, see chapters Repository Creation Utility Overview and Running Repository Creation Utility in Oracle Fusion Middleware Repository Creation Utility Users Guide. The creation the schema and seeding of initial data are explained in the following sections: ■ Creating the OPSS Schema in an Oracle Database ■ Dropping the OPSS Schema in an Oracle Database ■ Creating a Data Source Instance

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 tablespaces or datafiles.

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: 8-6 Oracle Fusion Middleware Application Security Guide

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 data source instance, see section Creating a JDBC Data Source in Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server. The JNDI name of the JDBC data source entered in the procedure in that section is used in the configuration of a DB-based store. To set up a data source on WebSphere Application Server, see Oracle Fusion Middleware Third-Party Application Server Guide.

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: SQLdelete from jps_changelog where createdate selectmaxcreatedate - 1 from jps_changelog; SQLCommit; 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: Note: 11.2 Oracle JDBC driver deprecated the following time zones: EtcUCT, UCT, EtcUTC, EtcUniversal, EtcZulu, and Universal. When setting a time zone for your Oracle JDBC driver, make sure that it is a non-deprecated time zone.