Federation Proxy in OAM und IdP

In diesem Artikel wird das Konzept des Federation-Proxys erläutert, und es wird erläutert, wie IdP einfach so konfiguriert werden kann, dass es zu einem SP wird, und wie die Authentifizierung an ein anderes Remote-IdP delegiert werden kann, anstatt den Benutzer lokal zu authentifizieren.

Der Federation-Proxy wird normalerweise verwendet, wenn ein Federation-Hub wie folgt funktioniert:

Ein IdP für SP-Partner, bei dem IdP die Föderationsvertrauensstellung zwischen diesen SPs und sich selbst aggregiert
Ein SP mit Remote-IdP-Partnern

Diese Lösung hat den Vorteil:

Reduzierung des Vertrauensmanagement-Overheads
Jeder neue IdP-Partner, der dem Federation-Hub hinzugefügt wurde, ist automatisch für alle SP-Partner verfügbar, die in den Federation-Hub integriert sind
Jeder neue SP-Partner, der dem Federation-Hub hinzugefügt wurde, muss nicht unter IdP-Partnern definiert werden
Bereitstellung eines mehrschichtigen Federation-Trust-Modells, bei dem der Federation-Hub das Federation-Deployment für die IdP-Partner verbirgt

Direct Trust-Modell

In diesem Modell vertrauen die verschiedenen Federation-Server einander direkt an, und es gibt keine Zwischen-Entitys, die als Proxy fungieren.

Dieses Modell hat den Vorteil, die Komplexität der Federation-Abläufe zu reduzieren, da nur zwei Server am SSO-Vorgang beteiligt sind. Manchmal hat es jedoch den Nachteil, einen enormen Verwaltungsaufwand zu schaffen, dem Partner möglicherweise nicht zustimmen.

Nehmen wir ein Beispiel für ein globales Unternehmen namens ACME Corp, das Büros in der ganzen Welt hat. Die Struktur des Unternehmens besteht aus drei Top-Organisationen, die eine andere Region der Welt repräsentieren, und jede Organisation ist für ihre Sicherheitsdomäne verantwortlich:

Nord- und Südamerika
Europäisch
Asien-Afrika-Pazifik

Jede Organisation verfügt über eine eigene Sicherheitsdomain, was bedeutet:

Eine Gruppe von Ressourcen
Ein SSO-Server
Ein Federation-Server Die Entitys einer Organisation sind unabhängig von denen einer anderen Organisation. Wenn Sie in einer Domain authentifiziert werden, erhalten Sie erst dann Zugriff auf Ressourcen einer anderen Domain, wenn die Authentifizierung in dieser anderen Domain durchgeführt wurde.

Jetzt sagen wir, dass ACME Corp eine Föderationsvereinbarung mit einigen Dienstleistern haben möchte, von denen einige Lieferanten sind, andere von ACME Corp erworbene Dienstleistungen, wie ein Konferenzanrufservice, sowie ein Webex-Service.

Um eine Föderation zwischen den verschiedenen ACME Corp-Organisationen und den SPs zu schaffen, muss der Federation-Server jeder Organisation Vertrauen mit jedem Remote-SP aufbauen:

Die Anzahl der Treuhandeinrichtungen muss hoch sein
Die SP-Partner können sich aufgrund der hohen Anzahl an Federation-Vereinbarungen für einen einzelnen Kunden weigern, diese Art von Trust-Niederlassung einzurichten.

Dieses Diagramm stellt alle Vereinbarungen dar, die getroffen werden müssten:

Beschreibung der Abbildung Direct_Trust_Model.jpg

Dieser Ansatz wird in der Regel vermieden, da er für den Partner die interne Komplexität der Infrastruktur von ACME Corp veröffentlicht.

Federation-SSO und SAML wurden so definiert, dass zwei unterschiedliche Sicherheitsdomains domainübergreifendes SSO so ausführen können, dass ein Partner die Sicherheitsimplementierung und das Deployment des anderen Partners nicht kennen muss. In diesem Fall wird deutlich, dass dieses Versprechen gebrochen ist und dass die Komplexität der Sicherheitsentscheidungen von ACME Corp die SP-Partner beeinträchtigt.

