3 Managing Data Sources

This chapter describes the steps to register and administer data sources in the Oracle Access Manager Administration Console. This chapter includes the following topics:

Prerequisites

This section identifies requirements for tasks in this chapter. Before you begin tasks in this chapter, be sure to review the following topics:

Introduction to Managing Data Sources

Various types of data must be managed for Oracle Access Manager 11g, as described in following topics:

See Also:

  • Chapter 12 for details about session data stored in-memory using Oracle Coherence and propagated to Oracle Database

  • Chapter 14 for details about Audit data is stored within audit files or a separate Oracle Database (not the policy store)

About User Identity Stores

OAM administrator and user identities are stored within an LDAP user identity store for use during authentication and authorization.

A User Identity Store is a centralized LDAP store in which an aggregation of administrator and user-oriented data is kept and maintained in an organized way.

Only user and group identity data are stored in the centralized LDAP store. Only the Primary user identity store can be used to authenticate:

  • Administrators signing in to use the OAM Administration Console, remote registration, and custom administrative commands for OAM 11g in WLST

  • Users attempting to access an OAM-protected resource

In the OAM 11g Administration Console, User Identity Store registrations are organized under the Data Sources node of the System Configuration tab. Administrators can register, view, modify, and delete User Identity Store registrations using either the OAM Administration Console or custom WLST commands for OAM 11g.

During initial WebLogic Server domain configuration using the Oracle Fusion Middleware Configuration Wizard, the embedded LDAP is configured as the one and only user identity store.

Note:

The embedded LDAP performs best with fewer than 10,000 users. With more users, consider a separate enterprise LDAP server.

Within the embedded LDAP, the Administrators group is created with "weblogic" is seeded as the default administrator.

See Also:

Oracle Fusion Middleware Securing Oracle WebLogic Server Part Number E13707-01

Administrators can define multiple user identity stores for OAM 11g. Each identity store can rely on a different LDAP provider. External LDAP repositories can provide user, role, and group membership information to be used when evaluating policies during authentication and authorization. After installing and configuring an enterprise LDAP directory server, the administrator must register it with OAM 11g to ensure connectivity with Oracle Access Manager servers.

After registering the identity store, administrators can reference it in one or more authentication modules that form the basis for authentication schemes.

Note:

Only the Primary user identity store is used for administrator and user authentication.

For more information, see "About the User Identity Store Registration Page".

See Also:

Appendix F, "Introduction to Custom WLST Commands for OAM Administrators"

About the OAM Policy and Session Data Store

OAM 11g requires a database to store OAM policy data and (optionally) OAM user session data.

The policy database must be installed according to vendor instructions, and extended with the OAM-specific schema using RCU, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management. Running the Oracle Access Manager with Database Policy Store configuration template automatically prepares the database to store OAM 11g policy and session data.

The database is specified for Oracle Access Manager 11g during initial configuration in a Oracle WebLogic Server domain using the Oracle Fusion Middleware Configuration Wizard.

Note:

Your OAM 11g deployment can have one policy and one session store, at most. By default, a single JDBC data source is used for both.

The following data is maintained:

  • Policy data, including authentication modules and schemes, application domains, authentication and authorization policies.

  • Session data, as a persistent backup to distributed in-memory storage

    An administrator must extend the database with the OAM-specific schema.

For more information, see "Managing the Database by Using the OAM Administration Console".

Note:

The preferred mode for audit data storage in production environments is writing audit records to a stand-alone RDBMS database for audit data only. This is done using a separately configured audit store. The policy store is not used for audit data.

About the OAM Configuration Data File

Oracle Access Manager provides an XML file (oam-config.xml) containing all OAM-related system configuration data. Each OAM Server has a local copy of the latest configuration XML file.

Any changes that are made to the OAM deployment configuration, including server and agent registration, are stored in the oam-config.xml file and are automatically propagated to each OAM Server.

Note:

The oam-config.xml file should not be edited. Changes could result in lost data or overwriting of the file during data synch operations.

Whether you have fail over configured in a high-availability environment, or not, all OAM Servers always have the latest oam-config.xml file.

About Security Keys and the Embedded Java Key Store

