4 Managing Data Sources

This chapter provides the steps to register and administer data sources in the Oracle Access Management Console. The information is common to all services available through the Oracle Access Management Console.

This chapter includes the following sections:

4.1 Prerequisites

This section identifies requirements for tasks in this chapter. Before performing tasks in this chapter, be sure to review all topics:

Note:

The default LDAP group, Administrators, is set during initial deployment using the Oracle Fusion Middleware Configuration Wizard, as described in "Introduction to Oracle Access Management Administrators".

4.2 Introduction to Common Data Sources

The term "data source" is a Java Database Connectivity (JDBC) term used within Oracle Access Management to refer to a collection of user identity stores or a database for policies.

Oracle Access Management supports several types of data sources that are typically installed for the enterprise. Each data source is a storage container for various types of information, as shown in Table 4-1.

Table 4-1 Data Sources for Oracle Access Management

Data Source Description

User Identity Store

Central LDAP storage in which an aggregation of user-oriented data is kept and maintained in an organized way.

During the initial deployment process, described in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management, the embedded LDAP store is used as the User Identity Store. Access Manager configuration data is stored in an XML file: oam-config.xml.

Oracle recommends that you use only the Oracle Access Management Console or WebLogic Scripting Tool (WLST) commands for changes; do not edit oam-config.xml.

The identity store must be installed and registered with Access Manager to enable authentication when a user attempts to access a protected resource (and during authorization, to ensure that only authorized users can access a resource).

Access Manager does not include identity services; there is no native user, group, or role store.

By default, Access Manager uses the Embedded LDAP in the WebLogic Server domain as the user identity store. However, a number of other external LDAP repositories can also be registered as user identity stores. In this case, one store must be designated as the System Store that contains Administrator roles and users.

Oracle Access Management configuration data file: oam-config.xml

During the initial deployment process, described in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management, Oracle Access Management configuration data is stored in an XML file: oam-config.xml.

See "About the Oracle Access Management Configuration Data File: oam-config.xml".

Database

A collection of information that is organized and stored so that its content can be easily accessed, managed, and updated.

  • Access Manager policy data, including password management data, must be stored in a database that is extended with the Access Manager-specific schema and registered with Access Manager. See "Managing the Policy and Session Database".

  • Session Store: By default, Access Manager session data is stored within in-memory caches that is migrated to the policy store. In production environments, you can have an independent database for policy data and another for session data. For details about sessions and session data, see Chapter 15.

  • Audit Store: Audit data can be stored either in a file or in a separate database (not the policy store database). For information on auditing administrative and run time events, see Chapter 8.

Keystores

Several keystores are associated with Oracle Access Management services as described in "Introduction to Oracle Access Management Keystores".

Table 4-2 introduces the services and location of details about data sources for each service available for Oracle Access Management.

Table 4-2 Data Sources for Oracle Access Management Services

Service Description

Access Manager

Access Manager supports multiple Identity Stores and provides authentication for single sign-on using data sources described in the following topics in this chapter:

Identity Federation

Identity Federation supports multiple Identity Stores, which can be assigned on a per Identity Partner basis. Each Identity Store must be registered with Access Manager. If no Identity Store is defined in the Identity Partner, the designated Default Store is used.

Security Token Service

Uses only the designated Default Store for user identities. See the following topic:

Mobile and Social

Mobile and Social provides its own Identity Directory Service configuration to point to directory servers for user authentication and/or user profile services.

There is no dependency on global (common) data sources that Access Manager or other services rely upon.

See:

See Also:

4.2.1 About the Oracle Access Management Configuration Data File: oam-config.xml

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

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

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

Note:

Oracle recommends that you not edit oam-config.xml.

Oracle recommends not editing oam-config.xml. Changes to this file could result in lost data or overwriting of the file during data sync operations. However, if you must edit oam-config.xml, use the following guidelines:

  • Back up oam-config.xml in: $DOMAIN_HOME/config/fmwconfig/ and store the copy in a different location for use if needed.

  • Make your changes on the node running the AdminServer to minimize possible conflicts that another AdminConsole user might make.

  • If OAM Servers are running, increment the configuration version number at the top of the file to associate your change and enable automatic propagation and dynamic activation across all OAM Servers. For example, see the next to last line of this example (existing value + 1):

    <Setting Name="Version" Type="xsd:integer">
  <Setting xmlns="http://www.w3.org/2001/XMLSchema"
    Name="NGAMConfiguration" Type="htf:map:> 
  <Setting Name="ProductRelease" Type="xsd:string">11.1.1.3</Setting>
    <Setting Name="Version" Type="xsd:integer">2</Setting>
