DCC HTTP Reverse Proxy mit OAM und OAM

In diesem Artikel wird das Feature "Detached Credential Collector (DCC) HTTP Reverse Proxy" beschrieben, das in Release 11.1.2.2.0 eingeführt wurde.

In einem Deployment, in dem dieses Feature aktiviert ist, ein WebGate SSO-Agent:

In diesem Modus erfolgen alle Interaktionen zwischen den Benutzern/Clients und OAM über den WebGate DCC HTTP Reverse Proxy: Keine Benutzer greifen mehr direkt auf die OAM-Server zu.

Diese neue DCC-HTTP-Reverse-Proxy-Funktion unterscheidet sich von der vorherigen DCC-Funktion für die HTTPBasic-/FORM-basierte Anmeldung, wobei letztere nicht für die Federation-SSO-Abläufe (IdP- oder SP-Modus) funktioniert.

Überblick

Dieser Artikel enthält keine Topologien mit HTTP-Reverse-Proxys oder Load Balancer, die den verschiedenen OAM-Komponenten (dem OAM-Server selbst oder den WebGate-Agents) vorangestellt sind, enthält jedoch einen Anwendungsfall gegen Ende, der angibt, wie DCC-HTTP-Reverse-Proxy in HA-Deployments verwendet wird, vor dem ein Load Balancer steht.

Authentifizierung ohne DCC

Der Authentifizierungsablauf ohne DCC ist der häufigste Anwendungsfall, bei dem der Benutzer von den SSO-Agents umgeleitet wird, die Ressourcen in der Sicherheitsdomain zur Challenge und Authentifizierung an OAM schützen. Ein typisches OAM-Deployment besteht aus den folgenden Entitys:

Eine solche Umgebung wird im folgenden Diagramm beschrieben:

Beschreibung der Abbildung local_security_domain.jpg

Verwenden Sie im Testablauf LDAPScheme OOTB als Schema, um die Ressourcen der lokalen Sicherheitsdomain zu schützen.

Ein lokaler Authentifizierungsablauf mit LDAPScheme umfasst Folgendes:

  1. Der Benutzer fordert den Zugriff auf eine geschützte Ressource an, die in OAM zum Schutz durch die LDAPScheme definiert ist.

  2. Der SSO-Agent WebGate fängt die HTTP-Anforderung ab, bestimmt, ob der Benutzer authentifiziert werden muss, und leitet den Benutzer zur Authentifizierung an den OAM-Server um.

  3. Der Benutzer greift auf den OAM-Server zu. Der Server initiiert einen Authentifizierungsablauf mit LDAPScheme und zeigt die Anmeldeseite an

Beschreibung der Abbildung local_authentication_flow.jpg

Nachdem der Benutzer seine Zugangsdaten eingegeben und auf die Schaltfläche Anmelden geklickt hat, geschieht Folgendes:

  1. Der OAM-Server validiert die Zugangsdaten, erstellt eine Session für den Benutzer, legt ein Cookie im Browser des Benutzers fest und leitet den Benutzer an die geschützte Ressource um.

  2. Der Benutzer fordert Zugriff auf die Ressource an. Diesmal erkennt der SSO-Agent von WebGate, dass der Benutzer authentifiziert ist, und erteilt Zugriff auf die Ressource

Beschreibung der Abbildung local_security_workflow.jpg

DCC für HTTP-Basic/FORM-basierte Anmeldung

DCC für HTTP-Basic-/FORM-basierte Anmeldung wurde in früheren Releases von OAM 11g eingeführt. Damit kann ein Administrator einen WebGate-SSO-Agent als Entity angeben, die:

Verwenden Sie im Testablauf die DCCLDAPScheme, die auf dem LDAPScheme OOTB basiert, bei der Challenge-URL jedoch aktualisiert wurde, um den DCC WebGate zu referenzieren. Dieses Schema wird verwendet, um die Ressourcen der lokalen Sicherheitsdomain zu schützen.

