Thursday Aug 10, 2006

Aliases, Maiden Names and Nicknames

You know, I've never really understood how nicknames are worked out.  It makes sense that Jon can be short for Jonathon.  But how do you get from John to Jack?  And from William to Bill?


Regardless of the mystifying linguistic antecedents, you can accomodate this state of affairs for user management with the combination of Oracle Internet Directory and the E-Business Suite.

Linking Apps Users with OID Users

If you've been following our series of articles on using Single Sign-On and Oracle Internet Directory 10g with the E-Business Suite, you know that we link user accounts in Oracle Internet Directory with their corresponding user accounts in the E-Business Suite, like this:

Link Apps Account to OID 2:

Every user in Oracle Internet Directory has a Global Unique Identifier (GUID).  The E-Business Suite stores this Global Unique Identifier in its own user directory (FND_USER), creating a unique link between the two accounts.

Using Different Names in Apps and OID

Since the users are linked by a numerical Global Unique Identifier, it doesn't matter if their actual userids in the two namespaces don't match exactly.  In addition to accomodating those mystifying nicknames, aliases, and maiden names, this is useful for integrating the E-Business Suite with LDAP directories with different userid naming conventions.

In the example above, the user's ID in Oracle Internet Directory is "john.smith", whereas his userid in Apps is "jsmith".  The user logs on to Single Sign-On using his "john.smith" userid and transparently passes through to Apps with responsibilities tied to his "jsmith" account. 

Assuming Multiple Identities

One of our largest E-Business Suite customers -- one of the world's largest multinationals -- has centralized their global business services.  In this business model, a single purchasing agent acts as the purchaser for different geographic organizations. 

Each of these different organizations have their own business setups, so separate user accounts have been created for each organization.  A given purchasing agent logs into the E-Business Suite using different accounts.

The brute-force approach to handling this is to require the purchasing agent to remember different passwords for each account.  A more elegant solution is to link his Oracle Internet Directory userid to each of the different Apps accounts, like this:

Link Multiple Apps Accounts:

Using this approach, the purchasing agent logs into Single Sign-On using his "john.smith" account.  One of the linked accounts is flagged as the default account, and he can easily switch to the other accounts without having to log out and back in again with a different userid.

Not in the Other Direction

This "one-to-many" link is fully supported with both Release 11i and 12.  In other words, you can link a single Oracle Internet Directory account to multiple Apps accounts.

"Many-to-one" links are not supported, however.  In other words, it's not possible to link multiple Oracle Internet Directory accounts with a single Apps account.

Integration with Third-Party LDAP Directories

You might have a third-party LDAP whose userid naming conventions differ from your E-Business Suite environment.  If so, your best approach is to ensure that Oracle Internet Directory is populated with those third-party userids, like this:

Tuesday Aug 08, 2006

Password Management with Third-Party Solutions

Editor Jan. 12, 2007 Update:  Oracle Identity Management 10g 10.1.4.0.1 is now certified with the E-Business Suite. 

We've now demonstrated that passwords no longer need to be maintained in the E-Business Suite when you've implemented Single Sign-On 10g integration.  What happens to passwords in a configuration that includes a third-party LDAP directory like Microsoft Active Directory, and a third-party single sign-on solution like Microsoft Kerberos?


Third-Party Integration In A Nutshell

Before we get to password management, I'd recommend that you review my earlier article about integrating the E-Business Suite with third-party LDAP and single sign-on solutions

If you're in a hurry, here's a quick recap of the key points:
  • Oracle Internet Directory is a mandatory hub for synchronizing user information between a third-party LDAP directory and the E-Business Suite
  • The third-party LDAP directory is usually considered to be the master "source of truth" for user credentials

  • Oracle Single Sign-On is a mandatory prerequisite for delegating E-Business Suite's user authentication to a third-party single sign-on solution
Using Oracle Internet Directory As A Hub

Recall that it's possible to integrate your E-Business Suite environment with a third-party LDAP directory using Oracle Internet Directory and its Directory Integration Platform as an intermediary, like this:

Third-Party LDAP Integration 2:

Oracle Internet Directory is a mandatory component in this chain.  Oracle doesn't currently offer any methods of directly integrating a third-party LDAP with the E-Business Suite.

Third-Party LDAP As The Master "Source of Truth"

In the typical configuration, the third-party LDAP directory is the master "source of truth" for the user's credentials.  For example, a change to the user's name would first be made in the third-party LDAP.  The updated user's information would then be sent to Oracle Internet Directory via the Directory Integration Platform.  Once in Oracle Internet Directory, the updated user's information would then be sent to the E-Business Suite via the Directory Integration Platform.

Extending the Chain of Trust

Remember that the E-Business Suite can delegate user authentication to Oracle Single Sign-On, effectively creating a chain of trust between the two components.  When the E-Business Suite is integrated with a third-party single sign-on solution, that chain of trust is extended one level further, like this:

Third-Party SSO Integration:
When the user logs on to the third-party single sign-on solution, she gets a set of security tokens that are recognized and trusted by Oracle Single Sign-On.  Oracle Single Sign-On doesn't challenge the user again for her credentials.

