5 Managing Common Data Sources

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

Note:

Unless explicitly stated, information in this chapter is the same whether you are using Oracle Access Manager alone or with Oracle Security Token Service.

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 Common Data Sources

Various types of data must be managed for Oracle Access Manager with Oracle Security Token Service, as described in following topics:

See Also:

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

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

About User Identity Stores

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 the User Identity Store designated as the System Store is used to authenticate Administrators signing in to use the Oracle Access Manager 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 marked as Default User Identity Store.

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

Note:

Administrators using the Oracle Access Manager Console must be in the System Store. Users attempting to access an OAM-protected resource can be authenticated against any store, not only the designated Default Store. Oracle Security Token Service uses only the Default User Identity 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).

In the Oracle Access Manager 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 Manager 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" seeded as the default administrator.

See Also:

Oracle Fusion Middleware Securing Oracle WebLogic Server Part Number

Multiple Identity Stores

Administrators can install multiple user identity stores for Oracle Access Manager with Oracle Security Token Service. Each identity store can rely on a different LDAP provider. However, Administrator logins occur against the System Identity Store only. When more than one identity store is registered, administrators must define:

  • The System Store for Administrative logins

  • The default user store, which comes into play during migration and when using Oracle Security Token Service

External LDAP repositories can provide user, role, and group membership information to be used:

  • When evaluating policies during authentication

  • When evaluating identities for authorization constraints in a policy

  • When using LDAP to search for identities for constraints per authorization policy

Registering user identity stores with Oracle Access Manager 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 Manager will address each user population and directory as identity domains. Each identity domain simply maps to configured Identity store name.

In the original Oracle Access Manager 11g release, users were identified using a simple user name/id field both internally as well as 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 Manager:

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

    For instance, in Oracle Access Manager 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 Constraint component of the Oracle 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:

About the Policy and Session Database 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.

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 Database by Using the Console"

About the Oracle Access Manager 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 Oracle 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.

Note:

The oam-config.xml file should not be edited. Changes could result in lost data or overwriting of the file during data sync 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 Oracle Access Manager Security Keys and the Embedded Java Keystore

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

  • Every Oracle Access Manager and OSSO Agent has a secret key that other agents cannot read.

  • There is 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 5-1 compares the cryptographic keys generated by Oracle Access Manager 11g, 10g, and OSSO 10g, as well as a brief description of there each is stored.

Table 5-1 Oracle Access Manager 11g, 10g, and OSSO 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 keystore is not available through the console and cannot be viewed, managed, or modified.

About Oracle Security Token Service Keystores

Following is a brief summary of several types of keystores for Oracle Access Manager with Oracle Security Token Service:

  • System Keystore for keys and certificates associated with OAM Server instances

  • Trust Keystore for keys and certificates that are used to establish trust in entities that are interacting with the OAM Server instances

  • Partner Keystore 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.

  • Certificate Revocation Lists (CRL) are used by the Oracle Access Manager/Oracle Security Token Service server instances when performing CRL-based certificate revocation checking

The following files are distributed across all Managed Servers in the domain by the JMX framework:

  • System Keystore: .oamkeystore

  • Trust Keystore: amtruststore

  • Partner Keystore: .oamkeystore

  • CRL: amcrl.jar

Oracle WSM Agent Keystore: Oracle WSM Agent functionality is available to Oracle Security Token Service to publish WS Policies and enforce message protection on inbound and outbound WS messages. Oracle WSM requires a separate Keystore of type JKS to contain System and Partner keys and certificates. The default name is default-keystore.jks, which is specified in jps-config.xml.

Note:

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

See Also:

Chapter 18, "Managing Oracle Security Token Service Certificates and Keys"

Managing User Identity Stores

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

See Also:

"Setting the Default Store and System Store"

About the User Identity Store Registration Page

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

Figure 5-1 illustrates a completed registration page. The Create User Identity Store Page is similar, though empty except for default Connection Details values. The Store Type drop-down list provides supported choices.