</Setting>

4.3 Managing User Identity Stores

This section provides the steps you need to manage user identity store registrations using the Oracle Access Management Console.

See Also:

4.3.1 About User Identity Stores

A User Identity Store is a centralized LDAP repository in which an aggregation of Administrator and user-oriented data is stored and maintained in an organized way. Oracle Access Management supports multiple LDAP vendors, and multiple LDAP stores can be registered for use by Oracle Access Management and its services.

Oracle Access Management addresses each user population and LDAP directory store as an identity domain. Each identity domain maps to a configured LDAP User Identity Store that must be registered with Oracle Access Management.

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 for Oracle Access Management. Within the Embedded LDAP, the Administrators group is created with weblogic seeded as the default Administrator.

See Also:

Oracle Fusion Middleware Securing Oracle WebLogic Server

Note:

The Embedded LDAP performs best with fewer than 10,000 users. With more users, consider a separate enterprise LDAP server. In a highly available configuration, Oracle recommends that an external LDAP is used as the User Identity Store.

When a user attempts to access an Access Manager-protected resource, she can be authenticated against any store, not simply the designated Default Store. That said, there are a few considerations:

  • System Store: Only one User Identity Store can (and must) be designated as the System Store. This is used to authenticate Administrators signing in to use the Oracle Access Management Console, remote registration tools, and custom administrative commands in WLST.

    Administrators using the Oracle Access Management Console or remote registration utility must have credentials stored in the System Store.

    Once you define a remote User Store as the System Store, you must change the OAMAdminConsoleScheme to use an LDAP Authentication Module that references the same remote user store (the System Store).

  • Default Store: As the name implies, the LDAP store designated as the Default Store is the automatic choice for use by LDAP authentication modules unless you configure use of a different store for the module or plug-in.

    Security Token Service: Uses only the designated Default Store. When adding User Conditions to a Token Issuance Policy, for instance, the identity store from which the users are to be chosen must be Default Store.

Note:

Users attempting to access an Access Manager-protected resource can be authenticated against any user identity store that is registered and defined in the authentication scheme. Security Token Service uses only the Default User Identity Store

In the Oracle Access Management Console, User Identity Store registrations are organized under the Data Sources node (System Configuration tab, Common Configuration section). Administrators can register, view, modify, and delete User Identity Store registrations using either the Oracle Access Management Console or custom WLST commands described in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

4.3.2 About Using Multiple Identity Stores

Administrators can install and register multiple user identity stores for Oracle Access Management. Each identity store can rely on a different LDAP provider. When more than one identity store is registered, an Administrator must define:

  • The System Store: Administrator logins occur against the System Store only.

  • The Default Store: Comes into play during patching and when using Identity Federation, and Security Token Service.

  • The specific store to use with each LDAP authentication module or plug-in (and Form or Basic authentication schemes)

External LDAP repositories can provide user, role, and group membership information. A user's group memberships, for example, are calculated at login time and stored for the duration of the session. Information is used as follows:

  • When evaluating policies during authentication

  • When evaluating identities for authorization conditions in a policy

  • When using LDAP to search for identities for conditions in an authorization policy

Note:

There is no way to flush a user's group memberships, information to force Oracle Access Management to recalculate it at a later date.

Registering user identity stores is required to provide connectivity with OAM Servers. After registering the identity store, Administrators can reference it in one or more authentication modules that form the basis for authentication schemes.

Oracle Access Management addresses each user population and directory as an identity domain. Each identity domain simply maps to a configured identity store name.