Ein lokaler Authentifizierungsablauf, der diesen benutzerdefinierten DCCLDAPScheme verwendet, umfasst Folgendes:

  1. Der Benutzer fordert den Zugriff auf eine geschützte Ressource an, die in OAM zum Schutz durch die DCCLDAPScheme definiert ist.

  2. Der SSO-Agent WebGate fängt die HTTP-Anforderung ab, bestimmt, ob der Benutzer authentifiziert werden muss, und leitet den Benutzer zur Authentifizierung an die Anmeldeseite von DCC WebGate um.

  3. Der Benutzer greift auf die Anmeldeseite von DCC WebGate zu und stellt Zugangsdaten bereit.

  4. Der DCC-WebGate interagiert direkt mit dem OAM-Server, der das OAM-NAP-Protokoll verwendet, um die Zugangsdaten zu validieren und eine Session für den Benutzer zu erstellen. Der DCC WebGate leitet den Benutzer dann an die geschützte Ressource um.

  5. Der Benutzer fordert Zugriff auf die Ressource an. Diesmal erkennt der SSO-Agent von WebGate, dass der Benutzer authentifiziert ist, und erteilt Zugriff auf die Ressource.

DCC-HTTP-Reverse-Proxy

DCC HTTP Reverse Proxy wurde in Release 11.1.2.2.0 von OAM eingeführt und ermöglicht es dem Administrator, einen WebGate SSO-Agent als öffentlichen Endpunkt für den OAM- und OAM-Server zu konfigurieren:

Hinweis: Im Grunde wird der DCC WebGate zum öffentlichen Endpunkt für OAM und OAM und fungiert als HTTP Reverse Proxy über das OAM NAP-Protokoll.

In diesem Test werden nach der Konfiguration von OAM und WebGate für DCC HTTP Reverse Proxy die LDAPScheme OOTB als Schema verwendet, um die Ressourcen der lokalen Sicherheitsdomain zu schützen (das Schema wurde nicht geändert).

Hinweis: Jedes Authentifizierungsschema mit einer Challenge-URL, die einen relativen Pfad enthält, kann in diesem DCC-Modus verwendet werden, wie FederationScheme. Außerdem ist das Feature IdP mit diesem DCC-Modus kompatibel

Ein lokaler Authentifizierungsablauf mit LDAPScheme umfasst Folgendes:

  1. Der Benutzer fordert den Zugriff auf eine geschützte Ressource an, die in OAM zum Schutz durch die LDAPScheme definiert ist.

  2. Der SSO-Agent WebGate fängt die HTTP-Anforderung ab, bestimmt, ob der Benutzer authentifiziert werden muss, und leitet den Benutzer zur Authentifizierung an den DCC WebGate um.

  3. Der Benutzer greift auf DCC WebGate zu und leitet die Anforderung an den OAM-Server weiter. Der Server initiiert einen Authentifizierungsablauf mit LDAPScheme, gibt eine Anmeldeseite zurück, die dem DCC WebGate angezeigt werden soll, und der DCC WebGate zeigt die Anmeldeseite dem Benutzer an.

Beschreibung der Abbildung local_authentication_flow_LDAP.jpg

Nachdem der Benutzer die Zugangsdaten eingegeben und auf die Schaltfläche Anmelden geklickt hat, geschieht Folgendes:

  1. Der DCC WebGate sendet die HTTP-Anforderung mit den Zugangsdaten an den OAM-Server, der diese validiert, eine Session für den Benutzer erstellt, ein Cookie erstellt und eine HTTP-Antwort mit dem Cookie und einen Umleitungsbefehl an den DCC WebGate zurückgibt. Der DCC WebGate legt das Cookie im Browser des Benutzers fest und leitet den Benutzer an die geschützte Ressource um.

  2. Der Benutzer fordert Zugriff auf die Ressource an. Diesmal erkennt der SSO-Agent von WebGate, dass der Benutzer authentifiziert ist, und erteilt Zugriff auf die Ressource

Beschreibung der Abbildung local_security_LDAPworkflow.jpg

DCC HTTP Reverse Proxy einrichten

Ursprüngliches Setup

Die erforderlichen Schritte zum Konfigurieren eines OAM-Deployments für DCC HTTP Reverse Proxy sind unterteilt in:

