AgeSA: Single Sign-On und Oracle EBS-Integration für 3.000 Mitarbeiter

Oracle E-Business Suite bleibt das Rückgrat der Finanz- und HR-Operationen für Tausende Unternehmen weltweit. Doch ihr Authentifizierungsmodell stammt aus der Zeit vor modernen Föderationsstandards — sie unterstützt nativ weder SAML 2.0, OAuth 2.0 noch OpenID Connect. Die Integration von SSO in Oracle EBS ist daher kein einfacher Schalter, sondern eine architektonische Herausforderung, die das Brückenbauen zwischen Legacy-Authentifizierung und modernen Identity-Providern erfordert.

Dieser Leitfaden präsentiert eine bewährte Architektur zur SSO-Integration mit Oracle EBS unter Verwendung von Azure AD (Entra ID) als Identity Provider. Die Muster stammen aus Enterprise-SSO-Integrationen in regulierten Branchen einschließlich Versicherung, Banken und Fertigung.

Warum Oracle EBS SSO schwierig ist

Oracle EBS wurde in einer Ära entworfen, in der jede Anwendung ihre eigenen Benutzeranmeldedaten verwaltete. Die Herausforderungen sind spezifisch und gut dokumentiert:

• Keine native Föderationsunterstützung: EBS spricht weder SAML noch OAuth. Man kann es nicht einfach auf einen Identity Provider zeigen und SSO aktivieren
• Enge Kopplung an Oracle Internet Directory (OID): Die EBS-Benutzerbereitstellung stützt sich auf OID für die Zuordnung von Benutzern zu Verantwortlichkeiten und fügt eine zwischengeschaltete Verzeichnisschicht hinzu, die synchronisiert werden muss
• Angepasste Authentifizierungs-Hooks: Viele EBS-Deployments haben über 10–15 Jahre angepasste Login-Seiten, Passwortrichtlinien und Session-Management-Code angesammelt. Die SSO-Integration muss mit — nicht gegen — diese Anpassungen arbeiten
• Multi-Populations-Komplexität: Enterprise-EBS-Umgebungen bedienen diverse Benutzertypen — interne Mitarbeiter, externe Agenten, Auftragnehmer — die jeweils unterschiedliche Authentifizierungsrichtlinien erfordern

Architekturoptionen

Es gibt drei primäre Ansätze zur SSO-Integration mit Oracle EBS. Jeder hat Vor- und Nachteile:

Option 1: Oracle Access Manager (OAM) + Azure AD via WS-Federation

Dies ist der robusteste Ansatz für Produktionsumgebungen. OAM agiert als Oracle-seitiger SSO-Agent und delegiert die Authentifizierung an Azure AD (Entra ID) via WS-Federation oder SAML. OID pflegt die EBS-spezifische Benutzerbereitstellungsschicht. Dieser Ansatz bewahrt die interne Benutzer-zu-Verantwortlichkeiten-Zuordnung von EBS, während die Authentifizierung externalisiert wird.

Option 2: Benutzerdefiniertes SAML-Gateway

Ein leichtgewichtiger Reverse-Proxy oder benutzerdefiniertes Gateway fängt EBS-Login-Anfragen ab und leitet an einen SAML-Identity-Provider weiter. Einfacher zu deployen als OAM, aber weniger resilient — Session-Management und Token-Refresh erfordern benutzerdefinierten Code, der zur Wartungslast wird.

Option 3: Oracle Identity Cloud Service (IDCS)

Oracles cloudbasierter Identity-Service kann EBS und moderne IdPs verbinden. Geeignet, wenn die Organisation bereits in Oracle Cloud investiert hat, fügt aber eine Abhängigkeit von Oracles Cloud-Infrastruktur hinzu und kann mit bestehenden Azure-AD- oder Okta-Investitionen kollidieren.

Für die meisten Unternehmen mit einem bestehenden Azure-AD-Deployment (Entra ID) bietet Option 1 — OAM mit Azure-AD-Föderation — die beste Balance aus Robustheit, Wartbarkeit und Kompatibilität mit EBS-Anpassungen.

Active-Directory-Integrationsmuster

Die empfohlene dreischichtige Architektur:

1. Identity-Provider-Schicht: Azure AD (Entra ID) als autoritativer Identity Provider, synchronisiert mit On-Premises-Active-Directory über Azure AD Connect. Passwort-Hash-Sync und Seamless SSO für ein reibungsloses Benutzererlebnis verwenden. Diese Schicht besitzt die Authentifizierung — sie ist die einzige Wahrheitsquelle für „Wer ist dieser Benutzer?"
2. Föderations-Bridge-Schicht: Oracle Access Manager (OAM), konfiguriert zur Authentifizierungsdelegation an Azure AD via WS-Federation. OAM validiert das Azure-AD-Token und erstellt eine EBS-kompatible Session. Oracle Internet Directory (OID) pflegt die Zuordnung zwischen Azure-AD-Identitäten und EBS-Benutzerkonten mit ihren zugehörigen Verantwortlichkeiten
3. Policy-Engine-Schicht: Azure-AD-Conditional-Access-Richtlinien erzwingen kontextbewusste Authentifizierung — MFA für EBS-Zugriff, Schadensbearbeitungstools und externe Portale; Single-Factor mit Device-Compliance für interne Workstation-Logins. Verschiedene Benutzergruppen erhalten unterschiedliche Richtlinien, ohne separate Authentifizierungsflows zu bauen

Session-Management über EBS-Module hinweg

Einer der trickreichsten Aspekte von EBS-SSO ist das Session-Management. EBS-Module (Financials, HR, Procurement) können als separate Apache/OC4J-Instanzen laufen, jede mit eigenem Session-Cookie. Zentrale Überlegungen:

• Session-Propagation: OAMs WebGate muss auf jedem EBS-Web-Tier deployed werden, um Anfragen abzufangen und die SSO-Session konsistent über Module hinweg zu validieren
• Timeout-Abstimmung: Azure-AD-Session-Lifetime, OAM-Session-Lifetime und EBS-Session-Lifetime müssen aufeinander abgestimmt sein. Nicht übereinstimmende Timeouts erzeugen Szenarien, in denen Benutzer bei Azure AD authentifiziert sind, aber Session-Expired-Fehler in EBS erhalten
• Single Logout: SLO (Single Logout) implementieren, sodass das Abmelden von einem System Sessions über alle Systeme hinweg beendet. Ohne SLO werden verwaiste Sessions zum Sicherheitsrisiko
• Formularbasierter Authentifizierungs-Fallback: Einen Fallback-Authentifizierungspfad für Break-Glass-Szenarien pflegen. Wenn der IdP nicht verfügbar ist, müssen Administratoren trotzdem auf EBS zugreifen können

Sicherheitsaspekte

Vor der SSO-Aktivierung ein vollständiges Benutzerkonto-Audit über alle verbundenen Systeme durchführen. Unternehmen entdecken typischerweise:

• Verwaiste Konten: EBS-Konten ohne entsprechendes AD-Konto (von nie bereinigten Mitarbeiterabgängen). Erwarten Sie, 5–10 % der Konten in diesem Zustand zu finden
• Berechtigungs-Drift: Konten mit EBS-Verantwortlichkeiten, die nicht mit aktuellen Jobrollen übereinstimmen — über Jahre von Rollenwechseln ohne ordnungsgemäßes Deprovisioning angesammelt
• Geteilte Konten: Dienstkonten oder geteilte Logins, die nicht Einzelpersonen zugeordnet werden können. Diese müssen in benannte Konten umgewandelt oder explizit von SSO mit kompensierenden Kontrollen ausgenommen werden

Alle Anomalien vor dem SSO-Cutover beheben. Dann automatisiertes Provisioning und Deprovisioning über Microsoft Identity Manager oder Azure-AD-Lifecycle-Workflows implementieren, um ein Wiederauftreten zu verhindern.

Rollout-Strategie

SSO niemals für alle Benutzer gleichzeitig aktivieren. Ein stufenweiser Rollout ist essenziell, besonders in regulierten Umgebungen:

1. Welle 1 — IT und Finanzen (5–10 % der Benutzer): Technische Pilotgruppe. Mindestens 4 Wochen laufen lassen. Helpdesk-Tickets, Authentifizierungslogs und Session-Fehler intensiv überwachen
2. Welle 2 — Hauptsitz (40–50 % der Benutzer): Größte Kohorte. Legacy-Authentifizierung 2 Wochen parallel als Fallback laufen lassen. Diese Welle validiert Skalierbarkeit
3. Welle 3 — Regionale und Außendienst-Benutzer (Rest): Remote-Rollout mit Self-Service-Onboarding-Materialien. Diese Benutzer authentifizieren sich oft selten, daher treten Randfälle hier auf

Eine 60-tägige Stabilisierungsphase nach vollständigem Rollout einplanen, bevor die Legacy-Authentifizierung abgeschaltet wird. Passwortbezogene Helpdesk-Tickets als primäre Erfolgsmetrik tracken — eine gut durchgeführte SSO-Integration sollte diese innerhalb der ersten zwei Monate um 70–80 % reduzieren.