The preferred keystore format is JKS (Java KeyStore). A Java keystore is associated with OAM 11g behind the scenes and is used to store cryptographic security keys that are generated to encrypt agent traffic and session tokens.

  • Every OAM and OSSO Agent has a secret key that other agents cannot read.

  • There is also a key to encrypt Oracle Coherence-based session management traffic.

  • During agent and partner (application) registration, a key is generated that is used for encrypting and decrypting SSO Cookies (ObSSOCookie for WebGates and mod_osso cookie).

Table 3-1 compares the cryptographic keys generated by OAM 11g, 10g, and OSSO 10g, as well as a brief description of there each is stored.

Table 3-1 Key Comparison


 OAM 11g OAM 10g OSSO 10g

Cryptographic keys

  • One per agent secret key shared between WebGate and OAM Server

  • One OAM Server key

  • 11g WebGate: OAMAuthnCookie

  • 10g WebGate: ObSSOCookie

One global shared secret key for all OAM WebGates

  • One key per partner shared between mod_osso and OSSO server

  • OSSO server's own key

  • One global key per OSSO setup for the GITO domain cookie

Keys storage

  • Agent side: A per agent key is stored locally in the Oracle Secret Store in a wallet file

  • OAM 11g server side: A per agent key, and server key, are stored in the credential store on the server side

Global shared secret stored in the directory server only (not accessible to WebGate)

  • mod_osso side: partner keys and GITO global key stored locally in obfuscated configuration file

  • OSSO server side: partner keys, GITO global key, and server key are all stored in the directory server

Note:

The key store is not available through the console and cannot be viewed, managed, or modified.

Managing User Identity Store and OAM Administrator Registrations

This section provides the steps you need to manage user identity store registrations using the OAM 11g Administration Console.

About the User Identity Store Registration Page

This topic describes the various user identity store settings under the System Configuration tab.

Figure 3-1 Create User Identity Store Page for Embedded LDAP

Surrounding text describes Figure 3-1 .

Figure 3-2 illustrates a completed user identity store registration page in the Administration Console. With the exception of the Embedded LDAP store, all registrations require the same type of information regardless of the LDAP directory server you are registering. A Test Connection button appears at the top of this page. By default, the embedded LDAP store is set as the Primary user identity store. If a data source is not set as primary, the Set As Primary button is available.

Figure 3-2 Completed User Identity Store Registration for Oracle Internet Directory

User Identity Store Definition
Description of "Figure 3-2 Completed User Identity Store Registration for Oracle Internet Directory"

Required settings are identified by the asterisk (*). Table 3-2 describes each element and is organized by element types.

Table 3-2 Required User Identity Store Elements

Elements Description

Name

A unique name for this registration. Use up to 30 characters for the name.
 

Location and Credentials

LDAP URL

The URL for the LDAP host, including the port number.

For example, the default embedded LDAP host might be:

ldap://localhost:7001

You can also specify ldaps://, which supports SSL_NO_AUTH.

Principal

The user DN for the connection pool over which all other BINDs occur. Oracle recommends a non administrative user with appropriate Read and Search privileges for the user and group base DNs.

For example:

uid=amldapuser,ou=people,o=org

credential

The password of the Principal, which is encrypted for security.
 

Connection Details

Connection Pool Size

The initial size set for the connection pool.

Connection Wait Timeout

The number (in seconds) that connection requests can wait before timing out in the event of a fully utilized pool.

Connection Pool Retry Count

The number of time that the connection is retried when there is a connection failure.

Search Time Limit

The time limit for LDAP searches and bind operations on the connection pool.

Default: 0

Referral Policy

One of these values:

  • follow: Follows referrals during an LDAP search

  • ignore: Ignores referral entries during an LDAP search

  • throw: Results in a ReferralException, which can be caught by the component user.
 

Users

User Name Attribute

The attribute that identifies the username.

For example:

uid

User Search Base

The node in the directory information tree (DIT) under which user data is stored, and the highest possible base for all user data searches.

For example:

ou=people,ou=myrealm,dc=base_domain

User Filter Object Class

The object classes to be included in search results for users, in a comma-separated list of user object class names. For example: user,person.
 

Groups

Group Name Attribute

The attribute that identifies the group name.

Default: cn

Group Search Base

Currently only static groups are supported, with the uniquemember attribute.

The node in the directory information tree (DIT) under which group data is stored, and the highest possible base for all group data searches.

For example:

ou=groups,ou=myrealm,dc=base_domain

Group Filter Object Class

The object classes to be included in the search results for groups, in a comma-separated list of group object classes. For example: groups,groupOfNames.
 

Group Caching