Führen Sie die folgenden Schritte aus, um einen bestimmten WebGate SSO-Agent als DCC WebGate zu konfigurieren:

  1. Gehen Sie zur OAM-Administrationskonsole: http(s)://OAM-admin-host:OAM-adminport/oamconsole.

  2. Navigieren Sie zu Access Manager , SSO-Agents.

  3. Suchen Sie nach dem WebGate-Eintrag, den Sie bereits registriert haben.

  4. Klicken Sie auf den Eintrag WebGate, und öffnen Sie ihn.

  5. Aktivieren Sie das Kontrollkästchen Vorgänge zum Erfassen von Zugangsdaten zulassen.

  6. Fügen Sie im Feld "Benutzerdefinierter Parameter" die folgende Zeile hinzu: TunneledUrls=/oam,/oamfed.

  7. Klicken Sie auf Apply.

Beschreibung der Abbildung Setting_DCC.jpg

So aktualisieren Sie die Authentifizierungs-Policys für die OAM- und OAM-Services:

  1. Gehen Sie zur OAM-Administrationskonsole: http(s)://OAM-admin-host:OAM-adminport/oamconsole.

  2. Navigieren Sie zu Access Manager, Anwendungsdomains.

  3. Suchen Sie nach der Anwendungsdomain für DCC WebGate.

  4. Öffnen Sie die Anwendungsdomain.

  5. Klicken Sie auf die Registerkarte Ressourcen.

  6. Konfigurieren Sie die folgende Ressource als öffentliche Ressourcen, indem Sie die Ressourcen als "Ungeschützt" kennzeichnen und eine öffentliche Authentifizierungs-Policy sowie eine öffentliche Autorisierungs-Policy festlegen:

  7. Klicken Sie auf Apply.

Beschreibung der Abbildung Authentication_Policies.jpg

So aktualisieren Sie die OAM-Konfiguration, um den DCC WebGate als neuen öffentlichen Endpunkt für OAM anzugeben

  1. Gehen Sie zur OAM-Administrationskonsole: http(s)://OAM-admin-host:OAM-adminport/oamconsole.

  2. Navigieren Sie zu Konfiguration, Access Manager-Einstellungen.

  3. Geben Sie auf dem OAM-Serverhost den Hostnamen ein, mit dem über den Browser auf den DCC WebGate zugegriffen wird.

  4. Geben Sie im OAM-Serverport den Port ein, mit dem über den Browser auf den DCC WebGate zugegriffen wird.

  5. Geben Sie im OAM-Serverprotokoll das HTTP-Protokoll ein, das für den Zugriff auf den DCC WebGate über den Browser verwendet wird.

  6. Anschließend müssen diese drei Felder den HTTP/HTTPS-Endpunkt DCC WebGate referenzieren.

  7. Klicken Sie auf Apply.

Beschreibung der Abbildung OAM_configuration.jpg

Nachdem die drei Konfigurationsänderungen vorgenommen wurden, werden OAM und OAM so konfiguriert, dass DCC WebGate als HTTP-Reverse Proxy über das NAP-Protokoll verwendet wird.

Wenn die Föderation in der OAM-Administrationskonsole, im Abschnitt Verfügbare Services für Konfiguration aktiviert wurde, können Sie als Test über die DCC-URL WebGate http(s)://DCC-webgatehost:DCC-webgate-port/oamfed/idp/metadata auf die OAM-Metadaten zugreifen und die SAML 2.0-Metadaten für OAM anzeigen. In meinem Setup werden die Metadaten angezeigt, ohne Services neu starten zu müssen. Die URLs der Federation-Services referenzieren den DCC-Speicherort WebGate und nicht mehr den OAM-Server.

Hinweis: Wenn die Federation ProviderID aktualisiert werden muss, können Sie dies über die OAM-Administrationskonsole, die Konfiguration, die Föderation tun, und die Änderung wird im Attribut entityID der Metadaten widergespiegelt.

Ein Beispiel für die Metadaten ist (entityID wird von der OAM-Administrationskonsole, Konfiguration, Abschnitt "Föderation" abgeleitet):