In the first Oracle Access Manager 11g release, users were identified using a simple user name/id field both internally and externally. Support for multiple identity realms requires cross-realm representation of a user or a group or any entity that resides within the identity store. This representation, referred to as a canonical identifier, serves as a unique identifier to various run time and administrative components of Oracle Access Management:

  • External Representation: Qualifies the simple user name with identity domain information.

    For instance, in Oracle Access Management Console a table that lists user names includes a column that displays the identity domain of the respective user. Identity domains map to identity store names. All functional components (the console, Policies, Responses, Logging, Session management, Auditing, and so on) that display user information will begin to qualify the same with the identity domain information.

  • Internal Representation: To support disambiguation, OAM stores and uses the fully-qualified name (or uses both fields, as-is, to form a composite key).

    For instance, The Session Management Engine does this to eliminate the need to store composite). In any case, the fully-qualified name is not visible.

Authorization Policy Administration

Authorization policy administration allows authoring of grants to users or groups. Administrators can search within specific identity stores, selecting certain users or groups and granting or denying them access. Search results provide canonical identifiers for users and groups such that those values are stored as principals of the Identity Condition type of an Access Manager Authorization policy. The console displays the names and the Identity Store of origin.

Run Time

Authentication and Authorization relies on the Policy run time component. OAMIdentity is the runtime representation of the authenticated user and any groups that the user is a member of (if any). During policy evaluation, information present within the OAMIdentity is matched with what is stored as part of authorization policy's Identity Constraint. The domain is asserted as a Name Qualifier within the token.

For OAM Proxy, in addition to the existing OAM_REMOTE_USER header, a second OAM_IDENTITY_DOMAIN header is set on every request for an authenticated user, such that a consuming application can disambiguate the user if needed.

Sessions

Session Management searches inform Administrators as to the user Identity Store, which is listed in the search results table.

Auditing and Logging

The user Identity Store against which the user has been authenticated is accounted for during auditing and logging.

See Also:

4.3.3 About the User Identity Store Registration Page

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

Figure 4-1 illustrates the Create User Identity Store Page, which provides fields where you enter details for your store and default settings that you can edit for your environment. The Store Type drop-down list provides supported choices.

Figure 4-1 Creating User Identity Store Registration

Description of Figure 4-1 follows
Description of "Figure 4-1 Creating User Identity Store Registration "

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

Table 4-3 User Identity Store Elements

Elements Description

Store Name

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

Store Type

A list of all supported LDAP providers from which you can choose. You can have multiple identity stores, as described in "About Using Multiple Identity Stores".

LDAP Provider List

See Also: Table 17-29, "Location of Oracle-provided LDIFs for LDAP Providers".

Description

Optional.

Enable SSL

Click to check this box and indicate that SSL is enabled between the directory server and OAM Server.

Location and Credentials

Description

Location

The URL for the LDAP host, including the port number. Oracle Access Management 11g support multiple LDAP URLs with failover capability. The Identity Assertion Provider fails over to the next LDAP URL based on the order in which these appear.

Enter one (or more) LDAP URLs in host:port format, Multiple URLs must be separated by a space or new line. There is no need to specify ldap:// or ldaps://(which supports SSL_NO_AUTH) in the URL value:

localhost:myhost:7001

Note: The number of characters a supported URL can have is based on the browser version. Ensure that your applications do not use URLs that exceed the length that Oracle Access Management and the browser can handle.

Bind DN

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

Password

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

Users and Groups

Description

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.

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 Classes

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.

Enable Group Cache (size)

Boolean value for group cache: true or false.

Default: true

Group Cache Size

Integer for the group cache size.

Default: 10000

Group Cache TTL (seconds)

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

Default: 0
 

Connection Details

Description

Minimum Pool Size

The smallest size set for the connection pool.

Default: 10

Maximum Pool Size

The greatest size set for the connection pool.

Default: 50

Wait Timeout

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

Default: 120

Inactivity Timeout

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

Results Time Limit (seconds)

The time limit (in seconds) for LDAP searches and bind operations on the connection pool.

Default: 0

Retry Count

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

Default: 3

Referral Policy

One of these values:

  • follow: Follows referrals during an LDAP search (Default)

  • ignore: Ignores referral entries during an LDAP search

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

Figure 4-2 shows the Default and System Store designations. Notice the Access System Administrators section. You can add or remove Administrator roles only within the defined System Store and the store itself.

Figure 4-2 System Store Registration

Description of Figure 4-2 follows
Description of "Figure 4-2 System Store Registration "

See Also:

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

4.3.4 Registering a New User Identity Store

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