Group Cache Enabled

Boolean value for group cache: true or false.

Default: true

Group Cache Size

Integer for the group cache size.

Default: 10000

Group Cache TTL

Integer (in seconds) for Time to Live for group cache elements.

Default: 0

LDAP Provider

A list of all supported LDAP providers from which you can choose.

LDAP Provider List

Primary

Primary is checked only when this LDAP store is set as the primary User Identity Store (by clicking the Set as Primary button at the top of the registration page). Checking this option has no effect.

OAM Administrator's Role

The group defined within the primary user identity store that grants users full OAM system and policy configuration privileges.

Default Group = Administrators

Note: Specifying a different LDAP group prohibits WebLogic administrators from logging in to OAM.

See Also: "Introduction to OAM Administrators".

See Also:

Details about classifying users in Chapter 9, "Managing Policies to Protect Resources and Enable SSO"

Searching for a User Identity Store Registration

Users with valid OAM Administrator credentials can use this procedure to search for a user identity store using the Administration Console.

Prerequisites

The user identity store that you intend to register must be installed and running with appropriate users and groups and roles defined.

To search for a user identity store registration

  1. Activate the System Configuration tab.

  2. From the search type list, choose the User Identity Stores type to define your search.

  3. In the text field, enter the exact name of the instance you want to find. For example:

    my_user_identity_store

  4. Click the Search button to initiate the search.

  5. Click the Search Results tab to display the results table, and then:

    • Edit: Click the Edit command button in the tool bar to display the configuration page.

    • Delete: Click the Delete button in the tool bar to remove the instance; confirm removal in the Confirmation window.

    • Detach: Click Detach in the tool bar to expand the table to a full page.

    • View: Select a View menu item to alter the appearance of the results table.

  6. Click the Browse tab to return to the navigation tree when you finish with the Search results.

Registering a New User Identity Store

Users with valid OAM Administrator credentials can use this procedure to register a new user identity store using the Administration Console.

After you register the identity store, you can reference it in one or more authentication modules that form the basis for authentication schemes.

See Also:

"About the User Identity Store Registration Page"

Prerequisites

The user identity store that you intend to register must be installed and running.

To register a new user identity store definition

  1. From the System Configuration tab, navigation tree, expand the Data Source nodes.

  2. Click User Identity Stores.

  3. Click the Create command button in the tool bar.

  4. Add appropriate values for each element, as described in Table 3-2.

  5. Role Mapping: Enter the name of the LDAP group defined for OAM administrators within the user identity store (Table 3-2).

  6. Click Apply to submit the registration.

  7. Click Test Connection button to confirm connectivity, then close the Confirmation window.

  8. Close the registration page, then re-open it.

  9. Set as Primary: Click this button to set this LDAP store as the primary user identity store for authentication and authorization.

  10. Click Apply to submit the registration and close the page.

  11. Configure one or more authentication modules to use this store, as described in "Managing Authentication Modules".

Viewing or Editing a User Identity Store Registration

Users with valid OAM Administrator credentials can modify the registration of a user identity store.

To view or modify a user identity store registration

  1. From the System Configuration tab, navigation tree, expand the Data Sources node.

  2. Expand the User Identity Stores node.

  3. Double-click the name of the desired User Identity Store registration.

  4. Modify values as needed (see Table 3-2).

  5. Click Apply to update the registration (or close the page without applying changes).

  6. Click Test Connection button to confirm connectivity, then close the Confirmation window.

  7. Close the registration page, then re-open it.

  8. Set as Primary: Click this button to set this LDAP store as the primary user identity store for authentication and authorization.

  9. Close the page when you finish.

Deleting a User Identity Store Registration

Users with valid OAM Administrator credentials can use this procedure to delete a non-primary user identity store registration using the Administration Console.

Note:

You cannot delete the primary user identity store registration.

To delete a secondary user identity store registration

  1. Edit LDAP Authentication Modules that reference the store to be deleted (to ensure a valid identity store is referenced).

  2. From the System Configuration tab, navigation tree, expand the Data Sources node.

  3. Expand the User Identity Stores node.

  4. Optional: Double-click the desired instance name to confirm it is the one to delete and then close the page.

  5. Click the desired instance name and then click the Delete button in the tool bar.

  6. Click the Delete button in the Confirmation window (or click Cancel to dismiss the window and retain the instance).

  7. Confirm that the definition is no longer listed in the navigation tree.