<md:EntityDescriptor entityID="hUp://oam.acme.com
/oam/fed" ...>
  ...
  <md:IDPSSODescriptor>
    ...
    <md:ArtifactResolutionService ...
Location="hUp://dcc-webgate.acme.com:7777
/oamfed/idp/soap"/>
    <md:SingleLogoutService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>     <md:SingleSignOnService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>
    ...
  </md:IDPSSODescriptor>
  ...
</md:EntityDescriptor>

Local Authentication

In meinem Test-Deployment wurde Folgendes bereitgestellt:

LDAPScheme ist der OOTB-Parameter und wurde nicht geändert. Der Parameter "Challenge-URL" referenziert nicht WebGate DCC:

Beschreibung der Abbildung Local_Authentication.jpg

Vor der Konfiguration von OAM, OAM und WebGate2 für DCC HTTP Reverse Proxy führte die Anforderung des Zugriffs auf die geschützte Ressource /cgi-bin/printenv auf OHS1 dazu, dass WebGate1 die Anforderung abfängt und den Browser zur Authentifizierung an den OAM-Server umleitet:

Beschreibung der Abbildung Access_Manager_Screen.jpg

Nach Eingabe der korrekten Zugangsdaten hat OAM den Benutzernamen/das Kennwort validiert und den Browser an die geschützte Ressource umgeleitet.

Nachdem OAM, OAM und WebGate2 für DCC HTTP Reverse Proxy konfiguriert wurden, führt die Anforderung des Zugriffs auf die geschützte Ressource /cgi-bin/printenv auf OHS1 jetzt dazu, dass WebGate1 die Anforderung abfängt und umleitet der Browser zur Authentifizierung an den DCC WebGate, der die HTTP-Anforderung über das NAP-Protokoll an den OAM-Server weiterleitet, der eine anzuzeigende Seite an den DCC WebGate zurücksendet:

Beschreibung der Abbildung Protected_Access_Screen.jpg

Nach Eingabe der korrekten Zugangsdaten geschieht Folgendes:

OAM als SP

Dieser Modus unterscheidet sich geringfügig vom Anwendungsfall für die lokale Authentifizierung. Die einzigen Unterschiede sind:

Hinweis: Es ist keine spezielle Konfiguration erforderlich, um FederationScheme mit dem DCC HTTP Reverse Proxy zu verwenden.

FederationScheme ist der OOTB-Parameter und wurde nicht geändert. Der Challenge-URL-Parameter referenziert nicht WebGate DCC:

Beschreibung der Abbildung Authentication_Schemes.jpg

Wenn die geschützte Ressource angefordert wird, geschieht Folgendes:

  1. Der Benutzer fordert den Zugriff auf eine geschützte Ressource an, die in OAM zum Schutz durch die FederationScheme definiert ist.

  2. Der SSO-Agent WebGate fängt die HTTP-Anforderung ab, bestimmt, ob der Benutzer authentifiziert werden muss, und leitet den Benutzer zur Authentifizierung an den DCC WebGate um.

  3. Der Benutzer greift auf den DCC WebGate zu, der die HTTP-Anforderungen verpackt und über NAP an den OAM-Server sendet. Der Server bestimmt, dass der Benutzer über FederationScheme herausgefordert werden muss, und das OAM/SP-Modul wird aufgerufen.

  4. OAM/SP erstellt eine SAML-Anforderung und erstellt eine 302-Umleitungs-URL mit der SAML-Nachricht. OAM verpackt die Daten und sendet die Antwort zurück an den DCC WebGate, der die HTTP-Antwort an den Browser des Benutzers zurückgibt.

  5. Der Browser des Benutzers wird mit der SAML-Anforderung an IdP umgeleitet.

Beschreibung der Abbildung Protected_Resource_Request.jpg