After you register the identity store, you can reference it in one or more authentication modules that form the basis for authentication schemes. You can also reference a specific identity store within Identity Conditions in Authorization Policies.

See Also:

Prerequisites

To register a new user identity store definition

  1. From the Oracle Access Management Console System Configuration tab, Common Configuration section, expand the Data Source nodes.

  2. Click User Identity Stores and then click the Create command button in the tool bar.

  3. Fill in the form with appropriate values for your deployment (Table 4-3), then click Apply to submit the registration.

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

  5. Close the registration page.

  6. Add Administrators: See "Managing the Administrators Role".

    1. In the navigation tree, double-click the store name to open the registration page.

    2. In the Access System Administrators section, click the + above the table.

    3. Fill in the Add System Administrator Roles dialog box (...).

    4. Click Apply.

  7. Set Default Store: See "Setting the Default Store and System Store".

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

  9. Configure one or more authentication modules or plug-ins to use this store, as described in:

4.3.5 Viewing or Editing a User Identity Store Registration

Users with valid Oracle Access Management Administrator credentials can view or modify the registration of a user identity store.

Prerequisites

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

To view or modify a user identity store registration

  1. Open the Oracle Access Management Console System Configuration tab, Common Configuration section, Data Sources node, User Identity Stores node.

  2. Click and open the desired User Identity Store registration page.

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

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

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

  6. Set as System or Default Store: See "Setting the Default Store and System Store".

  7. Manage Administrator Roles: See "Managing the Administrators Role".

  8. Configure one or more authentication modules or plug-ins to use this store, as described in:

  9. Close the page when you finish.

4.3.6 Deleting a User Identity Store Registration

Users with valid Oracle Access Management Administrator credentials can use this procedure to delete a user identity store registration using the Oracle Access Management Console.

Note:

You cannot delete the Default Store or System 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 within the module).

  2. Open the Oracle Access Management Console System Configuration tab, Common Configuration section, Data Sources node, User Identity Stores node.

  3. Click and open the desired User Identity Store registration page to confirm it is the one to delete (and not a Default), then close the page.

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

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

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

4.4 Setting the Default Store and System Store

This section includes the following topics:

4.4.1 About Setting the Default Store and System Store

Users with valid Oracle Access Management Administrator credentials can use this procedure to designate a user identity store registration as either the Default Store or the System Store.

See Also:

"About Using Multiple Identity Stores"

Note:

Administrator login works only when the LDAP Authentication Module used by the OAMAdminConsoleScheme also uses the System Store. Changing the System Store impacts the entire identity management domain. If you set another store as a remote store, ensure that the OAMAdminConsoleScheme is also modified to avoid a lockout.

Figure 4-3 shows the Default Store and System Store options that appear immediately after adding a new User Identity Store registration.

Figure 4-3 Default and System Store Options within a Registration Page

Description of Figure 4-3 follows
Description of "Figure 4-3 Default and System Store Options within a Registration Page"

Figure 4-4 shows the registration page when you view the Default Store.

Figure 4-4 Designated Store within a Registration Page

Description of Figure 4-4 follows
Description of "Figure 4-4 Designated Store within a Registration Page "

As soon as you apply the System Store designation, you are immediately asked to add Access System Administrator roles to it, as described in "Managing the Administrators Role". Also, you must ensure that the LDAP module used by the OAMAdminConsoleScheme refers to the System store.

You can also access the Default and System Identity Stores from the Common Settings page, as shown in Figure 4-5.

Figure 4-5 Common Settings Page: Default and System Identity Stores

Description of Figure 4-5 follows
Description of "Figure 4-5 Common Settings Page: Default and System Identity Stores"

4.4.2 Defining a Default Store and System Store

Users with Oracle Access Management Administrator credentials can use the following procedure to define or change Default Store and System Store designations.

See Also:

To define a Default Store and System Store

  1. From the Oracle Access Management Console, open the:


    System Configuration tab
    Common Configuration section
    Data Source node
    User Identity Stores node

  2. Set the System Store: Administrator roles and credentials must reside in this store.

    1. Click the name of the store to designate as the System Store and open the registration page.

    2. Check the box beside Set as system store (for domain wide authentication and authorization operations).

    3. Click Apply to submit the designation.

    4. Add Administrators: See "Managing the Administrators Role".

    5. Authentication Module: Set the LDAP Authentication Module used by the OAMAdminConsoleScheme (authentication scheme) to use this System Store.

    6. Configure one or more authentication plug-ins to use this store, as described in:

      "Orchestrating Multi-Step Authentication with Plug-in Based Modules"

  3. Set Default Store: This store is required for Security Token Service and migration when patching.

    1. Click the name of the store to designate as the Default Store and open the registration page.

    2. Check the box beside Set as default store to set this LDAP store (for migration).

    3. Authentication Module: Locate OAMAdminConsoleScheme and confirm that the LDAP module does not refer to this store. See "Managing Native Authentication Modules".

    4. Authorization Policy Conditions: Choose the desired user identity store when setting Identity Conditions in Authorization Policies. See "Defining Authorization Policy Conditions".

    5. Token Issuance Policy Conditions: Choose the desired user identity store when setting Identity Conditions in Token Issuance Policies. See "Managing Token Issuance Policies, Conditions, and Rules".

  4. Close the registration page.

4.5 Managing the Administrators Role

This section provides the following topics:

4.5.1 About Managing the Administrator Role

Administrator login works only when the Authentication Scheme (and assigned Authentication Module) used by the IAMSuiteAgent, also uses the System Store.

By default, the Administrators role for Oracle Access Management is the same as the WebLogic Administrators role (Administrators). You can register another User Identity Store (Oracle Internet Directory, for example); however, user weblogic must be defined with at least one user in the registered store to authenticate against.

Your enterprise might require independent sets of Administrators: one set of users responsible for Access Manager and another for Security Token Service. All Administrator roles, users, and groups must be stored in the System Store. If the System Store changes, appropriate Administrator roles must be added to the new System Store. If, when editing an Identity Store registration, you designate a store as the System Store the Access System Administrator section opens on the page as shown in Figure 4-6.

Note:

All Administrator roles, users, and groups must be stored in the System Store. If the System Store changes, appropriate Administrator roles must be added to the new System Store

Figure 4-6 System Store Registration with Access System Administrators Section

Description of Figure 4-6 follows
Description of "Figure 4-6 System Store Registration with Access System Administrators Section"

You can add new Administrator roles when adding or editing a User Identity Store registration. Figure 4-7 shows the page and controls to use.

Figure 4-7 Add System Administrator Roles

Description of Figure 4-7 follows
Description of "Figure 4-7 Add System Administrator Roles"

4.5.2 Managing Administrator Roles

The following procedure explains how to define or remove Oracle Access Management Administrator roles which must be stored in the User Identity Store designated as the System Store.

Prerequisites

Setting the Default Store and System Store

To add or remove an Administrator role from the System Store

  1. In the designated System LDAP Store:

    1. Define the desired LDAP group to use for Administrators.

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

  2. View System Store Registration: Perform the following steps (or find a different System Store in the Data Sources node to designate as the System Store).

    1. From the Oracle Access Management Console, Welcome page, click Common Settings in the Configuration panel.

    2. Scroll and expand the Default and System Identity Stores … section, as needed.

    3. Click the name of the System Store to display the configuration page.

  3. Add User Roles:

    1. Click the Add (+) button above the Access System Administrators table to display the Add System Administrator Roles dialog box.

    2. Select User in the Type list and click the Search button.

    3. In the results list, click the desired User and then click the Add Selected button.

    4. Repeat as need to add desired Administrator User roles.

    5. Click Apply to submit user roles.

  4. Add Group Roles:

    1. Click the Add (+) button above the Access System Administrators table to display the Add System Administrator Roles dialog box.

    2. Select Group in the Type list and click the Search button.

    3. In the results list, click the desired Group and then click the Add Selected button.

    4. Repeat as need to add desired Administrator Group roles.

    5. Click Apply to submit Group roles.

  5. Remove Administrator Roles:

    1. In the Access System Administrators table, click the row containing the user or group to remove.

    2. Click the Delete (x) button above the table.

    3. Confirm removal when asked.

    4. Click Apply to submit the removal.

  6. Correct any authentication plug-ins that use the System Store (if this is a new store), as described in:

    "Orchestrating Multi-Step Authentication with Plug-in Based Modules"

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

    1. Sign out of the Oracle Access Management Console and close the browser window.

    2. Start up the Oracle Access Management Console and attempt to log in using the previous Administrator role to confirm that this attempt fails.

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

      Login Failure: See "Administrator Lockout".