In turn, Oracle Single Sign-On issues its own set of security tokens, which are recognized and trusted by the E-Business Suite.  The E-Business Suite doesn't challenge the user again for her credentials.

What About Passwords?

Now that we've got the basics out of the way, understanding how passwords are handled in this scenario should be a bit easier.  In the scenario above, the user is challenged only once for their userid and password.  The third-party single sign-on solution handles that challenge and authenticates the user's credentials against the third-party LDAP.

It stands to reason that if the user is already logged in by the third-party single sign-on solution, and Oracle components never ask for the user's userid and password, there's no reason to keep the user's password anywhere in the Oracle namespaces.

Passwords Stored In Third-Party LDAP:

And, that's true:  when integrated as shown above, users' passwords are not stored locally in either Oracle Internet Directory or the E-Business Suite.  Passwords are stored only in the third-party LDAP directory.

Delegating User Management

Since the third-party LDAP repository is the master source of truth, it handles all user password resets.  Neither Oracle Internet Directory nor the E-Business Suite are interested in -- or even participate in the process -- of password management in this scenario.  It's all delegated to the third-party LDAP.

For Advanced Readers Only

By this point, I've weeded out readers with short attention spans.  For the handful of you who've toughed it out to this point, I should note that the above scenario is only one of many possible starting points.  Other advanced scenarios are technically feasible, including those in which user credentials flow bidirectionally between Oracle Internet Directory and the third-party LDAP. 

These can get pretty involved, so I'll have to leave these as an exercise for you to work out, for now.  More information can be found in our Implementation Guide, which describes more variants on the basic scenario outlined here. 

If you have a burning need to discuss those with someone, drop me a line.  I'll connect you to specialists in our Protected Enterprise Consulting group for more guidance.

Related

Note:  Everything in this article applies equally to both Release 11i and 12 environments.


Wednesday Aug 02, 2006

Password Management with Oracle Internet Directory

User password resets - the bane of every sysadmin.  Automating this tedium is a major benefit of integrating your E-Business Suite environment with Oracle Application Server 10g.  By delegating user authentication to Single Sign-On 10g and Oracle Internet Directory 10g, you can take advantage of the latter's automatic password reset capabilities.


But First, Some Basics About Account Management

In a standard E-Business Suite environment, user passwords are stored and encrypted in the user's records in the E-Business Suite's FND_USER directory.  

When an E-Business Suite environment is integrated with Single Sign-On and Oracle Internet Directory, Apps user accounts are linked to Oracle Internet Directory user accounts like this:

Link Apps Account to OID 2:

Where Does The User Log In?

When a user's E-Business Suite account is linked to an account in Oracle Internet Directory,  sysadmins have the option of specifying how the user can log into the E-Business Suite.  This can be specified for each individual user.

Available options are:
  • Users can log in externally via Single Sign-On
  • Users can bypass Single Sign-On and log in locally to the E-Business Suite
  • Users can log in via both of the methods above
E-Business Suite Doesn't Need To Store A Password

In the external scenario, all user authentication is handled by Single Sign-On and Oracle
Internet Directory.  For so-called external users, passwords are stored exclusively in Oracle Internet Directory.  Single Sign-On displays a login screen and collects the user's userid and password, and Oracle Internet Directory checks that those credentials match the user's entry within the Oracle Internet Directory LDAP user directory.

After users successfully log into Single Sign-On, they receive security tokens that the E-Business Suite recognizes and uses to establish their E-Business Suite session, based on a chain of trust that looks like this:

SSO OID Apps Trust:

The E-Business Suite uses those Single Sign-On security tokens in place of checking for a password.  So, it doesn't need to store user passwords for external users at all. 

No More Manual Password Changes

So, in a refreshing switch for veteran Apps sysadmins, all external users can reset their own passwords using Oracle Internet Directory's Delegated Administration Service.  This represents the end of the era of manual password resets for Apps users.

Logging Into The E-Business Suite Directly

There are specific users that must always be able to log into the E-Business Suite directly.  These users include Apps DBAs or system administrators, who still need to be able to get into Apps even if the external Single Sign-On and Oracle Internet Directory instances are unavailable due to maintenance windows.

These are considered to be local users, so their passwords are always stored in the E-Business Suite's FND_USER directory, not Oracle Internet Directory.  Passwords for these users still need to be maintained manually using the regular E-Business Suite security forms that you know and love.

A Tricky Case:  "Both"

There might be a subset of users who need to be able to access the E-Business Suite via Single Sign-On as well as locally.  These users would be given access to both login methods, which means that passwords must be stored in both locations:  Oracle Internet Directory and the E-Business Suite's FND_USER directory. 

The password management overhead is higher for these users, so you'll want to use this option very sparingly:
  • Password changes made in the E-Business Suite are automatically sent to Oracle Internet Directory
  • Password changes made in Oracle Internet Directory must be manually repeated in the E-Business Suite using the E-Business Suite security forms