Nachdem der Benutzer seine Zugangsdaten in IdP eingegeben hat, geschieht Folgendes:

  1. Die IdP erstellt eine SAML-Assertion und leitet den Browser des Benutzers mit der SAML-Nachricht an den DCC WebGate (der Federation-Endpunkt für OAM, veröffentlicht in den SAML 2.0-Metadaten) um.

  2. Der Browser des Benutzers stellt die SAML-Assertion dem DCC WebGate zur Verfügung. Dabei werden die HTTP-Anforderungen verpackt und über NAP an den OAM-Server gesendet, der wiederum das OAM/SP-Modul zur Verarbeitung der SAML-Assertion aufruft.

  3. OAM/SP validiert die SAML-Assertion, OAM erstellt eine Benutzersession, erstellt eine 302-Umleitung zur geschützten Ressource und sendet die Antwort zurück an den DCC WebGate, der die HTTP-Antwort an den Browser des Benutzers zurückgibt.

  4. Der Benutzer wird zur geschützten Ressource umgeleitet

  5. WebGate SSO-Agent erteilt Zugriff

Beschreibung der Abbildung local_security_Webgatedomain.jpg

OAM als IdP

In diesem Anwendungsfall fungiert OAM als Identitätsprovider, und der DCC WebGate ist der öffentliche Endpunkt für IdP. Bei diesem Setup:

Hinweis: Es ist keine spezielle Konfiguration erforderlich, um IdP mit dem DCC HTTP Reverse Proxy zu verwenden.

Wenn ein Benutzer ein Federation-SSO vom Remote-SP initiiert, geschieht Folgendes:

  1. Der Benutzer startet einen Federation-SSO-Vorgang am Remote-SP.

  2. The remote SP creates a SAML Request, and redirects the user to the IdP SAML 2.0 endpoint with the SAML Request: this endpoint is the DCC WebGate HTTP Reverse Proxy, as published in the IdP SAML 2.0 Metadata.

  3. Der Benutzer greift mit der SAML-Anforderung auf den öffentlichen SAML 2.0-Endpunkt IdP am DCC WebGate zu. Der DCC WebGate verpackt die HTTP-Anforderung und die SAML-Nachricht und leitet sie über das OAM-NAP-Protokoll an den IdP-Server weiter.

  4. Der IdP-Server verarbeitet die SAML-Anforderung, bestimmt, dass der Benutzer über die LDAPScheme authentifiziert werden muss, ruft intern OAM zur Authentifizierung auf, wodurch wiederum die anzuzeigende Anmeldeseite an den DCC WebGate zurückgegeben wird. Der DCC WebGate decodiert die Antwort von OAM, die über NAP gesendet wurde, und gibt die HTTP-Antwort an den Browser des Benutzers zurück.

Beschreibung der Abbildung local_security_FedSSO.jpg

Nach der Anzeige der Anmeldeseite geschieht Folgendes:

  1. Der Benutzer gibt seine Zugangsdaten ein und klicken auf die Schaltfläche Anmelden.

  2. DCC WebGate erfasst die eingehenden Daten, verpackt sie und sendet sie über NAP an den OAM-Server.

  3. OAM validiert die Zugangsdaten, erstellt eine Session für den Benutzer und gibt intern die Benutzeridentität an IdP zurück. Der Federation-Server erstellt eine SAML-Assertion und erstellt eine Antwort mit der Assertion, verpackt sie und gibt sie an den DCC WebGate zurück, der die Daten wiederum decodiert und die HTTP-Antwort mit der SAML-Assertion an den Browser des Benutzers sendet.

  4. Der Browser des Benutzers sendet die SAML-Antwort an den SP, der die Assertion erfolgreich validiert.

Beschreibung der Abbildung local_security_DCCWebgate.jpg

DCC HTTP Reverse Proxy und HA

In einem HA-Deployment gelten die erforderlichen Schritte zur Konfiguration der verschiedenen Komponenten (Load Balancer, OAM...) weiterhin, wenn das DCC-Feature "HTTP Reverse Proxy" verwendet wird.

Nehmen wir als Beispiel das folgende Deployment an (andere Arten von HA-Topologien verwenden einen ähnlichen Ansatz):

Die Topologie in diesem Beispiel sieht wie folgt aus:

Beschreibung der Abbildung local_security_Topology.jpg

Die in diesem Beispiel erforderlichen Schritte basieren auf:

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.