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

5.2.1 About User Identity Stores

A User Identity Store is a centralized LDAP store in which an aggregation of administrator and user-oriented data is kept and maintained in an organized way:

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

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

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

Note:

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

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

During initial WebLogic Server domain configuration using the Oracle Fusion Middleware Configuration Wizard, the embedded LDAP is configured as the one and only user identity store.

Note:

The embedded LDAP performs best with fewer than 10,000 users. With more users, consider a separate enterprise LDAP server.

Within the embedded LDAP, the Administrators group is created with "weblogic" seeded as the default administrator.

See Also:

Oracle Fusion Middleware Securing Oracle WebLogic Server

5.2.1.1 Multiple Identity Stores

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

The System Store for Administrative logins

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

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

When evaluating policies during authentication

When evaluating identities for authorization constraints in a policy

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

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

Oracle Access Manager will address each user population and directory as identity domains. Each identity domain simply maps to configured Identity store name.

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

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

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

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

Authorization Policy Administration

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

Run Time

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

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

Sessions

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

Auditing and Logging

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

5.2.2 About the Policy and Session Database Store

The policy database must be installed according to vendor instructions, and extended with the OAM-specific schema using RCU, as described in Oracle Fusion Middleware Installation Guide for Oracle Identity Management. Running the Oracle Access Manager with Database Policy Store configuration template automatically prepares the database to store OAM 11g policy and session data.

The database is specified for Oracle Access Manager 11g during initial configuration in a Oracle WebLogic Server domain using the Oracle Fusion Middleware Configuration Wizard.

Note:

Your OAM 11g deployment can have one policy and one session store, at most. By default, a single JDBC data source is used for both.

An administrator must extend the database with the OAM-specific schema.

Note:

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

5.2.3 About the Oracle Access Manager Configuration Data File

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

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

Note:

The oam-config.xml file should not be edited. Changes could result in lost data or overwriting of the file during data sync operations.

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

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

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

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

During agent and partner (application) registration, a key is generated that is used for encrypting and decrypting SSO Cookies (ObSSOCookie for Webgates and mod_osso cookie).

Table 5-1 compares the cryptographic keys generated by Oracle Access Manager 11g, 10g, and OSSO 10g, as well as a brief description of there each is stored.

Table 5-1 Oracle Access Manager 11g, 10g, and OSSO Key Comparison

OAM 11g

OAM 10g

OSSO 10g

Cryptographic keys

One per agent secret key shared between Webgate and OAM Server

One OAM Server key

11g Webgate: OAMAuthnCookie

10g Webgate: ObSSOCookie

One global shared secret key for all OAM Webgates

One key per partner shared between mod_osso and OSSO server

OSSO server's own key

One global key per OSSO setup for the GITO domain cookie

Keys storage

Agent side: A per agent key is stored locally in the Oracle Secret Store in a wallet file

OAM 11g server side: A per agent key, and server key, are stored in the credential store on the server side

Global shared secret stored in the directory server only (not accessible to Webgate)

The keystore is not available through the console and cannot be viewed, managed, or modified.

5.2.5 About Oracle Security Token Service Keystores

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

System Keystore for keys and certificates associated with OAM Server instances

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

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

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

System Keystore: .oamkeystore

Trust Keystore: amtruststore

Partner Keystore: .oamkeystore

CRL: amcrl.jar

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

Note:

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

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

Table 5-2 User Identity Store Elements

Elements

Description

Store Name

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

Store Type

A list of all supported LDAP providers from which you can choose.

Description

Optional.

Enable SSL

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

Location and Credentials

Location

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

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

localhost:7001

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

Bind DN

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

For example:

uid=amldapuser,ou=people,o=org

Password

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

Users and Groups

User Name Attribute

The attribute that identifies the username.

For example:

uid

User Search Base

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

For example:

ou=people,ou=myrealm,dc=base_domain

User Filter Object Class

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

Group Name Attribute

The attribute that identifies the group name.

Default: cn

Group Search Base

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

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

For example:

ou=groups,ou=myrealm,dc=base_domain

Group Filter Classes

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

Enable Group Cache (size)

Boolean value for group cache: true or false.

Default: true

Group Cache Size

Integer for the group cache size.

Default: 10000

Group Cache TTL (seconds)

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

Default: 0

Connection Details

Minimum Pool Size

The smallest size set for the connection pool.

Default: 10

Maximum Pool Size

The greatest size set for the connection pool.

Default: 50

Wait Timeout

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

Default: 120

Inactivity Timeout

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