Defining a New OAM Administrator Role

By default, the OAM Administrators role is the same as the WebLogic Administrators role (Administrators). However, OAM administrators can use the following procedure to define a new OAM administrator role which must be stored in the primary user identity store for OAM 11g.

To change the OAM Administrator role

  1. In the Primary user identity store for OAM:

    1. Define a different LDAP group to use for OAM Administrators.

    2. Ensure that your OAM Administrators group is available in the group search base.

  2. Log in to the OAM Administration Console and:

    1. Open the desired User Identity Store registration, as described in "Viewing or Editing a User Identity Store Registration".

    2. Modify the OAM Administrator role as needed (see Table 3-2).

    3. Apply the changes to this registration, test the connection, and close the page.

    4. Set as Primary: Re-open the registration page, click the Set as Primary button, and click Apply.

  3. Test the New Role: Close the browser window, then re-open it.

    1. Sign out of the OAM Administration Console and close the browser window.

    2. Start up the OAM Administration Console and attempt to log in using the previous OAM Administrator role to confirm that this attempt fails.

    3. Log in using the new OAM Administrator role to confirm that this attempt is successful.

Managing the Database by Using the OAM Administration Console

This section includes the following topics:

About Database Deployment for OAM 11g

Oracle requires a single database as the policy, which can also be used to store session data. Using the database as the session store provides greater scalability and fault-tolerance (against a power event taking all servers down). You can have up to one policy database and one session database.

During initial deployment using the WebLogic Configuration Wizard, the following database details are requested:

  • Database login ID and password

  • Database Service name and location

Using the WebLogic Configuration Wizard you can test the connection to the database. Also, the database is registered with OAM.

Basic schema creation occurs when the RCU is invoked. The RCU prepares the database to accept data for OAM 11g. Running the Oracle Access Manager with Database Policy Store configuration template automatically prepares the database to store OAM 11g policy and session data. Actual OAM policy elements are created the first time the WebLogic AdminServer is started with the OAM Administration Console deployed.

See Also:

Oracle Fusion Middleware Installation Guide for Oracle Identity Management

Note:

Only one database can be registered with OAM for use as a policy store. OAM includes a read-only oam-policy.xml file in the domain home. This file should not be edited directly. Changes can result in lost data or overwriting of the file during data synch operations.

Configuring a Separate Database for Session Data

Oracle Access Manager 11g includes a data source named "oamDS" which is configured against the database instance extended with the OAM Schema. The following pre-defined Java Naming and Directory Interface (JNDI) names are used by the OAM Server to refer the data source.

jdbc/oamds (used by both the policy layer and session layer to access database)

You can use the following procedure to create a separate database instance for session data using the WebLogic Administration Console. There is no support for this action in the OAM Administration Console.

To create and use an independent database for session data

  1. Install and configure the database for session data and then use RCU with the OAM-specific schema to set up the database as a session data store.

  2. Create a new Data Source instance for session data:

    1. From the WebLogic Administration Console, Domain Structure panel, expand the domain name, Services node.

    2. Expand JDBC, Data Source.

    3. Create a new Data Source with the JNDI name jdbc/oamsession.

    4. Save the changes.

    5. Stop the OAM Servers and the AdminServer to avoid potential loss of data during the next step.

    6. In oam-config.xml, edit the value of the DataSourceName attribute to the one configured in step 1. For example:

      domain-home/config/fmwconfig/oam-config.xml

      From:

      <Setting Name="SmeDb" Type="htf:map">
  <Setting Name="URL" Type="xsd:string">jdbc:oracle:thin://amdb.example.
    com:2001/AM</Setting>
  <Setting Name="Principal" Type="xsd:string">amuser</Setting>
  <Setting Name="Password" Type="xsd:string">password</Setting>
  <Setting Name="DataSourceName" Type="xsd:string">jdbc/oamds</Setting>
</Setting>

      To:

      <Setting Name="SmeDb" Type="htf:map">
  <Setting Name="URL" Type="xsd:string">jdbc:oracle:thin://amdb.example.
    com:2001/AM</Setting>
  <Setting Name="Principal" Type="xsd:string">amuser</Setting>
  <Setting Name="Password" Type="xsd:string">password</Setting>
  <Setting Name="DataSourceName" Type="xsd:string">jdbc/oamsession</Setting>
</Setting>

  3. Restart AdminServer and OAM Servers.