The E-Business Suite has its own security and user-management capabilities. You can use the E-Business Suite's native features to authenticate users, authorize users (i.e. assign responsibilities to them), and manage your EBS user repository. The majority of E-Business Suite system administrators simply use these built-in capabilities for enabling access to the E-Business Suite.
When EBS built-in capabilities aren't enough
Some organisations have third-party user authentication systems in place. These include CA Netegrity SiteMinder, Windows Kerberos, and others. These organisations frequently use third-party LDAP directory solutions such as Microsoft Active Directory, OpenLDAP, and others.
We don't certify the E-Business Suite with those third-party products directly, and we don't have any plans to do so. This article is intended to explain why Oracle Internet Directory (OID) is required when integrating with Oracle Access Manager (OAM), but you can safely infer that the same requirements prevent the use of third-party authentication products directly with the E-Business Suite.
It's possible to integrate the E-Business Suite with those third-party solutions via Oracle Access Manager and Oracle Internet Directory. See these articles:
Before going on, I'd recommend reading one of those two third-party integration articles. If you don't have those concepts under your belt, the rest of this article isn't going to make much sense.
Why does EBS require OID with OAM?
Oracle Access Manager itself doesn't require Oracle Internet Directory. However, Oracle Internet Directory is a mandatory requirement when Oracle Access Manager is integrated with the E-Business Suite.
Why? The short answer is that the E-Business Suite has hardcoded dependencies on Oracle Internet Directory for this configuration. These dependencies mean that you cannot replace Oracle Internet Directory with any third-party LDAP directory for this particular configuration.
There are two cases of hardcoded dependencies on Oracle Internet Directory:
1. Reliance on Oracle GUIDs
From the articles linked above, you know that user authentication is handled by Oracle Access Manager, and user authorization is handled by the E-Business Suite itself. This means that there are two different user namespaces.
These namespaces must be linked and coordinated somehow, to ensure that a particular user logging in via Oracle Access Manager is the same user represented within the E-Business Suite's own internal FNDUSER repository.
We associate externally-managed Oracle Access Manager users with internally-managed E-Business Suite users via a Global Unique Identifier (GUID). These Global Unique Identifiers are generated exclusively by Oracle Internet Directory.
The E-Business Suite has hardcoded functions to handle the mapping of these Global Unique Identifiers between Oracle Access Manager and the E-Business Suite. These mapping functions are specific to Oracle Internet Directory; it
isn't possible to replace Oracle Internet Directory with a generic
third-party LDAP directory and still preserve this functionality.
2. Synchronous user account creation
The E-Business Suite is predominantly used internally within an organisation. Certain E-Business Suite application modules can be made visible to users outside of an organisation. These include iStore, iRecruitment, iSupplier, and other application modules where the users aren't necessarily restricted to an organisation's own employees.
Users of some of those application modules expect to be able to register for a new account and use it immediately. This makes sense. If you're posting job openings via iRecruitment, potential applicants shouldn't need to hold off on submitting their resumes while your E-Business Suite sysadmin creates an account manually, assigns EBS responsibilities, and emails them the account login details. They'll be long gone before that happens.
This means that EBS application modules that support self-registration must create user accounts synchronously. A new account must be created within the E-Business Suite and the externalized directory at the same time, on demand.
The E-Business Suite has hardcoded dependencies upon Oracle Internet Directory function calls that handle these synchronous account creation tasks. These function calls are specific to Oracle Internet Directory; it isn't possible to replace Oracle Internet Directory with a generic third-party LDAP directory and still preserve this functionality.
Sun is setting for Oracle Single Sign-On
The older articles linked above refer to Oracle Single Sign-On. All conceptual references to Oracle Single Sign-On apply equally to Oracle Access Manager. Oracle Access Manager offers the same capabilities as Oracle Single Sign-On when integrated with the E-Business Suite.
You may have noticed that I have specifically been referring to Oracle Access Manager rather than Oracle Single Sign-On in this article. There's a very good reason for this.
The Fusion Middleware Lifetime Support Policy shows that Premier Support for Oracle Single Sign-On 10gR2 ends on December
2011. If you're
using Portal 11gR1, Forms & Reports 11gR1, or Discoverer 11gR1,
Premier Support for Oracle Single Sign-On 10gR2 is extended to December
Extended Support is not available for Oracle Single Sign-On 10gR2. This is true
regardless of whether you're using those other Fusion Middleware 11gR1 products or not. These support policy timelines for Oracle Single Sign-On are not affected by the E-Business Suite's own support timelines. There are no special exceptions from these Fusion Middleware support timelines for E-Business Suite customers.
Given that the Oracle Single Sign-On is nearing its end-of-life,
anyone considering a new external authentication solution for the
E-Business Suite should use Oracle Access Manager at this point. If
you're currently using Oracle Single Sign-On, I would recommend
evaluating your plans for migrating to Oracle Access Manager as soon as