Results Time Limit (seconds)

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

Default: 0

Retry Count

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

Default: 3

Referral Policy

One of these values:

follow: Follows referrals during an LDAP search (Default)

ignore: Ignores referral entries during an LDAP search

throw: Results in a ReferralException, which can be caught by the component user.

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

5.3.2 Registering a New User Identity Store

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

After you register the identity store, you can reference it in one or more authentication modules that form the basis for authentication schemes. You can also reference it in authorization constraints in access policies.

5.4 Setting the Default Store and System Store

5.4.1 About Setting the Default Store and System Store

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

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

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

Note:

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

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

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

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

5.5 Managing the Administrators Role

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

All Administrator roles, users, and groups must be stored in the System Store. If the System Store changes, appropriate Administrator roles must be added to the new System Store. If, when editing an Identity Store registration, you designate a store as the System Store the Access System Administrator section opens on the page as shown in Figure 5-6.

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

5.6 Managing the Policy Database by Using the Console

5.6.1 About Database Deployment for Oracle Access Manager

Oracle requires a single database as the policy store, which can also be used to store session data. Using the database as the session store provides greater scalability and fault-tolerance (against a power event taking all servers down). You can have up to one policy database and one session database.

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

Database login ID and password

Database Service name and location

Using the WebLogic Configuration Wizard you can test the connection to the database. Also, the database is registered with OAM.

Basic schema creation occurs when the RCU is invoked. The RCU prepares the database to accept data for OAM 11g. Running the Oracle Access Manager with Database Policy Store configuration template automatically prepares the database to store OAM 11g policy and session data. Actual OAM policy elements are created the first time the WebLogic AdminServer is started with the Oracle Access Manager Console Console deployed.

Only one database can be registered with OAM for use as a policy store. OAM includes a read-only oam-policy.xml file in the domain home. This file should not be edited directly. Changes can result in lost data or overwriting of the file during data sync operations.

5.6.2 Configuring a Separate Database for Session Data

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

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

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

Note:

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

To create and use an independent database for session data

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

5.7 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 Manager Console, remote registration, and custom administrative commands in WLST.

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

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

After registering a User Identity Store with Oracle 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 Manager 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.

Create Authentication Providers for your LDAP provider and Configure WebLogic Server to use them to avoid multiple login pages when accessing the Oracle Access Manager Console:.

Whether you authenticate through Oracle Access Manager Console or directly through the WebLogic Server Administration Console, confirm that all authentication providers are set to SUFFICIENT for single sign-on:

Click Security Realms, myrealm, then click Providers.

Click New, enter a name, and select a type. For example:

Name: OID Authenticator

Type: OracleInternetDirectoryAuthenticator

OK

In the Authentication Providers table, click the newly added authenticator.

On the Settings page, click the Common tab, set the Control Flag to SUFFICIENT, then click Save.

Click the Provider Specific tab, then specify the following values for your deployment:

Host: LDAP host. For example: example

Port: LDAP host listening port. 3060

Principal: LDAP administrative user. For example: cn=*********

Credential: LDAP administrative user password. ********

User Base DN: Same search base as the LDAP user.

All Users Filter: For example: (&(uid=*)(objectclass=person))

User Name Attribute: Set as the default attribute for username in the LDAP directory. For example: uid.

The following procedure guides as you set up an LDAP Authentication Method that points to your registered User Identity Store and an Authentication Scheme that uses this LDAP module for Form or Basic authentication. OAMAdminConsoleScheme is used in this example on the presumption that you designated your new LDAP store as the System Store. Your environment might be different.

5.7.4 Validating Authentication and Access

The procedure here provides several methods for confirming that Agent registration and authentication and authorization policies are operational. The procedures are nearly identical for both OAM Agents and OSSO Agents (mod_osso). However, OSSO Agents use only the authentication policy and not the authorization policy.

To verify authentication and access

Using a Web browser, enter the URL for an application protected by the registered Agent to confirm that the login page appears (proving that the authentication redirect URL was specified appropriately). For example:

http://myWebserverHost.example.com:8100/resource1.html

Confirm that you are redirected to the login page.

On the Sign In page, enter a valid username and password when asked, and click Sign In.

Confirm that you are redirected to the resource and proceed as follows:

Success: If you authenticated successfully and were granted access to the resource; the configuration is working properly.

Failure: If you received an error during login or were denied access to the resource, check the following:

Authentication Failed: Sign in again using valid credentials.

Access to URL ... denied: This userID is not authorized to access this resource.