The asymmetry in the tasks above is because of this:  we can decrypt passwords stored in the E-Business Suite, which allows us to send them to Oracle Internet Directory.  Passwords in Oracle Internet Directory, however, are hashed, which prevents us from transmitting a copy to the E-Business Suite.

Password Management With Third-Party Integrations

That's enough for today, but look out for a future article discussing password management when you integrate the E-Business Suite with a third-party LDAP directory or single sign-on solution.  Stay tuned.

Related

Note:  Everything in this article applies equally to both Release 11i and 12 environments.

Monday Jul 31, 2006

Identity Management in Release 12

If you've been keeping up with our E-Business Suite Release 12 sneak previews, you know that this release will include Oracle Application Server 10g for the application tier.  Here are a few more details about identity management for this release.

Apps R12 Identity Management:

FND_USER Still The Default

Like Release 11i, Release 12 will use the local E-Business Suite user directory, FND_USER, for user authentication by default.  You may optionally integrate R12 with an external Oracle Application Server 10g instance and delegate user authentication to Single Sign-On 10g and Oracle Internet Directory 10g running externally. 

Integration with Third-Party LDAPs and Single Sign-On Solutions

It's possible to integrate R12 with a third-party LDAP (e.g. Microsoft Active Directory, SunONE/iPlanet) or single sign-on solution (e.g. Microsoft Windows Kerberos, Netegrity SiteMinder).  If you want to do this, you'll need to integrate those third-party solutions via an external Oracle Application Server 10g instance, as shown in the diagram above.

That creates a chain of trust:  R12 delegates user authentication to Oracle Single Sign-On; Oracle Single Sign-On delegates authentication to the third-party single sign-on solution.

Likewise, user information from the third-party LDAP must be synchronized with Oracle Internet Directory 10g, which synchronizes its users with the E-Business Suite's FND_USER directory.  Synchronization is handled by the Oracle Directory Integration Platform.

New Local Login Page

The Release 12 local login page will feature the new Swan look-and-feel, offer multiple languages, and support customizations.

SSO Integration With Portal & Discoverer

As in Release 11i, the R12 Single Sign-On integration allows logged-in E-Business Suite users to access Portal and Discoverer content without having to log in again.

Switch to mod_osso


Under the covers, the R12 Single Sign-On integration switches from the older SSO SDK used in 11i to the latest mod_osso technology available in Oracle Application Server 10g.

From an end-user's perspective, nothing has changed; they're still authenticated by Single Sign-On 10g.  From a security perspective, mod_osso centralizes partner application session management and allows for simpler debugging and administration.

The above is intended to outline our general product direction.  It is intended for information purposes only, and may not be incorporated into any contract.   It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decision.  The development, release, and timing of any features or functionality described for Oracle's products remains at the sole discretion of Oracle. 


Thursday Jul 27, 2006

Login Server and Portal 3.0.9 Desupport... Again