Figure 5-1 Completed Registration for the Default Store

Completed Registration for the Default Store
Description of "Figure 5-1 Completed Registration for the Default Store"

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

Table 5-2 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.

LDAP Provider List

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

  

Location

The URL for the LDAP host, including the port number. Oracle Access Manager 11g has support for 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.

There is no need to specify ldap:// or ldaps://(which supports SSL_NO_AUTH) while specifying the URL value within the Location field. For example, enter:

localhost: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 Manager 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

  

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

  

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 ReferralException, which can be caught by the component user.

Figure 5-2 shows a completed registration page for the System Store, as it looks when viewing it. Notice the Access System Administrators roles are listed. You can add or remove administrator roles only within the defined System Store and the store itself.

Figure 5-2 Completed Registration for System Store

Completed Registration for System Store
Description of "Figure 5-2 Completed Registration for System Store"

See Also:

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

Registering a New User Identity Store

Users with valid 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. You can also reference it in authorization constraints in access policies.

See Also:

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, 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 5-2), 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 and proceed as follows:

  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 to use this store, as described in "Managing Authentication Modules".

Viewing or Editing a User Identity Store Registration

Users with valid 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. From the System Configuration tab, Common Configuration section, 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 5-2).

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

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

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

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

  9. Close the page when you finish.

Deleting a User Identity Store Registration

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

Note:

You cannot delete the Default User Identity 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. From the System Configuration tab, Common Configuration section, 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 not a Default), 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.

Setting the Default Store and System Store

This section includes the following topics:

About Setting the Default Store and System Store

After identity store registration, you can designate the new store as either the Default Store or the System Store, or both:

  • Default Store: Used by Oracle Security Token Service, and for migration purposes when patching.

  • System Store: Contains Groups and or users for Access System Administrator roles for the entire Identity Management Domain, to which the LDAP Authentication Module used by the OAMAdminConsoleScheme points.

    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 5-4 shows the Default Store and System Store options that appear immediately after adding a new User Identity Store registration.

Figure 5-3 Fresh Default Store and System Store Options

Fresh Default Store and System Store Options
Description of "Figure 5-3 Fresh Default Store and System Store Options"

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

Figure 5-4 Default Store Designation

Default Store Designation
Description of "Figure 5-4 Default Store Designation "

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

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

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

Defining a Default Store and System Store

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

See Also:

Managing User Identity Stores

To define a Default Store and System Store

  1. From the Oracle Access Manager 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. Double-click the name of the store to become the System Store to 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. See "Managing Authentication Modules".

  3. Set Default Store: This store is for migration purposes only when patching.

    1. Double-click the name of the store to become the Default Store to open the registration page.

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

    3. Authentication Module: Confirm that the LDAP module for OAMAdminConsoleScheme does not refer to this store. See "Managing Authentication Modules".

  4. Close the registration page and proceed as follows:

Managing the Administrators Role

This section provides the following topics:

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 Manager with Oracle Security Token Service is the same as the WebLogic Administrators role (Administrators). However, your enterprise might require independent sets of administrators: one set of users responsible for Oracle Access Manager and another for Oracle 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 5-6.

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

User Identity Store Definition
Description of "Figure 5-6 System Store Registration with Access System Administrators Section"

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

Figure 5-7 Add System Administrator Roles

Add System Administrator Roles
Description of "Figure 5-7 Add System Administrator Roles"

Managing Administrator Roles

The following procedure explains how to define or remove 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 for OAM:

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

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

  2. Locate the 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 Manager 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 modules that use the System Store (if this is a new store), as described in "Managing Authentication Modules".

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

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

    2. Start up the Oracle Access Manager 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.

Managing the Policy Database by Using the Console

This section includes the following topics:

About Database Deployment for Oracle Access Manager

Oracle requires a single database as the policy store, 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 Oracle Access Manager Console 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 sync 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 Oracle Access Manager 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 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.