Managing Data Sources

5 Managing 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. These data sources must be registered using the Oracle Access Management Console in order to be accessed.

The following topics describe the tasks to register and administer data sources using the Oracle Access Management Console. The information is common to all services available through the Oracle Access Management Console.

5.1 Data Sources for Oracle Access Management

Oracle Access Management supports several types of data sources that are typically installed for the enterprise.

Table 5-1 describes each data source is a storage container for the various types.

Table 5-1 Data Sources for Oracle Access Management

Data Source	Description
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 Maintaining Access Manager Sessions. 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 Auditing Administrative and Run-time Events.
User Identity Store	Central LDAP storage in which an aggregation of user-oriented data is kept and maintained in an organized way. (Access Manager does not include identity services; there is no native user, group, or role store.) 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). During the initial deployment process, described in the Installing and Configuring Oracle Identity and Access Management, the embedded LDAP store is used as the User Identity Store. 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. 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 Installing and Configuring Oracle Identity and Access Management, Oracle Access Management configuration data is stored in an XML file: oam-config.xml. See "Updating OAM Configuration".
Keystores	Several keystores are associated with Oracle Access Management services as described in "Introduction to Oracle Access Management Keystores". Embedded Java Keystore: Used for certificates for Simple or Certificate-based communication between OAM Servers and Webgates. The keystore bootstrap occurs upon initial AdminServer startup after running the Configuration Wizard. See: "Access Manager Security Keys and the Embedded Java Keystore" Security Token Service Keystores: Access Manager and Security Token Service keystore should always be different. For more information, see "Access Manager Keystores". Identity Federation Keystores: Keystore settings enable you to create aliases (a short hand notation) for keys in the keystore. See: "Identity Federation Keystore"

Table 5-2 contains the Oracle Access Management services and links to information about the data sources used for each.

Table 5-2 Data Sources for Oracle Access Management Services

Service	Description
Access Manager	Access Manager supports multiple Identity Stores and provides SSO authentication using data sources: Registering and Managing User Identity Stores Managing the Policy and Session Database Updating OAM Configuration Access Manager Security Keys and the Embedded Java Keystore
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. About Using Multiple Identity Stores Identity Federation Keystore Administering Identity Federation As A Service Provider

Service

Description

Access Manager

Access Manager supports multiple Identity Stores and provides SSO authentication using data sources:

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.

See Also:

"Managing Global Password Policy"

"Configuring OAM WebGate and Authentication Policy for DCC"
"About using the System Store for User Identities"
Auditing Administrative and Run-time Events for details about Audit data stored within audit files or a separate Oracle Database

The following sections contain additional details.

5.1.1 Updating OAM Configuration

From 12.2.1.3 release onwards, OAM configuration resides only in the OAM dbstore (OAM SCHEMA).

Therefore, editing oam-config.xml in $DOMAIN_HOME does not have any effect. To make changes to configuration, follow this procedure:

Create a <working directory> and change to the directory:
```
mkdir <working directory>
```
```
cd <working directory>
```

Inside the directory create a dbschema.properties file that contains the following:

oam.entityStore.ConnectString=jdbc:oracle:thin:@<DB_HOST>:<DB_PORT>/<DB_SERVICE_NAME>
oam.entityStore.schemaUser=<PREFIX>_OAM
oam.entityStore.schemaPassword= <password>
oam.importExportDirPath=<path to which configuration is exported or imported>
oam.frontending=params=host;port;protocol

For example:

oam.entityStore.ConnectString=jdbc:oracle:thin:@dbhost.example.com:1521/pdb1.example.com
oam.entityStore.schemaUser=DEV_OAM
oam.entityStore.schemaPassword= <password>
oam.importExportDirPath=<work directory>
oam.frontending=params=host;port;protocol

Export configuration from the dbstore using config-utility.jar:

java -cp $ORACLE_HOME/oam/server/tools/config-utility/config-utility.jar:$ORACLE_HOME/oracle_common/modules/oracle.jdbc/ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand $DOMAIN_HOME export dbschema.properties

This will export the oam-config.xml to the <working directory>

Modify the <working directory>/oam-config.xml as required.

Import the configuration back into the dbstore using config-utility.jar:

java -cp $ORACLE_HOME/oam/server/tools/config-utility/config-utility.jar:$ORACLE_HOME/oracle_common/modules/oracle.jdbc/ojdbc8.jar oracle.security.am.migrate.main.ConfigCommand $DOMAIN_HOME import dbschema.properties

5.1.2 About the Default LDAP Group

The default LDAP group, Administrators, is set during initial deployment using the Oracle Fusion Middleware Configuration Wizard.

For more information, see "About Oracle Access Management Administrators".

5.2 Registering and Managing 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. This section provides the information you need to register and manage user identity stores using the Oracle Access Management Console.

Note:

Oracle recommends that you use the Identity Directory Service Profiles to access identity data stores rather than the legacy OAM ID Stores function as it will be deprecated in a future release. The Identity Directory Service is documented in Managing the Identity Directory Service User Identity Stores.

5.2.1 Understanding User Identity Stores

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.

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. See Administering Security for Oracle WebLogic Server.

When attempting to access an Access Manager-protected resource, a user 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. Thus, 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). For details, see About using the System Store for User Identities
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.

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 while the Security Token Service uses only the Default User Identity Store. For example, when adding User Conditions to a Token Issuance Policy, the identity store from which the users are chosen must be the Default Store.

In the Oracle Access Management Console, User Identity Store registrations are organized under the Configuration Launch Pad. Administrators can register, view, modify, and delete User Identity Store registrations using either the Oracle Access Management Console or Customization Commands described in WLST Command Reference for WebLogic Server.

5.2.2 About using the System Store for User Identities

Users with valid Oracle Access Management System Administrator credentials can designate a registered user identity store as either the Default Store, the System Store or both.

You can select the Default and System Identity Store configurations using the Oracle Access Management Console as documented in Managing the Identity Directory Service User Identity Stores

UserIdentityStore1 is the embedded Access Manager LDAP store. After installation, the Oracle Access Management Console and OAM Policy Manager are protected by the IAM Suite Agent. The IAM Suite Application Domain is seeded with the OAM Admin Console Authentication Policy which uses the OAMAdminConsoleScheme authentication scheme. In turn, the OAMAdminConsoleScheme uses the LDAP Authentication module, and the System Store and the LDAP authentication module both use the WebLogic Embedded Identity Store (UserIdentityStore1). The Access Manager Administrator roles are mapped to the enterprise groups and users that belong to the System Store.

5.2.2.1 Using the System Store for User Identities

Changing the System Store impacts the entire identity management (IAM Suite) domain. When you want to change the System Store to a remote identity store, you need to create an Authentication Provider in WebLogic for this remote store.

The remote store provider should be displayed in the list of providers in the WebLogic console. Additionally:

Ensure the control flags for all providers preceding the new remote store provider are set to SUFFICIENT or OPTIONAL.
Assign ADMIN, the WebLogic global role, to the enterprise groups or users from this remote store. This can be done by following the steps to prepare the remote store using IDM Config Tool and by referring to the WebLogic documentation.
If using Oracle Unified Directory as a system store, create IPlanetAuthenticator in WebLogic.

The above configuration should be done and tested before you change the System Store to a remote store. You will also have to change the LDAP authentication module configuration to use the remote store. The remote store can be configured using OAM Identity Store or IDS Profile.

Note:

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

When you want to use a WebGate to protect the Oracle Access Management Console (on the AdminServer) and the Policy Manager Console (on the OAM Server), in addition to the above procedure, create an OAM Identity Asserter in WebLogic and enable OAM as the SSO provider in JPS using WLST commands. For details, see Integrating Oracle ADF Applications with Access Manager SSO. You will also have to whitelist the OAM Policy Manager Console host name and port to fully enable WebGate protection.

Information regarding administrator roles can be found in Managing Administrator Roles

5.2.3 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: Administrators can login against the System Store only.
The Default Store: Comes into play during patching and when using Identity Federation, and Security Token Service.
- Patching: Oracle recommends that before patching, you designate UserIdentityStore1 as the Default Store and also update LDAP Authentication Modules to use UserIdentityStore1 (the Embedded LDAP of Weblogic Server).
- Identity Federation: Supports multiple identity stores, on a per IdP Partner basis. The specified identity store must be registered like any other store. If no identity store is defined in the IdP Partner, the Default Store is used. For details, see Administering Identity Federation As A Service Provider.
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.

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.

5.2.3.1 Components of Oracle Access Management that use Identity Stores

The run time and administrative components of Oracle Access Management use identity stores.

Table 5-3 documents the various run time and administrative components of Oracle Access Management.

Table 5-3 Components That Use Identity Stores

Component	Description
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:

"User Identity Store Settings"
"Managing Administrator Roles"
"About using the System Store for User Identities"
Access Manager WLST Commands in Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for Identity and Access Management

5.2.4 User Identity Store Settings

You can create an user identity store from the System Configuration tab.

Figure 5-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 5-1 Creating User Identity Store Registration

Description of "Figure 5-1 Creating User Identity Store Registration "

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

Table 5-4 User Identity Store Elements