[Aug 3, 2007 Update:  That's it, folks.  Portal 3.0.9 and Login Server 3.0.9 are now officially out of Premier Support.  For a final discussion about this, see this article.]

Three months ago (an eternity in blog years), I noted that Login Server & Portal 3.0.9 will likely be effectively desupported this fall.  To recap:  this will be an unfortunate side-effect of Sun's upcoming release of Java 6 (a.k.a. 1.6), which triggers the desupport of Java 1.3.  Login Server & Portal 3.0.9 are only certified with Java 1.3, so this trumps Oracle's own planned desupport of Login Server & Portal 3.0.9 in July 2007.

Portal Upgrade Paths:

No Last Minute Reprieves

In that original article, I alluded to a slim chance of extending our support window for these elderly products.  Unfortunately, this has turned out to be technically infeasible.

After Sun's desupport of Java 1.3, E-Business Suite customers reporting problems with Login Server & Portal 3.0.9 will be advised to upgrade to the latest certified Portal 10g release.

Bite The Bullet

As you can see from the Portal Upgrade Path flowchart above, getting from Login Server & Portal 3.0.9 to the latest certified release may not be a walk in the park.

If you're running these products in production today, I strongly urge you to begin your upgrade planning to Oracle Application Server 10g, Portal 10g, and Single Sign-On 10g immediately

Related

Tuesday Jul 11, 2006

Benchmarking Oracle Internet Directory 10gR2 Performance

Customers have been comfortably using the E-Business Suite behind corporate firewalls for years now without any worries.  Increasingly, however, Applications environments are being exposed to supplies, partners, and customers outside of a corporate firewall like this:
Apps Multiple Web Entry Points:


Amongst other potential concerns, this has the potential to increase the number of registered and concurrent Apps users by several orders of magnitude.  System architects need to ensure that their Release 11i environments can scale up to handle the increased workload. 

If you're considering integrating Oracle Application Server 10g with your E-Business Suite environment to support Single Sign-On, then another one of your goals is to ensure that your Identity Management infrastructure can scale up, too.

To help you answer that question, our OID product management group has recently released a whitepaper that shows benchmarking data for Oracle Internet Directory 10g Release 2 (10.1.2.0.2):
This whitepaper has SLAMD Distributed Load Generation Engine benchmarks for an OID LDAP directory with 150 million users on a six-node Directory Replication ring consisting of two multi-master nodes and four fan-out replica nodes.  If that's gibberish to you, don't worry -- the paper describes what each of these High Availability concepts mean.

OID Benchmarking Architecture:

Pretty impressive testing setup:  they used six 32-CPU Itanium2-based servers running on Linux Suse 9, with a combined total of 2,160 GB of storage across all nodes. 

This paper's an interesting read, both from a high-availability architectural planning perspective, as well as for the actual benchmarking data itself.

Related

Wednesday May 10, 2006

In-Depth: Cloning OracleAS 10g + E-Business Suite Environments

As much as I'd prefer to avoid the subject, it's time to turn to address a subject of much ongoing controversy, namely cloning.  Cloning an E-Business Suite environment is easy. Cloning an E-Business Suite environment that's been integrated with Oracle Application Server 10g is not quite as easy, unfortunately.

What's Cloning?

Cloning is the process of creating an identical copy of an already existing Oracle Applications system, including both the application-tier and database-tier.

Why Clone?

Reasons for cloning E-Business Suite environments include:
  • Creating a copy of the production system for testing updates
  • Migrating an existing system to new hardware
  • Creating a stage area to reduce patching downtime
One of our more risk-averse customers informed me that they may create up to 15 clones of an E-Business Suite environment between the TEST and PRODUCTION rollout phases.

The Easy Part

The E-Business Suite Release 11i was architected to support cloning.  Experienced Apps DBAs know that the easiest way to create clones of their environments is to use the Rapid Clone utility introduced in 11.5.8.  Creating a n E-Business Suite clone is as simple as copying your application-tier and database-tier files to the new target system and then running the perl-based Rapid Clone (adcfgclone.pl) utility. 

The Not-So Easy Part

Oracle Application Server 10g was designed with different goals in mind.  Consequently, there are no Oracle tools available today to clone an entire OracleAS 10g environment in a single step.  In other words, OracleAS 10g does not have the equivalent of a Rapid Clone utility.

In the absence of a single turnkey tool like Rapid Clone, creating clones of new OracleAS 10g environments is a more involved process.  Not impossible, mind you -- but definitely more involved.

Things get even more complicated when an E-Business Suite environment is integrated with Oracle Application Server 10g

Nothing But Net

There are neither tools nor formal documents available from my group -- the Applications Technology Group -- or from Application Server Development, for cloning E-Business Suite environments that have been integrated with OracleAS 10g.

This hasn't exactly been a pleasant state of affairs, especially if you happen to be the person responsible for telling customers about the absence of this documentation and tools.  No matter -- I'm tough; I can take it.

But seriously, aside from this post, which will attempt to lay out general strategies for how you can fill in the gaps yourself through some old-fashioned elbow grease, there are no tools available to meet your comprehensive cloning requirements for combined OracleAS 10g + E-Business Suite environments today.  More on our future plans in a minute.

Warning:  Trail Ahead Requires Exploration

If you're willing to experiment a bit, the following are general guidelines to point you in the right direction.  Some customers and Oracle Consultants have used the following approaches to get the job done but have reported that there was some trial-and-error involved. 

These are neither detailed nor comprehensive instructions.  The following should be attempted only by system administrators who have a solid understanding of the principles outlined in Metalink Note 261914.1.

If you're going to experiment with these approaches, I strongly recommend that you take all sensible precautions, including backing up your environments at multiple stages, taking careful notes, and doing things in small, incremental steps to control your risk.

Cloning Scenarios

Assuming that you have an E-Business Suite environment that's been successfully integrated with OracleAS 10g, here are a few cloning scenarios that may apply to you:
  1. Create a clone of your Discoverer environment

  2. Create a clone of your Single Sign-On / Oracle Internet Directory environment
  3. Create a clone of your Portal environment 
Creating a Clone of Your Discoverer 10g Environment

If you've integrated Discoverer 10g with your E-Business Suite environment but have not chosen the Single Sign-On option, then the cloning process is relatively painless:
  1. Use Rapid Clone to create a clone of your E-Business Suite, including the application-tier and database-tier.  Remember that the E-Business Suite database already contains the Discoverer 10g End-User Layer.
  2. Create a fresh install of Discoverer 10g on your new server and point it to the End-User Layer in the cloned E-Business Suite instance.
Creating a Clone of Your Single Sign-On / Oracle Internet Directory Environment

If you've integrated Single Sign-On and Oracle Internet Directory 10g with your E-Business Suite environment, do the following:
  1. Use Rapid Clone to create a clone of your E-Business Suite, including the application-tier and database-tier.
  2. In your newly-cloned E-Business Suite instance, set the APPS_SSO_LDAP_SYNC profile option to "Disabled" at the site level (since there's no new Oracle Internet Directory instance to synchronize with yet).

  3. In your newly-cloned E-Business Suite instance, unlink all E-Business Suite users that were linked to the original Oracle Internet Directory 10g users (i.e. where FND_USER.USER_GUID is populated), since the those old links are no longer valid.  Those E-Business Suite users will need to be linked to their corresponding accounts in the as-yet non-existent new Oracle Internet Directory instance. 

  4. Create a fresh install of Single Sign-On and Oracle Internet Directory 10g on your new server.
  5. Assuming that you enabled bidirectional provisioning between the E-Business Suite and Oracle Internet Directory, do one of the following (but not all three):

    a) Redo your bulkload from the E-Business Suite into Oracle Internet Directory, reregister your E-Business Suite environment using the Bidirectional Provisioning Profile, and enable the APPS_SSO_AUTO_LINK_USER profile option, and set the profile option APPS_SSO_LDAP_SYNC back to Enabled at site level.

    b) Export your LDAP namespace from your original Oracle Internet Directory instance into an LDIF file, and then import the LDIF file into the new Oracle Internet Directory instance.  Reregister your E-Business Suite environment using the Bidirectional Provisioning Profile, and (assuming that the Oracle Internet Directory accounts are identical to the E-Business Suite accounts) enable the APPS_SSO_AUTO_LINK_USER profile option, and set the profile option APPS_SSO_LDAP_SYNC back to Enabled at site level.

    c) Connect the original Oracle Internet Directory instance to your new Oracle Internet Directory instance via a connector, synchronizing the namespaces.  Reregister your E-Business Suite environment using the Bidirectional Provisioning Profile, and (assuming that the Oracle Internet Directory accounts are identical to the E-Business Suite accounts) enable the APPS_SSO_AUTO_LINK_USER profile option, and set the profile option APPS_SSO_LDAP_SYNC back to Enabled at site level.