Brokered Trust-Modell

In diesem Modell gibt es das Konzept des Federation-Proxys, bei dem einige Entitys als Proxys/SPs verwendet werden müssen, um Federation-SSO-Vorgänge im Namen anderer SPs auszuführen.

Wenn wir erneut unser Beispiel für ACME Corp nehmen, ist der richtige Ansatz zur Implementierung von Federation SSO mit anderen SP-Partnern über ein Brokered Trust-Modell oder Federation Proxy, wobei:

Ein neuer Server wird in ACME Corp als Federation-Hub installiert
Der Federation Hub fungiert als Serviceprovider für die interne IdPs von ACME Corp.
Der Federation Hub fungiert als IdP für die externen SPs (Lieferanten, Telefonkonferenz und webex)
Während eines Federation-SSO-Vorgangs fungiert der Hub als SP und löst einen Federation-SSO-Vorgang mit einem internen Remote-IdP aus, anstatt den Benutzer direkt anzufordern

Dieser Ansatz entspricht eher der Föderation/SAML-Philosophie, bei der die externen Partner die Sicherheitsinfrastruktur und Komponenten von ACME Corp nicht kennen und nur mit einer einzigen IdP interagieren.

Diese Lösung löst auch den hohen Verwaltungsaufwand, bei dem die Anzahl der Vereinbarungen besonders hoch war und Aktualisierungen der Vereinbarung zu einem langwierigen Prozess führte. Mit diesem Ansatz:

Federation-Vereinbarungen bestehen zwischen dem Hub und dem internen IdPs sowie zwischen dem Hub und externen SPs
Das Hinzufügen eines internen IdP ist für die externen SPs nicht sichtbar
Das Hinzufügen eines externen SP ist für den internen IdPs nicht sichtbar
Die Aktualisierung der Federation-Vereinbarung (z.B. für Schlüssel-Rollover) ist ein einmaliger Vorgang, der nicht mehrmals wiederholt wird.

Dieses Diagramm stellt die Federation-Vereinbarungen dar, die in einem Brokered Trust-(oder Federation Proxy-)Modell erforderlich sind:

Beschreibung der Abbildung Brokered_Trust_Model.jpg

Federation-Proxy in OAM

Das Ziel in einem Federation-Proxy besteht darin, IdP in einen SP umzuwandeln, sodass IdP beim Empfang einer SSO-Anforderung von einem ersten Remote-SP zu einem SP wird und einen neuen Federation-SSO-Vorgang mit einem zweiten Remote-IdP auslöst, anstatt den Benutzer lokal herauszufordern.

Nach dem erfolgreichen Abschluss des zweiten Federation-SSO-Vorgangs hat der Proxy IdP den Benutzer identifiziert und kann eine SSO-Antwort für den ursprünglichen SP erstellen.

OAM unterstützt den Federation Proxy Now für alle Protokolle:

SAML 2.0, SAML 1.1 und OpenID 2.0
Das Protokoll zwischen dem ursprünglichen SP und IdP entspricht dem Protokoll, das zwischen OAM/SP und dem zweiten Remote-IdP verwendet wird
Das Protokoll zwischen dem ursprünglichen SP und IdP unterscheidet sich von dem Protokoll, das zwischen OAM/SP und dem zweiten Remote-SP IdP verwendet wird

Ein SP könnte also Federation-SSO mit IdP über SAML 1.1 ausführen, und IdP wird zu einem SP und Federation-SSO mit einem zweiten Remote-IdP über SAML 2.0. Der ursprüngliche SP muss das zwischen OAM/SP und der zweiten IdP verwendete Protokoll oder gar keinen zweiten Federation-SSO-Vorgang kennen.

In einem Federation Proxy Now kann IdP so konfiguriert werden, dass die im zweiten Federation-SSO angegebene Federation-Authentifizierungsmethode an den ursprünglichen SP weitergeleitet wird.