4.6 Managing the Policy and Session Database

This section includes the following topics:

4.6.1 About the Database Store for Policy, Password Management, and Sessions

Oracle Access Management requires a database to store Access Manager policy data, password management data, and Access Manager sessions in a production environment.

Note:

At most, your deployment can have one policy store database (which serves password management) and one session store. By default, a single JDBC data source is used for both.

The following data is maintained in the policy store database by default:

  • Policy data, including authentication modules and schemes, Application Domains, and policies.

  • Password Management data, which includes password policy type for each configured User Identity store as well as the policy that governs password requirements, expiry, notification,

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

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.

See Also:

"Managing the Policy and Session Database"

4.6.2 About Database Deployment

Oracle requires a single database as the policy store in production environments. This single database 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).

Note:

You can have up to two databases: one policy database and one session database. Access Manager is agnostic with respect to the actual back end repository and does not manage this policy store configuration directly.

The policy database must be installed according to vendor instructions. The policy database is configured for use in a Oracle WebLogic Server domain using Oracle Fusion Middleware Configuration Wizard and policy store Database configuration template.

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

  • Database login ID and password

  • Database Service name and location

An Administrator must extend the database with the Access Manager-specific schema using RCU, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management. Basic schema creation occurs when the RCU is invoked. The RCU prepares the database to accept Access Manager policy, password management, and session data.

Using the WebLogic Configuration Wizard you can register and test the connection to the database.

Actual Access Manager policy elements are created the first time the WebLogic AdminServer is started with the Oracle Access Management Console deployed.

See Also:

Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management

4.6.3 Configuring a Separate Database for Access Manager Sessions

Access Manager includes a data source named oamDS which is configured against the database instance extended with the Access Manager 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 Oracle Access Management Console.

Note:

In this rare instance, Oracle recommends that you carefully edit oam-config.xml as described in Step 2f.

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

4.7 Introduction to Oracle Access Management Keystores

This section provides the following topics:

4.7.1 About Access Manager Security Keys and the Embedded Java Keystore

Keystores are created and configured during Access Manager installation. The password and the key entries password were randomly generated.

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

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

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

  • During agent and application registration, a key is generated for encrypting and decrypting SSO Cookies (for Webgates and mod_osso).

Administrators use the Oracle-provided importcert tool for several different procedures related to keystores, keys, and certificates, as described in Appendix C.

The WLST resetKeystorePassword method allows you to set the .oamkeystore password and any key entries with a password identical to the .oamkeystore password to a new value. See Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.

Table 4-4 identifies the generated Access Manager cryptographic keys.

Table 4-4 Access Manager Keys and Storage

Keys and Storage Description

Access Manager Cryptographic keys

  • One per agent secret key shared between 11g Webgate and OAM Server

    One global shared secret key used by all your 10g Webgates

  • One OAM Server key

Key storage

  • Agent side: A per-agent key is stored locally in the Oracle Secret Store in a wallet file. Client keystore/scratch/clientTrustStore.jks and /scratch/clientKey.jks can be used.

  • OAM Server side: .oamkeystore contains a per-agent key, and server key, are stored in the credential store on the server side.

Keystores are not accessible using the Oracle Access Management Console. You can manage keystores and certificates as described in Appendix C, "Securing Communication".

See Also:

"About Identity Federation Keystore"

4.7.2 About Access Manager Keystores

Table 4-5 provides a summary of keystores used for Access Manager.

Table 4-5 Keystores for Access Manager and Security Token Service

Keystore Description

System Keystore / Partner Keystore

.oamkeystore

The container for keys and certificates associated with OAM Server instances (OAM secret keys and Security Token Service private keys for signing and encryption).

The container for keys and certificates that are used to establish trust with partners, clients, and agents. The partner keys and certificates are stored in.oamkeystore with sensitive information encrypted.

Only one System Keystore of type JCEKS can be present: .oamkeystore.

$DOMAIN_HOME/config/fmwconfig/.oamkeystore

The certificate alias and password can be configured using the Oracle Access Management Console.

See Also:

Trust Keystore