Creating a Clone of Your Portal Environment
  1. Portal requires a working Single Sign-On setup, so complete the previous section first.
  2. If you haven't already done so, create a fresh install of Portal 10g on your new server.

  3. Use the existing Portal 10g documentation to export your portal content and metadata from the original Portal instance.  Import that content into the new Portal 10g instance.
  4. Reregister the OAF Web Provider from your new E-Business Suite instance in your new Portal instance.
Other Alternatives To Exploring On Your Own

If you found the previous sections alarming and confusing, there are a few options:
  1. Hire an experienced consultant.  Check their references!  You don't want to pay someone for the privilege of training them -- including staff from Oracle Consulting.  There are some Oracle Consultants with experience in this area; email me if you'd like some contacts within Oracle.
  2. Wait for the formal documentation from the Applications Technology Group.  Be prepared to wait for a while, however.  A project proposal has been submitted for review but it has not been accepted or prioritized yet.  I'm continuing to press for the priority of this to be raised.  At present, there are no fixed schedules for this documentation yet.
Good luck... and remember to take frequent backups.

Wednesday May 03, 2006

In-Depth: Using Third-Party Identity Managers with the E-Business Suite Release 11i

Like most of our customers, you probably already have a corporate identity management system in place.  And, you've probably not been enjoying the experience of redundantly administering the same user in your corporate identity management system as well as the E-Business Suite. 


If this describes your environment, this post should come as good news to you. 

No More Redundant User Administration

With the certification of Oracle Application Server 10g and Single Sign-On 10g, it is now possible to integrate the E-Business Suite with existing third-party LDAP and single sign-on solutions, like this:

Simple Third-Party LDAP SSO Integration:

Third-party single sign-on solutions can be integrated with Oracle Single Sign-On 10g, and third-party LDAP directories can be integrated with Oracle Internet Directory 10g.  From there, it's a short hop to the E-Business Suite.

Example Scenario:  The Deluxe "Zero Sign-On" Approach

A user logs on their PC using their Windows userid and password.  Wanting to avoid real work, the user decides to file a long-overdue expense report for last year's OpenWorld conference.  He starts Internet Explorer, opens Favorites, and selects a bookmarked link for the E-Business Suite's Self-Service Expenses.

Self-Service Expenses starts up, and the user begins the process of assembling rationalizations to justify that $450 dinner at Jardiniere with their favorite Oracle blogger.

(This is a fictional example, of course; nobody takes bloggers out to dinner)

We sometimes call this "zero sign-on" because the user never actually logged on to any Oracle systems at all; their Windows Kerberos ticket gave them an all-access pass to the E-Business Suite automatically.

Magic?  What Really Happened?

Brace yourself: some of the following material might require a couple of passes to sink in.

The scenario above illustrates the following integrations:
  • Microsoft Active Directory with Oracle Internet Directory 10g
  • Microsoft Kerberos Authentication with Oracle Single Sign-On 10g
  • Oracle Application Server 10g with the E-Business Suite
MS AD + Kerberos Integration:

The user logged on to their PC, which authenticated them against Microsoft Active Directory.  As part of that logon process, Microsoft Kerberos Authentication issued a valid Kerberos ticket to the user.

When the user attempted to access Self-Service Expenses via his bookmarked link, he was redirected to Oracle Single Sign-On 10g.  Oracle Single Sign-On 10g recognized the Microsoft Kerberos ticket, issued its own Oracle security tokens to the user, and redirected the user back to the E-Business Suite.

