Request a trial
Menu
Products
Solutions
ERP
Authentication
Apps
LearnDocsWhy SSOGENRequest a trial

SSOGEN / Learn / Replace Oracle Access Manager for EBS: A Cut-Over Plan You Can Roll Back

Learn

Replace Oracle Access Manager for EBS: A Cut-Over Plan You Can Roll Back

To replace Oracle Access Manager, EBS teams inventory every link to OAM, rehearse on a clone, run the old and the replacement side by side, cut over one instance or application at a time, and write the rollback step before each stage starts.

Updated

Request More Info

The short answer. Replace Oracle Access Manager (OAM) for Oracle E-Business Suite (EBS) in stages: rehearse the switch and the way back on a clone, then move production in one planned window while OAM stays installed.

Why now. Premier Support for Oracle Access Management 12.2.x ends in December 2026 and Extended Support in December 2027; the OAM 12c end-of-support dates and options cover the choice between upgrading and leaving. EBS 12.2 has Premier Support through at least 2037, so the application outlives its sign-in layer.

Why you move a whole EBS instance at a time

You cut over one EBS instance at a time, because the sign-in link is stored on every user of that instance.

  • Accounts are linked by GUID. Oracle describes how EBS links each application account to the single sign-on account through a globally unique identifier (GUID) that the directory generates.
  • Removing OAM applies to the whole instance. Taking out the old registration removes it for the whole instance. Clearing the stored GUID values is a separate step, after which each person is linked again at the next sign-in.

The consequence: you do not move half the users of one instance and leave half on OAM. You move whole instances (development, test, production) and whole external tiers, and other OAM-protected applications one at a time.

Inventory everything that touches OAM

List every connection to OAM before anyone changes a file:

  • EBS instances and web nodes. Every environment, every Oracle HTTP Server node, load balancers, and any external tier in a DMZ for iSupplier.
  • EBS AccessGate. Where it is deployed and at which patch level.
  • WebGate. The OAM WebGate configuration on each web node, and the paths it protects.
  • Directory links. Oracle Internet Directory (OID) or Oracle Unified Directory (OUD) registrations, provisioning between the directory and EBS, and the stored GUID values.
  • Custom login and logout pages. Branded OAM login pages, the EBS logout target, and bookmarked links.
  • Sign-in profile options. Their current values at site and user level.
  • Local accounts. SYSADMIN and other accounts that must keep a local way in.
  • Timeouts. The EBS application session timeout and the OAM session timeout.
  • Other applications behind OAM. Each one, its web server and the user attribute it reads.

Run the old and the replacement side by side

Side by side means OAM keeps serving production while the replacement runs on a clone of production.

  1. Clone production with the same patch level and node layout.
  2. Switch the clone to the replacement, while production stays on OAM.
  3. Sign in to both with the same pilot users, and compare what each user sees.
  4. Keep OAM installed and running after production moves, until the hold period ends.

Compare the decisions each system makes

Shadow mode is a general software technique: send the same input to the old and the replacement, use only the old result, and log every disagreement. GitHub described it for code paths, calling the old path the control and the new one the candidate.

For sign-in, the input is a user and an application, and the decision is allow or deny:

  1. Export who OAM allows for each protected application, from its policies and the directory groups they name.
  2. Export who the replacement allows, from its group assignments and sign-in rules.
  3. Diff the two lists per application. Every user in one list and not the other is a finding.
  4. Explain or fix each finding before the stage that moves that application.

Move one instance or one application at a time

Order the stages so each one teaches you something before production depends on it:

  1. Rehearsal clone. Switch, test, then switch back. Time both directions.
  2. Test instance with a pilot group. Users from finance, purchasing and IT run their daily tasks for an agreed period.
  3. Other OAM-protected applications, one at a time, fewest users first.
  4. Production EBS in one maintenance window, with the rollback rehearsed and timed.
  5. External tier for iSupplier, after the internal tier is stable.
  6. Retire OAM when the hold period ends with no rollback.

A rollback step for every stage

Write the rollback before each stage starts, and name the person who decides to use it.

Stage Rollback step Point of no return
Rehearsal clone Remove the replacement, restore saved files, re-register OAM None
Pilot instance As the clone, then link the pilot users again None
Other applications Restore the old web-server configuration None while OAM runs
Production EBS Remove the replacement, restore saved files and GUID values, re-register OAM None during the hold
External tier Remove the replacement from that node None
Retire OAM Rebuild OAM from its archived configuration Yes: plan it as final