amtrustkeystore

The Trust Keystore is used to validate keys and certificates presented by clients to establish trust in entities interacting with OAM Server instances.

$DOMAIN_HOME/config/fmwconfig/amtruststore

amtruststore is created during installation, and must include at least one trusted anchor.

The Trust Keystore is managed by using the JRE's keytool application. Security Token Service can use a custom trust keystore.

See Also:

Certificate Revocation Lists (CRL)

amcrl.jar

Certificate revocation information lists are stored in a ZIP archive on the filesystem. These are used by OAM Servers when performing CRL-based certificate revocation checking.

amcrl.jar contains CRL files in the DER format:

$DOMAIN_HOME/config/fmwconfig/amcrl.jar

The OAM Server defines a notification listener for the Keystores and the CRL Zip file. Any changes to these files causes Security Token Service to reload the keystore/crl-zip at runtime, without requiring any restarts.

amcrl.jar is created by installation and can be modified using the Oracle Access Management Console.

See Also:

Oracle WSM Agent Keystore

default-keystore.jks

The Oracle WSM Agent uses this keystore for various cryptographic operations. For these operations, the Oracle WSM Agent uses the keystore configured for Oracle WSM tasks.

Oracle strongly recommends that the Oracle WSM Agent keystore and the Access Manager and Security Token Service keystore always be different. Otherwise, keys could be available to any modules authorized by OPSS to access the keystore and Access Manager/Security Token Service keys might be accessed.

See Also:

"About the Oracle Web Services Manager Keystore (default-keystore.jks)"

OPSS Keystore

For special cases where clients use referencing schemes such as SKI (as opposed to a certificate token being received as part of the web service request), the requester's certificates need to be populated in the OPSS Keystore.

This is an uncommon scenario that requires manually provisioning keys to the OPSS keystore.

See Also:

.cohstore.jks

This is used to store the SSL Key and Certifcate that is used to encrypt SSL communication between Coherence nodes. For information on securing Coherence communications, see the Oracle Coherence Security Guide.

4.7.3 About Identity Federation Keystore

Identity Federation and Access Manager store key pairs and certificates that are used for digital signatures and encryption operations. Identity Federation uses keys to:

  • Sign outgoing assertions

  • Decrypt incoming XML encrypted data contained inside the SAML message

The following keystore is used to store the encryption and signing certificates:

$DOMAIN_HOME/config/fmwconfig/.oamkeystore

Identity Federation uses CSF to securely store keystore passwords, as well as server credentials such as HTTP Basic Authentication usernames and passwords.

See Also:

4.8 Integrating a Supported LDAP Directory with Oracle Access Manager

This section describes post-installation enablement of a centralized LDAP store for use with Oracle Access Manager. Oracle Internet Directory is featured in this discussion. However, tasks are the same regardless of your chosen LDAP provider.

Oracle Access Manager addresses each user population and LDAP directory store as an identity domain. Each identity domain maps to a configured LDAP User Identity Store that is registered with Oracle Access Manager. Multiple LDAP stores can be used with each one relying on a different supported LDAP provider.

During initial WebLogic Server domain configuration, the Embedded LDAP is configured as the one and only User Identity Store for Oracle Access Manager. Within the Embedded LDAP, the Administrators group is created, with weblogic seeded as the default Administrator:

  • Only the User Identity Store designated as the System Store is used to authenticate Administrators signing in to use the Oracle Access Management Console, remote registration, and custom administrative commands in WLST.

  • Users attempting to access an OAM-protected resource can be authenticated against any store, not necessarily the only one designated as the Default User Identity Store.

  • Security Token Service uses only the Default User Identity Store. When adding User constraints to a Token Issuance Policy, for instance, the identity store from which the users are to be chosen must be Default User Identity Store.

After registering a User Identity Store with Access Manager, administrators can reference the store in one or more authentication modules, which form the basis for Oracle Access Manager Authentication Schemes and Policies. When you register a partner (either using the Oracle Access Management Console or the remote registration tool), an application domain can be created and seeded with a policy that uses the designated default Authentication Scheme. When a user attempts to access an Oracle Access Manager-protected resource, she is authenticated against the store designated by the authentication module.

For more information, see Oracle Fusion Middleware Integration Guide for Oracle Identity Management Suite.