The E-Business Suite recognized the Oracle Single Sign-On 10g security tokens and looked up the user's assigned Applications Responsibilities to ensure that he was authorized to access Self-Service Expenses.  That done, it issued its own E-Business Suite security tokens and then passed the user through to Self-Service Expenses without requiring any additional logons.

Integration with Microsoft Active Directory Only

Not everyone uses Microsoft Kerberos Authentication.  A simpler integration option omits Kerberos and includes only Microsoft Active Directory and Oracle Internet Directory, like this:

MS AD Only - No Kerberos:

In this simpler architecture, when the user attempts to access Self-Service Expenses via his bookmarked link, he's redirected to Oracle Single Sign-On OracleAS 10g. Single Sign-On displays a login screen and collects the user's ID and password.

Single Sign-On passes the user's supplied ID and password to Oracle Internet Directory for validation.  Oracle Internet Directory uses the Windows NT External Authentication plug-in (sometimes also called the Windows Native Authentication plug-in) to delegate user authentication to Microsoft Active Directory.

Microsoft Active Directory looks up the user's ID and password in its database, and informs Oracle Internet Directory that this is an authenticated user.  Oracle Internet Directory informs Single Sign-On that the user was successfully authenticated. 

Single Sign-On issues the user a set of security tokens and redirects the user to the E-Business Suite.  The E-Business Suite recognizes the Single Sign-On security tokens and looks up the user's assigned Applications Responsibilities to ensure that he's authorized to access Self-Service Expenses.  That done, it issues its own E-Business Suite security tokens and then passes the user through to Self-Service Expenses.

"Out-of-the-box" Third-Party LDAP Integration with Oracle Internet Directory

Due to the popularity of Microsoft Active Directory, Oracle Internet Directory provides a prebuilt connector out-of-the box, ready to use.

Oracle Internet Directory also provides a prebuilt connector for the SunONE (iPlanet) Directory Server, ready-to-use.  You should note that Sun (like Oracle, following its myriad recent acquisitions) has rebranded its identity management products, so there's a new name for the Sun LDAP directory now.  I'll update this post with the latest name as soon as my Sun contacts provide me with that information.

Synchronization of User Credentials with Third-Party LDAP Directories

If you've been paying close attention so far, you have likely gathered that user credentials need to be synchronized between the third-party LDAP, Oracle Internet Directory, and the E-Business Suite.  The synchronization architecture looks like this:

Third-Party LDAP User Sync:

In this configuration, only the user name needs to be synchronized; the user's password is stored in the third-party LDAP directory.  None of the Oracle products need to store the user's password, since they delegate user authentication to the third-party LDAP solutions.

The key concept here is that user authentication is still separated from user authorization even when a third-party LDAP is in place.  So, the E-Business Suite still grants authenticated users access to E-Business Suite protected content based on the users' Applications Responsibilities, which are managed in the E-Business Suite exclusively.

Integration With Other Single Sign-On Solutions

It is also possible to integrate Oracle Single Sign-On 10g with other single sign-on solutions, including:
When integrated with other single sign-on solutions, a chain of trust is established between the third-party, Oracle Single Sign-On, and the E-Business Suite.  Users logging on via the third-party single sign-on solution are passed through transparently to Oracle Single Sign-On and the E-Business Suite.

Bringing It All Together

Assuming I haven't lost you so far, the following diagram shouldn't be too overwhelming:

Combined 3rd Party LDAP SSO:

This combines all of the concepts we've covered:
  • Third-party LDAP integration with Oracle Internet Directory
  • Third-party SSO integration with Oracle Single Sign-On
  • Synchronization of user credentials via the Oracle Internet Directory's Oracle Directory & Provisioning Platform to the E-Business Suite
Relax, It's Easy and Fun

Well, maybe not... but at least it's technically feasible.  You might find it reassuring to note that a number of E-Business Suite customers are running this configuration in production already. 

This is about as much detail as I think is appropriate for now.  Feel free to post comments if you have questions about this topic. 

There are many more options for integration with the E-Business Suite, including options for linking OID userids to different E-Business Suite userids, and so on.  If you're really interested, I'd recommend a careful reading of this document:
Related Articles:

Tuesday May 02, 2006

In-Depth: Using Single Sign-On 10g with E-Business Suite Release 11i

Editor Jan. 12, 2007 Update:  Oracle Identity Management 10g 10.1.4.0.1 is now certified with the E-Business Suite. 

In the two-year Early Adopter Program we ran for OracleAS 10g + E-Business Suite configurations, over 200 customers elected to enable Single Sign-On 10g in their environments.

If that's representative of the general E-Business Suite customer, this suggests that approximately 75% of E-Business Suite customers will wish to use OracleAS 10g for this reason alone. 

Technical Benefits

This is a technically-focussed blog and I've promised not to bore you with vacous marketing rhetoric.  If you want to get the full pitch on why Oracle Identity Management should be your choice of solutions, you can find many compelling arguments here.