How to test login, logout, session timeout and responsibilities

Run the same tests on the clone, the test instance and production, with the same users each time. The sign-in address is https://ebs.acme.example/OA_HTML/AppsLogin; the local login page is https://ebs.acme.example/OA_HTML/AppsLocalLogin.jsp.

Test How Pass when
Login Maria Lopez opens the sign-in address She lands in EBS as her own user
Responsibilities Compare her responsibility list before and after The lists match
Local login SYSADMIN opens the local login page The EBS password works
Logout James Carter logs out; Maria opens EBS in the same browser Maria is asked to sign in
Session timeout Compare the EBS and sign-in session timeouts EBS timeout is equal or shorter
Every node Repeat login on each web node Each node passes

Responsibilities need no migration. Oracle states that after authentication EBS reads authorization from the responsibilities of the application account, so a changed list points to a user-linking problem.

Cut-over checklist by phase

The cut-over runs in eight phases, and each one ends with a check that must pass before the next starts.

Phase Tasks Exit check
1. Inventory Everything in the inventory list Owner named per item
2. Connect people Link the directory or identity provider; test it A pilot user signs in
3. Re-create rules Turn OAM policies into groups and rules; diff No unexplained differences
4. Rehearse Switch the clone, test, roll back, time it Rollback fits the window
5. Pilot Test instance with a pilot group Business owners sign off
6. Production One window, rollback owner present All tests pass on every node
7. Hold OAM stays installed; watch errors and calls Hold ends with no rollback
8. Retire Archive OAM settings; remove OAM, WebGate, old links Inventory closed

Where SSOGEN fits in this plan

SSOGEN signs people in to EBS 12.2 without OAM or OID. A package run on each EBS web node deploys Oracle’s own AccessGate (./ssogen deployag), installs the SSOGEN Web Agent in Oracle HTTP Server and sets the EBS sign-in profile options (./ssogen reg). It connects through SSOGEN or straight to a SAML or OpenID Connect provider.

The package maps onto each stage:

  • Clearing OAM. ./ssogen cleanup removes the earlier registration and clears the user links, after saving the old values to a file.
  • Dry runs. --check shows what any step would change without changing it.
  • Rollback. Each edited file is first copied to <file>.preSSOGEN.<timestamp>, and ./ssogen dereg removes the SSOGEN block and restores the EBS settings.
  • Local login. SYSADMIN keeps the local login page.
  • Logout and nodes. Logout in EBS ends the Web Agent session; reg runs on every node, and dmzreg covers an external tier.

The Oracle EBS SSO guide has every step, and the integration packages reference lists each back-out command.

Questions people ask

Can Oracle EBS 12.2 use single sign-on without Oracle Access Manager?

Yes. SSOGEN signs people in to EBS 12.2 without OAM or OID. Its package deploys Oracle’s own AccessGate, installs the SSOGEN Web Agent in Oracle HTTP Server and sets the EBS profile options. People then sign in against your directory or the identity provider you already run, and land in EBS as their own user.

Can OAM and the replacement run on the same EBS instance at once?

No. Each EBS user is linked to one single sign-on account, and removing the old registration applies to the whole instance. Run them side by side on separate instances instead: OAM keeps production while the replacement runs on a clone, and production moves only after the clone and a pilot group pass every test.

How do you roll back an EBS single sign-on cut-over?

Remove the replacement from the web tier, restore the saved web-server files and user links, and register OAM again by Oracle’s procedure. Rehearse it on a clone and time it, so you know it fits the maintenance window. Keep OAM installed and running until the agreed hold period after production moves has ended.

Does replacing Oracle Access Manager change EBS responsibilities?

No. Oracle states that EBS reads authorization from the responsibilities of the application account after the user is authenticated. The replacement only proves who the person is. Test it anyway: compare each pilot user’s responsibility list before and after the switch, and treat any difference as a user-linking problem.

Where to go next

Sources, all read 2026-11-13:

Oracle, E-Business Suite and Oracle Access Manager are trademarks of Oracle and its affiliates. SSOGEN is an Oracle partner, but Oracle has not reviewed or endorsed this page. SSOGEN names Oracle products only to say which systems this page is about.