OAM für Federation-Proxy konfigurieren

Wie bereits beschrieben, nutzt IdP OAM für die Benutzerauthentifizierung: Bei jedem Federation-SSO-Vorgang ruft IdP OAM auf, indem ein Authentifizierungsschema angegeben wird, um sicherzustellen, dass der Benutzer ausreichend authentifiziert ist, und fordert ihn bei Bedarf an.

Wie Sie wissen, definiert OAM bestimmte Schemas, die an OAM/SP gebunden sind: Wenn ein nicht authentifizierter Benutzer Zugriff auf eine Ressource anfordert, die durch eine FederationScheme geschützt ist (oder ein Schema, das ein Authentifizierungsmodul ähnlich dem FederationPlugin verwendet), ruft OAM OAM/SP auf, das einen Federation-SSO-Vorgang mit einer Remote-IdP auslöst.

Damit IdP einen Federation-Proxy jetzt ausführt, müssen Sie IdP mit einem FederationScheme aufrufen, anstatt OAM mit einem lokalen Authentifizierungsschema aufzurufen. Von dort:

OAM ruft OAM/SP auf und löst ein neues Federation-SSO Now mit einem zweiten Remote-IdP aus
Die zweite Remote-IdP authentifiziert den Benutzer bei Bedarf und gibt eine SSO-Antwort aus
OAM/SP validiert die SSO-Antwort, erstellt eine OAM-Session
OAM leitet den Benutzer zu IdP um.
IdP erstellt eine SSO-Antwort und leitet den Benutzer mit dieser Antwort an den ursprünglichen SP um

WLST-Befehl

Um IdP so zu konfigurieren, dass ein Benutzer anstelle eines lokalen Authentifizierungsverfahrens mit Federation SSO authentifiziert wird, führen Sie einen der folgenden Befehle aus:

setIdPDefaultScheme(), um das globale Standardschema als Federation-Schema festzulegen
setSPPartnerProfileDefaultScheme(), um das Standardschema für ein SP-Partnerprofil festzulegen
setSPPartnerDefaultScheme(), um das Standardschema für einen SP-Partner festzulegen

Weitere Informationen zur Konfiguration von OAM für die Authentifizierung finden Sie im Artikel zur Authentifizierung in IdP. In diesem Beispiel konfigurieren Sie IdP global für die Verwendung von Federation SSO als Standardauthentifizierungsmechanismus:

Geben Sie die WLST-Umgebung ein, indem Sie Folgendes ausführen: $IAM_ORACLE_HOME/common/bin/WLST.sh.
Stellen Sie eine Verbindung zum WLS-Admin-Server her: connect().
Navigieren Sie zur Domainlaufzeitverzweigung: domainRuntime().
Führen Sie den setIdPDefaultScheme()-Befehl aus: setIdPDefaultScheme("FederationScheme").
Beenden Sie die WLST-Umgebung: exit().

Mit dieser Änderung wird FederationScheme zur Authentifizierung von Benutzern verwendet.

Andere Federation-Schemas können zur Authentifizierung des Benutzers verwendet werden, wobei OAM entweder auf globaler Ebene konfiguriert wird (alle Benutzer aller SPs werden mit diesem Federation-Schema authentifiziert) oder auf SP-Partnerebene (alle Benutzer, die Federation SSO mit diesem spezifischen SP ausführen, werden mit diesem Federation-Schema authentifiziert). Denken Sie daran, dass Sie ein Federation-Schema für ein bestimmtes IdP erstellen können, entweder über den OAM WLST-Befehl createAuthnSchemeAndModule oder über den Abschnitt "IdP-Partner bearbeiten" in der OAM-Administrationskonsole.

Zu verwendende zweite IdP bestimmen

Wenn ein Federation-Schema zur Authentifizierung in OAM verwendet wird, muss OAM/SP bestimmen, welche IdP für den Federation-SSO-Vorgang verwendet werden soll:

Wenn das Schema ein Schema war, das aus einem IdP-Partnereintrag erstellt wurde, weist es OAM/SP an, Federation SSO mit diesem IdP auszuführen
Wenn das Schema FederationScheme ist, wertet OAM/SP zuerst aus, ob es für die Verwendung eines IdP Discovery Service konfiguriert ist
Wenn er für einen IdP Discovery Service konfiguriert ist, leitet OAM/SP den Benutzer an diesen Service um, um einen IdP auszuwählen
Andernfalls verwendet OAM/SP das Standard-SSO IdP

So legen Sie einen IdP-Partner als Standard-SSO IdP fest:

Gehen Sie in der OAM-Administrationskonsole zum IdP-Partner, und aktivieren Sie das Kontrollkästchen Standard-Identitätsproviderpartner.
Sie können auch den OAM WLST-Befehl setDefaultSSOIdPPartner() verwenden, indem Sie den IdP-Partnernamen angeben.

Proxying Federation-Authentifizierungsmethoden

Wie in einem vorherigen Artikel erläutert, ordnet IdP beim Erstellen einer Assertion das lokale OAM-Schema, das zur Authentifizierung des Benutzers verwendet wird, einer Federation-Authentifizierungsmethode zu.

Bei einem Federation-SSO-Proxy "Jetzt" bedeutet dies, dass ein FederationScheme einer Federation-Authentifizierungsmethode zugeordnet ist. Beispiel: Wenn das Schema urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport für SAML 2.0 zugeordnet werden muss, verwendet der Administrator einen Befehl ähnlich dem folgenden:

So erstellen Sie die Zuordnung auf einer SP-Partnerprofilebene: addSPPartnerProfileAuthnMethod("saml20-sppartner-profile","urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport", "FederationScheme")
So erstellen Sie die Zuordnung auf SP-Partnerebene: addSPPartnerAuthnMethod("AcmeSP","urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport ", "FederationScheme")

In einigen Fällen empfiehlt es sich, die aus dem zweiten IdP empfangene Federation-Authentifizierungsmethode weiterzuleiten, anstatt das Federation-Schema lokal einer Federation-Authentifizierungsmethode zuzuordnen.

So konfigurieren Sie IdP für die Weiterleitung der Federation-Authentifizierungsmethoden in einem Federation-SSO-Proxy.

Verwenden Sie jetzt den Befehl useProxiedFedAuthnMethod():

Geben Sie die WLST-Umgebung ein, indem Sie Folgendes ausführen: $IAM_ORACLE_HOME/common/bin/WLST.sh.
Stellen Sie eine Verbindung zum WLS-Admin-Server her: connect().
Navigieren Sie zur Domainlaufzeitverzweigung: domainRuntime().
Führen Sie den useProxiedFedAuthnMethod()-Befehl aus: useProxiedFedAuthnMethod(enabled="true/false",authnSchemeToAdd="SCHEME", authnSchemeToRemove="SCHEME").

Der aktivierte Parameter gibt an, ob IdP so konfiguriert werden soll, dass die Federation-Authentifizierungsmethoden in einem Federation-SSO-Proxy jetzt weitergeleitet werden
Der Parameter authnSchemeToAdd gibt an, welches OAM-Authentifizierungsschema ein Federation-Schema ist: Mit diesem Parameter kann IdP bestimmen, ob die gecachte Federation-Authentifizierungsmethode basierend auf dem Authentifizierungsschema der Benutzersession verwendet werden soll
Der Parameter authnSchemeToRemove entfernt ein OAM-Authentifizierungsschema aus der Liste der Schemas, die als Federation-Schemas markiert sind, für die IdP die Authentifizierungsmethode "Proxied Federation" verwenden soll
Beispiel: useProxiedFedAuthnMethod(enabled="true", authnSchemeToAdd="FederationScheme")

Beenden Sie die WLST-Umgebung: exit().

Weitere Lernressourcen

Sehen Sie sich weitere Übungen unter docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning-Kanal YouTube zu. Besuchen Sie außerdem education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.

Titel und Copyright-Informationen

Federation Proxy in OAM and IdP

F60446-01

September 2022