For E-Business Suite customers, the key benefits are:
  • The ability to offer a comprehensive Single Sign-On solution that works with all Oracle products, including the E-Business Suite, PeopleSoft, and JD Edwards.

  • The ability to use Oracle Internet Directory for managing E-Business Suite user credentials, shifting focus from the older FND_USER directory

  • The ability to integrate the E-Business Suite with your existing third-party
    single sign-on and LDAP infrastructure
Comprehensive Single Sign-On Solution

If you have one or more E-Business Suite Release 11i instances and are tired of maintaining users separately for each environment, you can create a central OracleAS 10g environment and manage all 11i users in one place.

If you have a combination of PeopleSoft, JD Edwards, and the E-Business Suite in your organization, you can use OracleAS 10g to manage users for all three environments centrally.

If you have a combination of the E-Business Suite and custom applications based on Oracle databases or OracleAS 10g technology, you can use OracleAS 10g to manage users for all applications in a single place.

Use Oracle Internet Directory Instead of FND_USER

The E-Business Suite's user management capabilities (based on the FND_USER directory) are perfectly adequate for administering E-Business Suite users.  However, security administrators wishing for additional user management and provisioning features would benefit from switching to Oracle Internet Directory.

Integrate with Third-Party LDAP and Single Sign-On Products

If you have an existing corporate security system such as Microsoft Active Directory, Windows Kerberos, Sun ONE/iPlanet, or Netegrity SiteMinder, using OracleAS 10g allows you to integrate your E-Business Suite with that infrastructure.  This is a topic for a future In-Depth posting; watch this space.

How Single Sign-On 10g Works With the E-Business Suite

When the E-Business Suite is integrated with OracleAS 10g and Single Sign-On 10g, the user authentication process is handled by Single Sign-On 10g. 

Simple SSO 10g + Release 11i flow:

Users attempting to access protected E-Business Suite content are redirected to Single Sign-On 10g for authentication.  Users log in via Single Sign-On 10g, and then are redirected back to the E-Business Suite and the protected content they wished to access.

Authentication versus Authorization

It's important to distinguish user authentication from user authorization:
  • User authentication is the process of establishing whether the user is whom they claim to be.
  • User authorization is the process of determining what resources an authenticated user is permitted to access.
With our current integration for the E-Business Suite Release 11i, these two processes are handled by Single Sign-On and the E-Business Suite, respectively:
  • When the E-Business Suite is integrated with Single Sign-On 10g, it delegates user authentication to Single Sign-On. 
  • After Single Sign-On has successfully authenticated a user, the E-Business Suite handles the authorization process:  e.g. ensuring that the user is entitled to file expenses.
Partner Applications, Single Sign-On, and Single Sign-Off

The E-Business Suite is a Single Sign-On partner application.  Once a user logs on successfully to Single Sign-On 10g, the user has access to all registered partner applications without having to log on again.

Likewise, if a user logs out of any one of those partner applications, the user is logged out of all of them.  This is called Single Sign-Off, and works with the E-Business Suite, too.

Under the Covers:  The Chain of Trust


The key architectural concept to understand is that there is a chain of trust established between the E-Business Suite, Single Sign-On 10g, and Oracle Internet Directory 10g:

Simple SSO 10g Chain of Trust:

The E-Business Suite delegates user authentication to Single Sign-On, and Single Sign-On delegates user credential validation to Oracle Internet Directory.

The Log In Process, Deconstructed

Let's walk through this with an example:

Our example user isn't logged into the E-Business Suite.  She attempts to access a bookmarked link in her browser that points to the E-Business Suite's Self-Service Expenses page.

The E-Business Suite checks the user's browser for a valid 11i cookie, but doesn't find one:  not surprising -- she hasn't logged in yet. 

The E-Business Suite redirects the user to Single Sign-On 10g.  Single Sign-On 10g displays a login screen and collects the user's userid and password.  It then passes those credentials to Oracle Internet Directory for validation. 

Oracle Internet Directory looks up the user's credentials in the Oracle Internet Directory LDAP directory in the OracleAS 10g Infrastructure, providing an approval or rejection as appropriate to Single Sign-On.

If approved, Single Sign-On 10g issues a set of security tokens to the user and redirects her back to the E-Business Suite.   If rejected, the user is given another chance to log in with valid credentials.

Once redirected back to the E-Business Suite, the E-Business Suite recognizes the Single Sign-On security tokens and looks up the user's assigned Applications Responsibilities in the E-Business Suite FND_USER table. 

Having established that our example user is authorized to access Self-Service Expenses, the E-Business Suite issues its own security tokens and creates a new ICX user session.  The user now has two sets of security tokens in her browser, one from Single Sign-On 10g, and another from the E-Business Suite. 

At this point, the user is officially logged in, and is redirected to Self-Service Expenses.

Synchronizing User Credentials Between Oracle Internet Directory and the E-Business Suite

If user authentication and user authorization are performed by two different parts of this integrated system for the same user, the alert reader will leap ahead and guess that user credentials need to synchronized.

