Introduction

The Oracle Access Manager (OAM) product delivers so many features and functions, but have you ever thought about what it can do from the most simplistic concept?

At its highest level it validates who you are (Authentication -Authn) and what you can or cannot see (Authorization – Authz) using a User Identity Stores.

This blog will provide some basic concepts and practices of how it accomplishes this. Some of the information is based on my experiences with the OAM product and is my opinion. As with anything, what we decide to do has its own merit. We balance the information and decide what is best for our environments.

General Concept

Out of box (OOB) – 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.

When attempting to access an Access Manager-protected resource, a user can be authenticated against any store, not simply the designated Default Store.

User Identity Store

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.

The “User Identity Store” uses lib-ovd to communicate to back-end LDAP servers.

Supported LDAP Providers

  • Embedded LDAP: Oracle WebLogic Embedded LDAP
  • OID: Oracle Internet Directory
  • OVD: Oracle Virtual Directory
  • AD Microsoft Active Directory
  • e Directory: Novell eDirectory
  • ODSEE: Oracle Directory Server enterprise Edition
  • OUD: Oracle Directory Service
  • SLAPD: OpenLDAP Directory
  • IBM: IBM Tivoli Directory

Implementation Methods

Legacy OAM ID Stores … Standard ID Store

This method was introduced in the initial OAM 11g Release 1 (11.1.1.3) release and is still used today with OAM 12c. For more information on this method please refer to the “Middleware, Identity Management (IdM), Access Manager, Release 12.2.1.4, 5.2 Registering and Managing User Identity Stores”

Identity Directory Service Profiles … Service Profiles ID Store

Identity Directory Service Profiles was first introduced in the 11g Release 2 (11.1.2.2). For more information on this method please refer to the “Middleware, Identity Management (IdM), Access Manager, Release 12.2.1.4, 5.3 Managing the Identity Directory Service User Identity Stores”

Legacy OAM ID Stores VS Identity Directory Service Profiles

I think the overall thought of introducing the Identity Directory Service Profiles method of an Identity store was based on the current “recommendation” at that time, to take advantage of the architecture where any product residing in the same WLS domain could use the same store, as opposed to each one having its own configuration.

Since then, we have moved away from that thought and recommend that each IDM product be installed in their own WSL domain, which means this Identity Directory Service Profiles Store type may not fit.

  • Just like anything else they each have their +’s and –‘s; and what works best is dependent on the environment it will be used in.

Default Store

As the name implies, the User Identity 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.

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

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.

The following steps assume that the Identity store has already been registered and tested, and that you are now going to make this store the System Identity Store and that the current System Identity Store is the OOB embedded LDAP.

The Steps to Register a System Identity Store, will be covered in my May 2023 blog.

OAM Console

The Test Button

The biggest point here I want to point out is the difference between the mechanisms used by the  “Test Connection” button and the LDAP  runtime communication to the OAM server are not the same. Just because the “Test Connection” can be successful, does not guarantee the LDAP runtime communication will also be successful.

The OAM console LDAP store “Test Connection” button uses a java applet. Beyond that I am not sure what logic it uses, I just know it its different. In my opinion it provides an alternative method where telnet, netstat, or any system tools cannot be used to provide some confidence it is basic communication,

The LDAP runtime communication used lib-ovd.

How Does OAM Know Which User Identity Store To Use?

To illustrate this concept, we will use the OAM console as an example. Note this is what is seen in the default out of box configuration.

Application Domain

  • The application domain used by the OAM console is called “IAM Suite”

Authentication Policy

  • The Authentication Policy used by the OAM console is called “OAM Admin Console Policy”

Authentication Scheme

  • The Authentication Scheme used by the OAM console is called “OAMAdminConsoleScheme”

Authentication Module

  • The Authentication Module used by the OAM console is called “LDAP”

User Identity Store

  • The User Identity Store used by the OAM console is called “UserIdentityStore1”

Directory Type

  • The Directory Type used by the OAM console is called “Embedded_LDAP”

Warp up

The Oracle Access Manager (OAM) User Identity Store utilizes the Lightweight directory access protocol (LDAP) to find data about organizations, persons, and more. It has two main goals: to store data in the LDAP directory and authenticate users to access the directory based on relationships between these entities.

This blog showed in simple terms, how the Oracle Access Manager User Identity Store fits in to this mold based on its product documentation and personnel experience.

Resources

lesRelated Articles:

  • Simplify Knowing Your Identity and Access Management Environment – Overlooked Resources Part 1 of 6-part series that discusses overlooked resources that will help improve many aspects of an Administrators Duties, such as upgrade, maintenance and overall ease of resolving environment issues.