5 Managing Data Sources

This chapter provides the steps 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.

This chapter includes the following sections:

5.1 Introducing the Data Sources

The term data source is a Java Database Connectivity (JDBC) term used within Oracle Access Management to refer to a collection of user identity stores or a database for policies. Oracle Access Management supports several types of data sources that are typically installed for the enterprise. Each data source is a storage container for the various types of information documented in Table 5-1.

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

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

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 Oracle Fusion Middleware Installation Guide for 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 Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management, Oracle Access Management configuration data is stored in an XML file: oam-config.xml.

See "About the oam-config.xml Configuration Data File".

Keystores

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

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:

Identity Federation

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

Security Token Service

Security Token Service uses only the designated Default Store for user identities.

Mobile and Social

Mobile and Social provides its own Identity Directory Service configuration that points to directory servers for user authentication and/or user profile services. There is no dependency on the global data sources upon which Access Manager and other Oracle Access Management services rely.

See Also:

The following sections contain additional details.

5.1.1 About the oam-config.xml Configuration Data File

Oracle Access Management provides an XML file (oam-config.xml) containing all Access Manager-related system configuration data. Any changes made to the Access Manager deployment configuration, including server and agent registration, are stored in oam-config.xml and are automatically propagated to each Access Manager server. Each Access Manager server has a local copy of the latest configuration XML file. Whether you have failover configured in a high-availability environment or not, all Access Manager servers always have the latest oam-config.xml file.

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

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

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

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

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

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, as described in "Specifying the Oracle Access Management Console Administrator".

5.2 Managing OAM Identity Stores

This section provides the steps you need to manage user identity store registrations 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 Section 5.3, "Managing the Identity Directory Service User Identity Stores."

5.2.1 About User Identity Stores

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

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

During initial WebLogic Server domain configuration using the Oracle Fusion Middleware Configuration Wizard, the Embedded LDAP is configured as the one and only user identity store for Oracle Access Management. Within the Embedded LDAP, the Administrators group is created with weblogic seeded as the default Administrator.

See Also:

Oracle Fusion Middleware Securing Oracle WebLogic Server

Note:

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

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

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

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

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

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

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

Note:

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

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

5.2.2 Using Multiple Identity Stores

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

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

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

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

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

  • When evaluating policies during authentication

  • When evaluating identities for authorization conditions in a policy

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

Note:

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

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

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

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

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

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

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

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

Authorization Policy Administration

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

Run Time

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

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

Sessions

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

Auditing and Logging

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

See Also:

5.2.3 About the User Identity Store Registration Page

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

Figure 5-1 illustrates 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 follows
Description of "Figure 5-1 Creating User Identity Store Registration "

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

Table 5-3 User Identity Store Elements

Elements Description

Store Name

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

Store Type

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

LDAP Provider List

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

Description

Optional.

Enable SSL

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

Location and Credentials

Description

Location

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

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

localhost:myhost:7001

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

Bind DN

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

For example:

uid=amldapuser,ou=people,o=org

Password

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

Users and Groups

Description

User Name Attribute

The attribute that identifies the username.

For example:

uid

User Search Base

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

For example:

ou=people,ou=myrealm,dc=base_domain

User Filter Object Class

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

Group Name Attribute

The attribute that identifies the group name.

Default: cn

Group Search Base

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

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

For example:

ou=groups,ou=myrealm,dc=base_domain

Group Filter Classes

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

Enable Group Cache (size)

Boolean value for group cache: true or false.

Default: true

Group Cache Size

Integer for the group cache size.

Default: 10000

Group Cache TTL (seconds)

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

Default: 0

Connection Details

Description

Minimum Pool Size

The smallest size set for the connection pool.

Default: 10

Maximum Pool Size

The greatest size set for the connection pool.

Default: 50

Wait Timeout

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

Default: 120

Inactivity Timeout

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

Results Time Limit (seconds)

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

Default: 0

Retry Count

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

Default: 3

Referral Policy

One of these values:

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

  • ignore: Ignores referral entries during an LDAP search

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

Figure 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 follows
Description of "Figure 5-2 System Store Registration "

See Also:

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

5.2.4 Registering a New User Identity Store

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

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

See Also:

Prerequisites

To register a new user identity store definition

  1. From the Oracle Access Management Console Launch Pad, click User Identity Stores.

  2. Click Create.

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

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

  5. Close the registration page.

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

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

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

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

    4. Click Apply.

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

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

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

5.2.5 Viewing or Editing a User Identity Store Registration

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

Prerequisites

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

To view or modify a user identity store registration

  1. From the Oracle Access Management Console Launch Pad, click User Identity Stores.

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

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

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

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

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

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

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

  9. Close the page when you finish.

5.2.6 Deleting a User Identity Store Registration

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

Note:

You cannot delete the Default Store or System Store registration.

To delete a secondary user identity store registration

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

  2. From the Oracle Access Management Console Launch Pad, click User Identity Stores

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

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

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

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

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

  1. Support for different types of user directories including integration with native user/password state managed by the directory.

  2. Consistent administration user interface and a paradigm for working with different identity stores across Oracle Identity Management components.

  3. Built in failover and load balancing capabilities.

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

Surrounding text describes Figure 5-3 .

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

To create an Identity Directory Service profile, proceed as follows.

  1. Click User Identity Stores from the Launch Pad.

  2. Click Create under IDS Profile.

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

    Figure 5-4 Create IDS Profile Page

    Description of Figure 5-4 follows
    Description of "Figure 5-4 Create IDS Profile Page"

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

  4. 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 Oracle Fusion Middleware Application Security Guide for SSL configuration details.)

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

  5. Configure the User properties to configure the LDAP User object in Mobile and Social User Profile services.

    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.

  6. Configure the Group properties to configure the LDAP group object in Mobile and Social User Profile services.

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

  7. 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 on 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 that Mobile and Social uses to connect to the Directory Service.

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

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

  • Entity Attributes - Use the fields under this tab to view or edit the attributes that Mobile and Social uses to navigate the corporate directory service schema. 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 how Mobile and Social interacts 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.

    • 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 how Mobile and Social interacts 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 sent from the Mobile and Social server. 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. The Mobile and Social default configuration uses two scope attribute values: toTop and all. 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.)

