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.

• Understanding User Identity Stores

• About using the System Store for User Identities

• About Using Multiple Identity Stores

• User Identity Store Settings

• Registering a New User Identity Store

• Viewing or Editing a User Identity Store Registration

• Deleting a User Identity Store Registration

Note:

Oracle recommends that you use the Profiles to access identity data stores rather than the legacy OAM ID Stores function as it will be deprecated in a future release. The 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 Oracle Fusion Middleware Securing 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 after the IAMSuiteAgent provider 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, and delete the IAMSuiteAgent provider from WebLogic 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.

  • Security Token Service: An LDAP server is required for Security Token Service to map the Username token referencing the user to an LDAP User record, and thus use that record to populate the outgoing token. Ensure that the desired LDAP server is registered and configured as the Oracle Access Management Default Identity Store, as described in "About using the System Store for User Identities". For more information, see "Configuration overview: Identity Propagation with the Username Token".

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

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

• When evaluating policies during authentication

• When evaluating identities for authorization conditions in a policy

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

Note:

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

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

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

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

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

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

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

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

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 11g support multiple LDAP URLs with failover capability. The Identity Assertion Provider fails over to the next LDAP URL based on the order in which these appear. Enter one (or more) LDAP URLs in host:port format, Multiple URLs must be separated by a space or new line. There is no need to specify ldap:// or ldaps://(which supports SSL_NO_AUTH) in the URL value: localhost:myhost:7001 Note: The number of characters a supported URL can have is based on the browser version. Ensure that your applications do not use URLs that exceed the length that Oracle Access Management and the browser can handle.
	Bind DN	The user DN for the connection pool over which all other BINDs occur. Oracle recommends a non administrative user with appropriate Read and Search privileges for the user and group base DNs. For example: uid=amldapuser,ou=people,o=org
	Password	The password of the Principal, which is encrypted for security.
Users and Groups	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> Increment oam-config.xml version by one after the edit.
	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 Oracle Fusion Middleware Installation Guide for 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:

1. At the top of the Oracle Access Management Console, click Configuration.

2. In the Configuration console, click User Identity Stores.

3. In the OAM ID Stores section, click Create.

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

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

6. Close the registration page.

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

8. Set Default Store: See "About using the System Store for User Identities".

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

10. 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:

1. At the top of the Oracle Access Management Console, click Configuration.
2. In the Configuration console, click User Identity Stores.
3. In the OAM ID Stores list, select the target identity store and click Edit.
4. Modify values as needed (see Table 5-4).
5. Click Apply to update the registration (or close the tab without applying changes).
6. Test Connection: Click Test Connection button to confirm connectivity, then close the Confirmation window.
7. Set as System or Default Store: See "About using the System Store for User Identities".
8. Manage Administrator Roles: See "Managing Administrator Roles".
9. 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"

10. 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:

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