Section	Elements	Description
General	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". See Also: Table 24-6.
	Description	Optional.
	Enable SSL	Click to check this box and indicate that SSL is enabled between the directory server and OAM Server. Using the keytool command line interface, you must also import the appropriate CA root certificate and server certificate to the default JDK keystore (located at $JAVA_HOME/lib/security/cacerts). NOTE: The CA root certificate can be added to any keystore as long as the appropriate values regarding that keystore are set for the following Java properties. To do this, start the OAM Admin Server and Managed Server instances with the appropriate values and the -D option. javax.net.ssl.trustStore=trust.jks javax.net.ssl.trustStorePassword=<trustPass> javax.net.ssl.keyStore=keystore.p12 javax.net.ssl.keyStoreType=pkcs12 javax.net.ssl.keyStorePassword=<keyStorePass>
	Prefetched Attributes	List of comma-separated user attributes; for example, email, phone, mobile. The OAM server will cache the list of user attributes in memory while it authenticates the user against the identity store. The cached values will be used to compute the Authentication response headers, Authorization policy response headers and Authorization policy conditions. Pre-fetched attributes provide huge performance improvements by avoiding a round trip to the user identity store. The OAM Administrator has to make sure all the user attributes used in Authentication and Authorization policy response headers and Authorization conditions are defined as prefetched attributes in the user identity store profile.
	User Native ID Store	This enables getting the authentication code for natively locked/disabled/pw_must_change code in the LDAP authentication module.