Section 5.3.2, "Creating an Identity Directory Service Profile" and Section 5.3.3, "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. This 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

To create an Identity Directory Service repository, proceed as follows.

  1. Click User Identity Stores from the Launch Pad.

  2. Click Create under IDS Repository.

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

    Figure 5-5 Create IDS Repository Page

    Description of Figure 5-5 follows
    Description of "Figure 5-5 Create IDS Repository Page"

  3. Provide the following values for the new Identity Directory Service repository.

    • Name: the entry must be a unique.

    • Select the Directory Type from the drop down choices.

  4. Click Add to configure the physical location of the repository (Host name, Port number and Load Weightage percentage).

    • Availability - select Failover or Load balanced

    • SSL - select to enable

    • Bind DN

    • Bind Password

    • Base DN

  6. Click Test Connection to confirm the values are correct.

  7. Click Create.

    The profile is displayed in the IDS Profiles table.

5.4 Setting the Default Store and System Store

Users with valid Oracle Access Management Administrator credentials can designate a user identity store registration as either the Default Store or the System Store. The Default Store is required for the Security Token Service and migration when patching. Administrator roles and credentials must reside in the System Store. You can define the appropriate store from the drop down menu. UserIdentityStore1 is the embedded LDAP store.

Note:

Changing the System Store impacts the entire identity management domain. For example, 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 also modified to avoid a lockout.

You can modify the Default and System Identity Stores configurations from the User Identity Stores link on the Launch Pad. Figure 5-6 is a screen capture of the User Identity Stores page.

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

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

The supported method of configuring the ID Store for a WebSphere installation is documented in the Oracle Fusion Middleware Third-Party Application Server Guide for Oracle Identity and Access Management. Additional information regarding store configurations can be found in the following sections.

5.5 Managing the Administrators Role

This section provides the following topics:

5.5.1 About Managing the Administrator Role

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

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

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

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

Description of Figure 5-7 follows
Description of "Figure 5-7 System Store Registration with Access System Administrators Section"

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

Figure 5-8 Add System Administrator Roles

Description of Figure 5-8 follows
Description of "Figure 5-8 Add System Administrator Roles"

5.5.2 Managing Administrator Roles

The following procedure explains how to define or remove Oracle Access Management Administrator roles which must be stored in the User Identity Store designated as the System Store. First, define the desired LDAP group to use for Administrators and then ensure that your Administrators group is available in the group search base

Prerequisites

Setting the Default Store and System Store

To add or remove an Administrator role from the System Store

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

    1. From the Oracle Access Management Console Launch Pad, click Administration.

      The registered System Store can not be changed from this page .

    2. Search the System Store to find configured administrators.

  2. 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 the Search button.

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

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

    5. Click Apply to submit user roles.

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

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

  5. Correct any authentication plug-ins that use the System Store (if this is a new store).

    This procedure is decscribed in "Orchestrating Multi-Step Authentication with Plug-in Based Modules"

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

This section includes the following topics:

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

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

Note:

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

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

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

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

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

Note:

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

See Also:

"Managing the Policy and Session Database"

5.6.2 About Database Deployment

Oracle requires a single database as the policy store in production environments. This single database can also be used to store session data. Using the database as the session store provides greater scalability and fault-tolerance (against a power event taking all servers down).

Note:

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

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

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

  • Database login ID and password

  • Database Service name and location

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

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

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

See Also:

Oracle Fusion Middleware Installation Guide for Oracle Identity and Access Management

5.6.3 Configuring a Separate Database for Access Manager Sessions

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

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

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

Note:

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

To create and use an independent database for session data

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

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

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

    2. Expand JDBC, Data Source.

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

    4. Save the changes.

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

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

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

      From:

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

      To:

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

  3. Restart AdminServer and OAM Servers.

5.7 Introduction to Oracle Access Management Keystores

This section provides the following topics:

5.7.1 About Access Manager Security Keys and the Embedded Java Keystore

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

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

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

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

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

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

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

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

Table 5-4 Access Manager Keys and Storage

Keys and Storage Description

Access Manager Cryptographic keys

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

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

  • One OAM Server key

Key storage

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

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

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

See Also:

"About Identity Federation Keystore"

5.7.2 About Access Manager Keystores

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

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

Keystore Description

System Keystore / Partner Keystore

.oamkeystore

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

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

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

$DOMAIN_HOME/config/fmwconfig/.oamkeystore

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

See Also:

Trust Keystore

amtrustkeystore

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

$DOMAIN_HOME/config/fmwconfig/amtruststore

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

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

See Also:

Certificate Revocation Lists (CRL)

amcrl.jar

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

amcrl.jar contains CRL files in the DER format:

$DOMAIN_HOME/config/fmwconfig/amcrl.jar

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

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

See Also:

Oracle WSM Agent Keystore

default-keystore.jks

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

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

See Also:

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

OPSS Keystore

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

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

See Also:

.cohstore.jks

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

5.7.3 About Identity Federation Keystore

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

  • Sign outgoing assertions

  • Decrypt incoming XML encrypted data contained inside the SAML message

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

$DOMAIN_HOME/config/fmwconfig/.oamkeystore

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

See Also:

5.8 Integrating a Supported LDAP Directory with Oracle Access Manager

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

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

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

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

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

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

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

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