That guess would be correct:  user credentials in Oracle Internet Directory and the E-Business Suite's FND_USER directory need to be synchronized.  A user must be recognized and have valid entries in both locations to gain access to protected content.

DIP synchronization OID + Release 11i:

This synchronization is handled by an Oracle Internet Directory tool called the Directory Integration & Provisioning Platform. 

It's up to you to designate the master "source of truth" for user credentials; this is fully configurable.  For example, you can designate the E-Business Suite as the master and Oracle Internet Directory as the slave, or vice versa.  You can even elect to manage user credentials in both locations and have changes updated automatically between the two of them. 

In other words, changes to user credentials can flow:
  • From the E-Business Suite to Oracle Internet Directory
  • From Oracle Internet Directory to the E-Business Suite
  • Bidirectionally between them.
At this point, you're probably as exhausted as I am, so I'll cover third-party LDAP and Single Sign-On integration tomorrow.

Related Articles:

Monday May 01, 2006

In-Depth: Using OracleAS 10g with E-Business Suite Release 11

Editor Jan. 12, 2007 Update:  Oracle Identity Management 10g 10.1.4.0.1 is now certified with the E-Business Suite. 

As promised earlier, this post represents the first of a series of in-depth discussions on using OracleAS 10g with the E-Business Suite Release 11.


It is now possible to integrate the E-Business Suite Release 11i with OracleAS 10g, for the use of Single Sign-On, Oracle Internet Directory, Portal, Discoverer, Web Cache and Oracle Integration.

Integrated, Not Upgraded

The key concept is that Release 11i may be integrated with OracleAS 10g.  The existing E-Business Suite application server, Oracle9i Application Server 1.0.2.2.2, is not upgraded to OracleAS 10g; the two instances are integrated together in a loosely-coupled architecture like this:

Simple OracleAS 10g + E-Business Suite Architecture:

Remember that if you want to upgrade your existing E-Business Suite 9iAS application server to OracleAS 10g, you'll be able to do that in Release 12.  For Release 11i, it's always going to be an integration-based architecture.

One Server or Two?

The diagram above shows the existing E-Business Suite 9iAS services and the new external OracleAS 10g services running on two different physical servers.  That's our recommended configuration, particularly if you're planning to upgrade from Discoverer 4i to 10g (due to the former's obsolescence in Oct 2006).

It's possible to install OracleAS 10g on the same physical server where 9iAS is installed... if you have sufficient resources available on that box.  You must install OracleAS 10g in a separate ORACLE_HOME.  OracleAS 10g cannot be installed into the existing E-Business Suite 9iAS ORACLE_HOME.

What Are The Main OracleAS 10g Components?

This is something new to E-Business Suite sysadmins, so you may have to review this a few times to let it sink in.

Architecturally, you should think of OracleAS 10g as being comprised of middle-tier (application tier) products and infrastructure services.  Middle-tier products include Portal, Discoverer, and Oracle Integration.

The OracleAS 10g Infrastructure includes Single Sign-On, Oracle Internet Directory, and the actual LDAP database where user credentials are stored.  In general, all of the OracleAS 10g middle-tier products share the same OracleAS 10g Infrastructure.

Middle-tier products like Portal have content such as portal page definitions, pictures, downloadable files, and so on.  This content has metadata, too, which determines how content is displayed and accessed.  All of this product-specific content and metadata is stored in a database called the OracleAS 10g Metadata Repository.

Installing OracleAS 10g (Over and Over)

As you'd expect, there are several variants of how these components can be installed.  These variants are documented in excruciating detail in the OracleAS 10g Installation Guide for your operating system platform.  Arm yourself with coffee before reading the Installation Guide - it can be heavy going for a first-time reader.

In general, the first component to be installed is the OracleAS 10g Infrastructure.  If you're starting out simply (which I'd recommend), you can install the OracleAS 10g Metadata Repository at the same time, like this:

Simple OracleAS 10g Infrastructure:

Advanced sysadmins have the option of installing the Infrastructure and Metadata Repository in different places and on different servers, like this:

Split OracleAS 10g Infra + MR:

If all you're interested in using is Single Sign-On and Oracle Internet Directory with the E-Business Suite, you're done on that front (for now). 

If you're interested in using Portal or other middle-tier components like Oracle Integration, you need to run the Oracle Unversal Installer and install those components separately.  As part of their installation, you'll need to point those components to the OracleAS 10g Infrastructure and OracleAS 10g Metadata Repository that you created earlier.

OracleAS 10g Runs Independently

Now that your OracleAS 10g environment is installed, you should test it to ensure that it runs without any issues.  You should be able to log in to this environment, create and modify users, start up Portal, create custom portal home pages, and so on. 

Connecting OracleAS 10g to the E-Business Suite

Once your OracleAS 10g instance is proven to be working, you will proceed with connecting it to your E-Business Suite environment.  Doing so will enable your E-Business Suite to use Single Sign-On, Portal, and Discoverer services running on the OracleAS 10g instance. 

I'll cover each of those options in subsequent "In-Depth" postings later this week.

Related Articles:

About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today