Location and Credentials	Location	The URL for the LDAP host, including the port number. Oracle Access Management 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	Login ID Attribute	The attribute that identifies the login ID (user name). For example: uid
	User password attribute	The attribute in the user identity store (LDAP directory) which stores the user's password. This is made configurable for added flexibility.
	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 Classes	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 Membership Cache	Boolean value for group cache: true or false. Default: true
	Group Cache Size	Integer for the group cache size. Default: 10000
	Group Cache Time-to-Live (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.
	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.
	Enable Password Management	Enables password policy enforcement against the attribute values listed below. The corresponding options in the password policy must be configured as well.
	Use Oblix User Schema	Enables the use of OBLIX schema instead of standard Oracle schema.
	Global Common ID Attribute	Specifies the User ID attribute name. This attribute will be used as part of the password policy to check that the user ID is not part of the password.
	First Name Attribute	Specifies the First Name attribute name. This attribute will be used as part of the password policy to check that the user's first name is not part of the password.
	Last Name Attribute	Specifies the Last Name attribute name. This attribute will be used as part of the password policy to check that the user's last name is not part of the password.
	Results Time Limit (seconds)	Results Time Limit is not supported. Alternatively, use `OperationTimeout` as described: `OperationTimeout` specifies the time (in milliseconds) IDS waits for an LDAP request to be acknowledged by the LDAP remote host. Default value is 120000 milliseconds For IDS based profiles, use the `modifyLDAPAdapter` WLST command to set the timeout value. For example: modifyLDAPAdapter(adapterName='ADAPTER_NAME', attribute='OperationTimeout', value=120000, contextName='ids') For original idstore profiles, edit the `oam-config.xml` and set the value inside the idstore snippet. For example, <Setting Name="CONN_TIMEOUT" Type="xsd:string">120000</Setting> See Updating OAM Configuration
	Retry Count	Not currently supported.
	Email Address Attribute	Not currently supported.
	Challenge Questions Attribute	Not currently supported.
	Challenge Answers Attribute	Not currently supported.

Figure 5-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 5-2 System Store Registration

Description of "Figure 5-2 System Store Registration "

See Also:

Details about classifying users in Managing Policies to Protect Resources and Enable SSO

5.2.5 Registering a New User Identity Store

Users with valid Oracle Access Management Administrator credentials can 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. Before you begin:

Install the user identity store that you intend to register with Oracle Access Management.
Extend the LDAP directory schema for Access Manager, as described in Installing and Configuring Oracle Identity and Access Management.
Create Users and Groups in the LDAP directory, as described in your vendor documentation.

Follow this procedure to register a new identity store definition:

At the top of the Oracle Access Management Console, click Configuration.
In the Configuration console, click User Identity Stores.
In the OAM ID Stores section, click Create.
Fill in the form with appropriate values for your deployment (Table 5-4), then click Apply to submit the registration.
Test Connection: Click Test Connection to confirm connectivity, then close the Confirmation window.
Close the registration page.
Add Administrators: See "Managing Administrator Roles".
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.
Set Default Store: See "About using the System Store for User Identities".
Click Apply to submit the registration and close the page.
Configure one or more authentication modules or plug-ins to use this store, as described in:
- "Native LDAP Authentication Modules"
- "Orchestrating Multi-Step Authentication with Plug-in Based Modules"

5.2.6 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. The user identity store that you intend to register must be installed and running.

To view or modify a user identity store registration:

At the top of the Oracle Access Management Console, click Configuration.
In the Configuration console, click User Identity Stores.
In the OAM ID Stores list, select the target identity store and click Edit.
Modify values as needed (see Table 5-4).
Click Apply to update the registration (or close the tab without applying changes).
Test Connection: Click Test Connection button to confirm connectivity, then close the Confirmation window.
Set as System or Default Store: See "About using the System Store for User Identities".
Manage Administrator Roles: See "Managing Administrator Roles".
Configure one or more authentication modules or plug-ins to use this store, as described in:
- "Native LDAP Authentication Modules"
- "Orchestrating Multi-Step Authentication with Plug-in Based Modules"
Close the page when you finish.

5.2.7 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. You cannot delete the Default Store or System Store registration.

To delete a user identity store registration:

Edit LDAP Authentication Modules that reference the store to be deleted (to ensure a valid identity store is referenced within the module).
At the top of the Oracle Access Management Console, click Configuration.
In the Configuration console, click User Identity Stores.
In the OAM ID Stores list, select the target identity store and click Delete.
In the confirmation dialog that appears, click Delete to confirm the deletion (or click Cancel to dismiss the window and retain the instance).
Confirm that the definition is no longer listed in the navigation tree.

5.3 Managing the Identity Directory Service User Identity Stores

Identity Directory Service (IDS) is a flexible and configurable service used by Access Manager as the means for accessing multiple identity data stores. The purpose of IDS is to allow the management of users or groups from identity stores not deployed with Access Manager itself.

The following sections contain the details.

5.3.1 Identity Directory Services

Identity Directory Service offers a consistent and rationalized technology to access identity stores that eliminates redundant configurations and simplifies Identity Management operations.

IDS provides the following benefits:

Support for different types of user directories including integration with native user/password state managed by the directory.
Consistent administration user interface and a paradigm for working with different identity stores across Oracle Identity Management components.
Built in failover and load balancing capabilities.
Logical to physical attribute mapping and entity relationships.

The following list of directory servers are among those supported.

Microsoft Active Directory
Novell eDirectory
Oracle Directory Server Enterprise Edition
Oracle Internet Directory
Oracle Unified Directory
Oracle Virtual Directory
OpenLDAP
IBM Tivoli Directory Server
WebLogic Server Embedded LDAP

Note:

Oracle recommends that you use the Identity Directory Service Profiles to access identity data stores rather than the legacy OAM ID Stores function as it will be deprecated in a future release.

Figure 5-3 is a screen capture of the Identity Directory Service console page.

Figure 5-3 Identity Directory Service Console Page

Description of "Figure 5-3 Identity Directory Service Console Page"

Note:

Note this page contains the configuration panel for the legacy OAM ID Stores. Oracle recommends that you use the Identity Directory Service Profiles to access identity data stores rather than the legacy OAM ID Stores function as it will be deprecated in a future release.

Configuring an Identity Directory Service store involves configuring parameters for an IDS Profile and an IDS Repository. The IDS Profile specifies the full scope of traits for a particular type of identity store. It is the logical configuration for the repository and contains the following data.

Entity definition
Entity relationship definition
Default operational configuration (including the tenant search/create base, the tenant filter, timeouts and cache configuration)

The IDS Repository configuration defines the actual location of the store. The IDS Repository is a physical configuration that containing the following data.

Connection details (including the host machine, port number and credentials)Connection pool detailsHigh-availability/failover configurationEntity attribute mapping

5.3.2 Creating an Identity Directory Service Profile

You can create an Identity Directory Service profile form the Configuration console.

To create:

At the top of the Oracle Access Management Console, click Configuration.
In the Configuration console, click User Identity Stores.
In the IDS Profiles section, click Create.

The Create IDS Profile page is displayed as in Figure 5-4.

Figure 5-4 Create IDS Profile Page

Description of "Figure 5-4 Create IDS Profile Page"
Provide the following values for the new Identity Directory Service profile.
- Name - Type a unique name for this User Profile Service Provider.
- Description - (Optional) Type a short description that will help you or another Administrator identify this service in the future.
Configure the Repository properties by selecting Create New or Use Existing.

Create New defines a new Repository object (that is, a reference to an LDAP directory server) for the Identity Directory Service connection. Click Test Connection after you have defined the values in the Repository section to verify they are correct. This option is only available when defining a new Identity Directory Service connection. Use Existing allows you to choose a previously defined Repository object by selecting it from the drop down menu.
- (Repository) Name - Enter a new unique name to create, or choose an existing one from the menu. After entering a new name, configure properties for the Identity Directory Service connection.
- Directory Type - Select the type of directory server software hosting the Repository; for example, Microsoft Active Directory or Oracle Internet Directory. If your directory is not listed, leave this field empty. If you are not defining a new Identity Directory Service connection or creating a new repository, this field is read-only.
- Host Information - Contains information about the host computer on which the Identity Directory Service Repository is located. Add multiple hosts if the directory server is part of a cluster. Click Add to add a new host to the table. In the Host Name column type either the IP Address or the name of the computer (or virtual computer) on which the Directory server is running. In the Port column, type the port number that the directory server is configured to use. If the hosts are part of a cluster, in the Load Distribution column type the load amount as a percentage that should be directed to each host. For multiple hosts, the amount should add up to 100%. To delete a host, select its row in the table and click Remove. If you are not defining a new Identity Directory Service connection or creating a new repository, this field is read-only.
- Availability - Choose Failover if the cluster is configured for failover operation, or choose Load balanced if the cluster distributes the load across multiple hosts. This field is read-only if you are using an existing repository.
- SSL - Select Enabled if the connection is configured for SSL. (See the Securing Applications with Oracle Platform Security Services for SSL configuration details.)
  Note:
  
  Follow this procedure to add the SSL certificates required for setting the TLS connection.
  1. Create the LibOVD keystore by running this command.
```
MW_HOME/oracle_common/bin/libovdconfig.sh -host WLS_ADMIN_HOST 
 -port WLS_ADMIN_PORT -userName weblogic 
 -domainPath WLS_DOMAIN_PATH -createKeystore 
 -contextName ids
```
    Enter the AdminServer password and the password used for the LibOVD keystore when requested.
  2. Import the OID server certificate into the LibOVD keystore.
```
keytool -importcert 
 -keystore DOMAIN_HOME/config/fmwconfig/ovd/
ids/keystores/adapters.jks 
 -storepass KEYSTORE_PASSWORD -alias ALIAS_NAME 
 -file FULL_PATH_TO_CERTFILE -noprompt
```
- Bind DN - Type the distinguished name (DN) of the LDAP Administrator used to authenticate to the Directory server.
- Bind Password - Type the Bind DN password used to authenticate to the Directory server.
- Base DN - Type the base distinguished name (DN) where User and Group data is located.
- Password Management - selecting Enable Password Management enables password policy enforcement against the attribute values listed in Table 5-4. The corresponding options in the password policy must be configured as well.
Configure the User properties to configure the LDAP User object.

Note:

These fields are read-only if using an existing Identity Directory Service connection.
- Object Classes - Click Add to add a custom object class that represents people in an organization as defined on your directory server.
- RDN Attribute - Type the relative distinguished name attribute (for example, cn) designated for the User object on the directory server.
- Base DN - Type the base DN (in LDAP form) for the User object on the directory server.
- Login ID Attribute - Type the LDAP attribute from which the login ID specifying the User will be extracted.
- Global Common ID Attribute - Type the global common user ID attribute.
Configure the Group properties to configure the LDAP group object.
- Object Classes - Click Add to add a custom object class that represents a group of people in an organization as defined on your Directory server.
- RDN Attribute - Type the relative distinguished name attribute (for example, cn) designated for the Group object on the directory server.
- Base DN - Type the base DN (in LDAP form) for the Group object on the directory server.
- ID Attribute - Type the LDAP attribute from which the ID designated for the Group object will be extracted.
Click Create.

The profile is displayed in the IDS Profiles table.

5.3.3 Editing or Deleting an Identity Directory Service Profile

To edit or delete an IDS Profile, select the name in the table and click Edit or Delete in the tool bar.

Editing the profile allows for additional configuration properties for the Identity Directory Service connection.

Name - Choose an Identity Directory Service connection to associate with the User Profile Service Provider from the drop down menu.
- If you choose either of the default Identity Directory Services (either userrole or idxuserrole) you cannot view or edit the configuration values.
- If you choose an Identity Directory Service connection that you or another Administrator created, you can view and edit the configuration values as needed.
General and Repository - Use the fields under this tab to edit the Directory Service and Repository configuration values.
- Repository Name - Choose from the menu a repository to associate with the Identity Directory Service connection. After choosing a repository, configure its properties using the following form fields.
- Directory Type - Displays the type of Directory server software hosting the Repository, for example Microsoft Active Directory, Oracle Internet Directory, and so on. This field is read-only.
- Host Information - Displays information about the host computer where the Identity Directory Service Repository is located. Add multiple hosts if the Directory server is part of a cluster. Click Add to add a new host to the table. In the Host Name column type either the IP Address or the name of the computer (or virtual computer) that the Directory server is running on. In the Port column, type the port number that the Directory server is configured to use. If the hosts are part of a cluster, in the Load Distribution column type the load amount as a percentage that should be directed to each host. For multiple hosts, the amount should add up to 100%. To delete a host, select its row in the table and click Remove. If you are not defining a new Identity Directory Service connection or creating a new repository, this field is read-only.
- Availability - Choose Failover if the cluster is configured for failover operation, or choose Load balanced if the cluster distributes the load across multiple hosts. This field is read-only if you are using an existing repository.
- SSL - Select Enabled if the connection is configured for SSL. Otherwise clear the option box. See SSL in Creating an Identity Directory Service Profile for information on how to add the SSL certificates required for the TLS connection.
- Bind DN - Type the distinguished name (DN) of the LDAP Administrator used to authenticate to the Directory server.
- Bind Password - Type the Bind DN password used to authenticate to the Directory server.
- Base DN - Type the base distinguished name (DN) where User and Group data is located.
- Password Management - selecting Enable Password Management enables password policy enforcement against the attribute values listed in Table 5-4. The corresponding options in the password policy must be configured as well.
Entity Attributes - Use the fields under this tab to view or edit the attributes. Click Add to add an attribute to the table or click Remove to delete an attribute.
- Name - The attribute name.
- Physical Attribute - The name of the corresponding physical attribute type in the underlying Repository.
- Type - The attribute's data type.
- Description - A brief description of the attribute.
- Sensitive - Select to mark that the attribute contains sensitive information such as a password.
- Read-only - Select to protect the attribute from modification.
Entities / User Properties - Use the fields under the User sub head to configure interaction with the User entities on the LDAP server.
- Create Base - Specifies the base DN (the top level of the LDAP directory tree) at which Users are defined.
- Search Base - Specifies the search base DN for Users. Only entries at or below the search base DN are considered when processing the search operation.
- Create Object Classes - Specifies the object class under which attributes associated with a person are stored.
- RDN Attribute - Specifies the relative distinguished name attribute, for example cn.
- ID Attribute - Specifies the attribute that uniquely identifies the User, such as the uid attribute or the loginid attribute.
  
  Note:
  OAM does not support multi-valued uid. In a OUD proxy scenario, the uid or loginid must be single value.
- Filter Object Classes - Specifies the object class by which to filter.
- Attributes Configuration - Specify the User attributes that should be available to, and searchable by, the User Profile Service Provider.
  - Used - Specifies if the attribute is used for Users in the directory service.
  - Attribute Name - Specifies the name of the attribute as defined on the Entity Attributes tab.
  - In Results - Select if the specified attribute should be returned in search results.
  - Searchable - Select if the specified attribute should be available for search operations.
  - Search Operator - Select a search operator from the menu to restrict how the specified attribute is searched.
- Operations Configuration - Select from Create, Update, Delete, and Search to enable those operations at the User entity level. Clear the option boxes to disable them.
Entities / Group Properties - Use the fields under the Group sub head to configure interaction with the Group entities on the LDAP server.
- Create Base - Specifies the base DN (the top level of the LDAP directory tree) at which Users are defined.
- Search Base - Specifies the search base DN for Groups. Only entries at or below the search base DN are considered when processing the search operation.
- Create Object Classes - Specifies the object class under which attributes associated with a Group are stored.
- RDN Attribute - Specifies the relative distinguished name attribute; for example, cn.
- ID Attribute - Specifies the LDAP attribute that uniquely identifies the Group.
- Filter Object Classes - Specifies the object class by which to filter.
- Attributes Configuration - Specify the Group attributes that should be available to, and searchable by, the User Profile Service Provider.
  - Used - Specifies if the attribute is used for Users in the directory service.
  - Attribute Name - Specifies the name of the attribute as defined on the Entity Attributes tab.
  - In Results - Select if the specified attribute should be returned in search results.
  - Searchable - Select if the specified attribute should be available for search operations.
  - Search Operator - Select a search operator from the menu to restrict how the specified attribute is searched.
- Operations Configuration - Select from Create, Update, Delete, and Search to enable those operations at the Group entity level. Clear the option boxes to disable them.
Relationships - Use the fields under this tab to configure the relationship between attributes for this Identity Directory Service.
- Name - The relationship name.
- (From) Entity - Choose User to select from User attributes or choose Group to select from Group attributes in the (From) Attribute column.
- (From) Attribute - Choose the attribute from which you are mapping.
- Relation - Choose the menu option that describes the relationship between the specified attribute in the From column and the specified attribute in the To column.
- (To) Entity - Choose User to select from User attributes or choose Group to select from Group attributes in the (To) Attribute column.
- (To) Attribute - Choose the attribute to which you are mapping.
- Recursive - Select if the relationship extends down the directory tree to include nested child entities or up the directory tree to include parent entities.
Relationship Configuration - Type the URI segment used to access the corresponding column in the Identity Directory Service. Use Add to add a new relationship or Remove to remove a configured relationship.
- Access URI - Type a URI segment that will be used to access a corresponding data column in the Identity Directory service. For example, if memberOf is the Access URI, then:
```
http://host:port/.../idX/memberOf
```
  would be the URI to access related entities of an entity with ID idX.
- Identity Directory Service Relation - Choose the Directory Service relationship that is to be accessed by the Access URI segment. You can configure relationships on the Relationships tab in the Identity Directory Service configuration section provided that the Identity Directory Service is not the pre-configured UserProfile Identity Provider. (You cannot configure Identity Directory Service relationships for the UserProfile Service Provider.)
- Entity URI Attribute - Type the JSON attribute name to be used in the URI response. For example, if person-uri is the specified entity URI attribute, the URI response would be as follows:
```
{ {"person-uri":uriY1, ...}, {"person-uri":uriY2, ...}, ... }
```
  where uriY1 and uriY2 are the direct URIs to access each of the related entities.
- Scope for Requesting Recursion - Use Scope attribute values with the scope query parameter to retrieve a nested level of attributes in a relationship search. To access related entities recursively, type the value to be used.
  
  If the Scope for Requesting Recursion value is the attribute value all, then the following REST URI example is used to make the request:
```
http://host:port/.../idX/reports?scope=all
```
  In this example, the URI returns the entities related to the entity with ID idX, as well as all further related entities.

5.3.4 Creating a Form-fill Application Identity Directory Service Profile

To create an Identity Directory Service Profile for a Form-fill Application, click the Create Form-fill Application IDS Profile button on the left of the User Identity Stores console page.

(See Figure 5-3.)

Creating an Identity Directory Service Profile and Editing or Deleting an Identity Directory Service Profile contain definitions for most of the Form-fill attributes. Additional definitions for the Entity Search Bases section specific to this type of profile are listed below.

User Search Base - Full DN for the node at which enterprise users are stored in the directory; for example, cn=Users,realm_DN.
App Template Search Base - Full DN for the node from which searches for the Application Templates will begin.
Top Search Base - Full DN for the node from which searches will begin; for example, cn=realm_DN.

5.3.5 Understanding the Pre-Configured Identity Directory Service Profile

Mobile and Social provides a pre-configured IDS Profile named UserIdentityStore1. The Pre-Configured Identity Directory Service Profile allows lookup and update tasks to be performed on directory objects using Mobile and Social.

5.3.6 Creating an Identity Directory Service Repository

You can crate an Identity Directory Service repository from the Configuration console.

To create an Identity Directory Service repository:

At the top of the Oracle Access Management console, click Configuration.
In the Configuration console, click User Identity Stores.
Click Create under IDS Repositories.

The Create IDS Repository page is displayed as in Figure 5-5.

Figure 5-5 Create IDS Repository Page

Description of "Figure 5-5 Create IDS Repository Page"
Provide the following values for the new Identity Directory Service repository.
1. Name: the entry must be a unique.
2. Select the Directory Type from the drop down choices.
Click Add to configure the physical location of the repository (Host name, Port number and Load Weightage percentage).
Configure the Repository properties as follows:
1. (Repository) Name - Enter a new unique name to create, or choose an existing one from the menu. After entering a new name, configure properties for the Identity Directory Service connection.
2. Directory Type - Select the type of directory server software hosting the Repository; for example, Microsoft Active Directory or Oracle Internet Directory. If your directory is not listed, leave this field empty. If you are not defining a new Identity Directory Service connection or creating a new repository, this field is read-only.
3. Host Information - Contains information about the host computer on which the Identity Directory Service Repository is located. Add multiple hosts if the directory server is part of a cluster. Click Add to add a new host to the table. In the Host Name column type either the IP Address or the name of the computer (or virtual computer) on which the Directory server is running. In the Port column, type the port number that the directory server is configured to use. If the hosts are part of a cluster, in the Load Distribution column type the load amount as a percentage that should be directed to each host. For multiple hosts, the amount should add up to 100%. To delete a host, select its row in the table and click Remove. If you are not defining a new Identity Directory Service connection or creating a new repository, this field is read-only.
4. Availability - Choose Failover if the cluster is configured for failover operation, or choose Load balanced if the cluster distributes the load across multiple hosts. This field is read-only if you are using an existing repository.
5. SSL - Select Enabled if the connection is configured for SSL. See SSL in Creating an Identity Directory Service Profile for information on how to add the SSL certificates required for the TLS connection. (See the Securing Applications with Oracle Platform Security Services for SSL configuration details.)
6. Bind DN - Type the distinguished name (DN) of the LDAP Administrator used to authenticate to the Directory server.
7. Bind Password - Type the Bind DN password used to authenticate to the Directory server.
8. Base DN - Type the base distinguished name (DN) where User and Group data is located.
9. Password Management - selecting Enable Password Management enables password policy enforcement against the attribute values listed in Table 5-4. The corresponding options in the password policy must be configured as well.
Click Test Connection to confirm the values are correct.
Click Create.

The repository is displayed in the IDS Repositories table.

5.3.7 Editing an Identity Directory Service Repository

You can edit an Identity Directory Service repository from the Configuration console (Configuration > User Identity Stores > IDS Repositories).

When creating an Identity Directory Service Repository, Advanced LDAP Connection Settings are not available. To modify the LDAP Connection Settings, you must edit the Identity Directory Service Repository. The default LDAP Connecting settings are optimal for most deployments. We do not recommend changing the defaults.

Note:

The Advanced LDAP Connection Settings are not available when the LDAP Server does not support this capability (for example, Embedded OVD, OPSS).

The following table shows the connection options and their default values:

Parameter	Description	Default Value
Search Timeout	Specifies the time period within which a connection between OAM and the LDAP server must be established.	`120000` milliseconds
TCP Timeout	Specifies the time period within which OAM must receive a TCP ACK message during a TCP interaction. Once exceeded, the TCP packet will be retransmitted.	`180000` milliseconds
Connection Pool Initial Size	Specifies the minimum number of LDAP connections in the LDAP connection pool.	`5`
Connection Pool Maximum Size	Specifies the maximum number of LDAP connections in the LDAP connection pool.	`10`
Size Limit	Specifies the maximum number of Directory entries that will be returned during an LDAP search. A value of `O` means unlimited.	`0`
Keep Alive	Enables keep-alive for the socket connection between OAM and the LDAP Server.	Not Enabled

5.4 Managing Administrator Roles

By default, the Oracle Access Management Administrators role 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. Administrator login works only when the Authentication Scheme (and assigned Authentication Module), also uses the System Store. This section provides the following topics:

5.4.1 Understanding Administrator Roles

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 appears. You can add new Administrator roles when adding or editing a User Identity Store registration. Figure 5-6 shows the page and controls to use.

Figure 5-6 Add System Administrator Roles

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

5.4.2 Defining and Removing Administrator Roles

Oracle Access Management Administrator roles which must be stored in the User Identity Store designated as the System Store can be defined or removed.

First, define the desired LDAP group to use for Administrators and then ensure that your Administrators group is available in the group search base. (See About using the System Store for User Identities.) To add or remove an Administrator role from the System Store, follow this procedure.

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. At the top of the Oracle Access Management Console, click Configuration.
2. In the Configuration console, click Administration.
  
  The registered System Store can not be changed from this page.
3. Search the System Store to find configured administrators.
Add User Roles:
1. Click the Grant (+) button above the Access System Administrators table to display the Add Users and Groups dialog box.
2. Select User in the Type list and click Search.
3. In the results list, click the desired user, then click Add Selected.
4. Repeat as need to add desired Administrator User roles.
5. Click Apply to submit user roles.
Add Group Roles:
1. Click the Grant (+) button above the Access System Administrators table to display the Add Users and Groups 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.
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.
Correct any authentication plug-ins that use the System Store (if this is a new store).

This procedure is described in "Orchestrating Multi-Step Authentication with Plug-in Based Modules"
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".

5.5 Managing the Policy and Session Database

Oracle Access Management requires a database to store Access Manager policy data, password management data, and Access Manager sessions in a production environment. 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.

This section includes the following topics:

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

In a production environment, the Oracle database stores policy data, password management data, and sessions of the Access Manager.

The policy store database, by default, stores the following data:

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.

5.5.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 Navigating the Repository Creation Utility Screens to Create the Schemas in the 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:

Configuring the Oracle OAM Suite Domain in the Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management.

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

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.

Create a new Data Source instance for session data:

From the WebLogic Administration Console, Domain Structure panel, expand the domain name, Services node.
Expand JDBC, Data Source.
Create a new Data Source with the JNDI name jdbc/oamsession.
Save the changes.
Stop the OAM Servers and the AdminServer to avoid potential loss of data during the next step.

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

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>

See Updating OAM Configuration

Restart AdminServer and OAM Servers.

5.6 Introduction to Oracle Access Management Keystores

A Java keystore is set up to be used for certificates for Simple or Certificate-based communication between OAM Servers and Webgates during authorization. The keystore bootstrap also occurs on the initial AdminServer startup after running the Configuration Wizard.

This section provides the following topics:

5.6.1 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 has a secret key that other agents cannot read.
During agent and application registration, a key is generated for encrypting and decrypting SSO Cookies (for Webgates).

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

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

Table 5-5 Access Manager Keys and Storage

Keys and Storage	Description
Access Manager Cryptographic keys	One per agent secret key shared between OAM Webgate and OAM Server 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 Securing Communication.

See Also:

"Identity Federation Keystore"

"About Communication Between OAM Servers and WebGates"
Secure Communication in Administering Oracle Fusion Middleware for details about the SSL automation tool and managing ports for WebLogic Server, Oracle HTTP Server, and Oracle Fusion Middleware

5.6.2 Access Manager Keystores

Keystores for Access Manager and Security Token Service are created and configured during the installation of the Access Manger.

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

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

Keystore Description

Keystore	Description
System Keystore / Partner Keystore .oamkeystore	The container for keys and certificates associated with OAM Server instances (OAM secret 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.
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.
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: "Certificate Validation and Revocation"
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.
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: Managing Keys and Certificates in Securing Applications with Oracle Platform Security Services.

System Keystore / Partner Keystore

.oamkeystore

The container for keys and certificates associated with OAM Server instances (OAM secret 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.

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.

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:

"Certificate Validation and Revocation"

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.

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:

Managing Keys and Certificates in Securing Applications with Oracle Platform Security Services.

5.6.3 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:

5.7 Integrating a Supported LDAP Directory with Oracle Access Manager

A centralized LDAP store can be enabled for use with Oracle Access Manager post-installation.

Oracle Internet Directory is featured in this discussion however the tasks are the same regardless of your chosen LDAP directory.

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 Introduction to IdM Suite Components Integrationin Integration Guide for Oracle Identity Management Suite.