Integration von ADFS 2.0 und 3.0 mit OAM: Voraussetzung

In diesem Artikel wird beschrieben, wie OAM mit dem SAML 2.0-Protokoll in ADFS 2.0/3.0 für Federation SSO integriert wird. Die Integration umfasst:

• Voraussetzungen (dieser Artikel)

• ADFS 2.0/3.0 als IdP und OAM als SP

• ADFS 2.0/3.0 als SP und OAM als IdP

Die SAML 2.0-Integration basiert auf:

• E-Mail-Adresse, die als NameID-Format verwendet wird

• Der Wert NameID enthält die E-Mail-Adresse des Benutzers.

• Das HTTP-POST-Binding wird verwendet, um die SAML-Assertion an den SP zu senden

• Benutzer sind in beiden Systemen vorhanden, wobei jeder Benutzer dieselbe E-Mail-Adresse hat, damit er als allgemeines Benutzerattribut verwendet werden kann.

ADFS 2.0 ist in Windows 2008 R2 verfügbar, während ADFS 3.0 in Windows 2012 R2 verfügbar ist. Die Artikel zeigen Screenshots für ADFS 3.0, während die dokumentierten Schritte für beide Versionen gelten.

Voraussetzungen

Für die Integration mit ADFS mit dem SAML 2.0-Protokoll muss OAM so konfiguriert sein, dass HTTPS/SSL als Endpunkte verwendet wird. Andernfalls akzeptiert ADFS beim Aufbau von Federation Trust die OAM SAML 2.0-Metadaten nicht.

Bei der Integration von ADFS als IdP mit OAM als SP müssen folgende Punkte berücksichtigt werden:

• Standardmäßig verschlüsselt ADFS IdP die SAML-Assertion, wenn sie mit AES-256 an den SP gesendet wird. Standardmäßig kann das im OAM-Deployment verwendete JDK keine starke Kryptografie verwenden, wie AES-256. So:

  • Entweder muss das JDK für starke Kryptografie konfiguriert sein

  • Oder ADFS IdP muss zum Deaktivieren der Verschlüsselung konfiguriert werden

• Wenn ADFS IdP für die Authentifizierung über die HTTP-Basisauthentifizierung oder die Windows-native Authentifizierung konfiguriert ist, kann der Benutzer nie abgemeldet werden als:

  • Die Zugangsdaten für die HTTP-Basisauthentifizierung können nach der Eingabe nicht mehr aus dem Browser entfernt werden, es sei denn, der Browser ist geschlossen

Hinweis: Dies gilt für andere IdPs-Benutzer, die eine HTTP-Basisauthentifizierung verwenden, um den Benutzer zu fragen.

• Der Browser ist immer bei ADFS angemeldet, wenn die native Windows-Authentifizierung verwendet wird.

• Standardmäßig erfordert ADFS, dass Nachrichten mit SHA-256 signiert werden, während OAM standardmäßig SHA-1 verwendet:

  • Konfigurieren Sie ADFS zur Verwendung/Akzeptierung von SHA-1

  • Oder konfigurieren Sie OAM so, dass SHA-256 für Signaturen verwendet wird

Vor der Integration von OAM und ADFS für SAML 2.0 müssen die Metadaten für die beiden Server heruntergeladen worden sein.

SSL aktivieren

Es gibt verschiedene Möglichkeiten, SSL auf den öffentlichen Endpunkten für OAM zu aktivieren:

• Wenn ein Load Balancer OAM als Frontend verwendet, kann SSL/HTTPS im Load Balancer aktiviert/konfiguriert werden

• Wenn OHS OAM vorgibt, wird OHS für SSL konfiguriert

• Wenn keine Komponente OAM voranstellt, kann der WLS-Server, auf dem OAM ausgeführt wird, für SSL/HTTPS konfiguriert werden

Nachdem die Komponente (Load Balancer, OHS oder WLS) für SSL konfiguriert wurde, muss die OAM-Konfiguration aktualisiert werden, damit der neue Endpunkt als öffentliche URL referenziert wird:

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

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

3. OAM-Serverhost auf den Hostnamen des öffentlichen Endpunkts setzen

4. OAM-Serverpost auf den SSL-Port des öffentlichen Endpunkts setzen

5. OAM-Serverprotokoll auf "https" setzen

6. Klicken Sie auf Apply.

Beschreibung der Abbildung Access_Manager_Settings.jpg

Hinweis: Nachdem Sie diese Änderungen vorgenommen haben, enthält das Abrufen der OAM SAML 2.0-Metadaten die neuen HTTPS-URLs.

Effiziente Verschlüsselung

Wie erwähnt, verschlüsselt ADFS IdP standardmäßig die SAML-Assertion beim Senden an den SP mit AES-256, die von Java als starke Cipher betrachtet wird (im Gegensatz zu "normaler Stärke" wie AES-128, AES-192, 3DES...).

Aufgrund rechtlicher Exportgründe kann JDK nicht mit starken Ciphers versendet werden, die in JCE aktiviert sind: administrator/integrator/developer muss die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy herunterladen und installieren.

Um die JCE Unlimited Strength Jurisdiction-Policy-Dateien zur Unterstützung einer starken Verschlüsselung wie AES-256 zu aktualisieren, führen Sie die folgenden Schritte aus:

1. Ermitteln Sie die Hauptversion von Java, die im OAM-Deployment verwendet wird.

2. Suchen Sie den JDK-Ordner, der von OAM Execute verwendet wird: $JDK_HOME/bin/java -version.

3. Die Hauptversion wird gedruckt (6 oder 7).

4. Laden Sie die JCE Unlimited Strength Jurisdiction Policy herunter.

5. Wenn Sie JDK 7 verwenden:

   • http://www.oracle.com/technetwork/java/javas%20/downloads/index.htm

6. Wenn Sie JDK 6 verwenden:

   • http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archivedownloads-java-plat-419418.html

7. Extrahieren Sie den Inhalt der heruntergeladenen ZIP-Datei in einen temporären Ordner.

8. Kopieren Sie die dekomprimierten Dateien local_policy.jar und US_export_policy.jar in das folgende JDK-Verzeichnis (dieser Vorgang überschreibt die Dateien local_policy.jar und US_export_policy.jar in diesem Ordner): $JDK_HOME/jre/lib/security.

9. Starten Sie die WLS-Server in der WLS-Domain neu, um die Änderungen anzuwenden.

So konfigurieren Sie ADFS so, dass die Verschlüsselung beim Senden der SAML-Assertion an einen SP deaktiviert wird:

1. Gehen Sie zu dem Rechner, auf dem ADFS bereitgestellt wird.

2. Wenn ADFS 2.0 verwendet wird, klicken Sie auf Startmenü, Programme, Administrative Tools, Windows PowerShell Module.

3. Wenn ADFS 3.0 verwendet wird, klicken Sie auf Menü starten , Verwaltungstools , Active Directory-Modul für Windows PowerShell.

4. Führen Sie den folgenden Befehl aus (ersetzen Sie RP_NAME durch den SP-Namen, mit dem der Partner in ADFS erstellt wird): set-ADFSRelyingPartyTrust –TargetName“RP_NAME” –EncryptClaims $False.

ADFS-Abmeldung

Das SAML 2.0-Protokoll definiert ein Abmeldeprofil, bei dem jeder an einem Federation-SSO beteiligte Federation-Partner für die Session des aktuellen Benutzers über die Abmeldung des Benutzers benachrichtigt wird. Dadurch können die verschiedenen Federation-Partner die Benutzersession in ihrer SSO-Domain beenden.

ADFS IdP bietet verschiedene Möglichkeiten zur Authentifizierung des Benutzers, wenn ein Federation-SSO ausgeführt wird:

• FORM-basierte Authentifizierung, wobei

  • Der Server zeigt eine Anmeldeseite an

  • Der Benutzer gibt die Zugangsdaten ein und leitet sie weiter

• HTTP-Basisauthentifizierung

  • Dabei gibt der Server einen 401-Statuscode an den Browser zurück

  • Der Browser erfasst die Zugangsdaten des Benutzers

  • Der Browser zeigt die Zugangsdaten für den ADFS-Server an

Hinweis: Der Browser speichert die Zugangsdaten und stellt sie dem ADFS-Server jederzeit zur Verfügung, wenn der Browser auf ADFS zugreift, bis der Browser geschlossen wird.

• Integrierte Windows-Authentifizierung, bei der ADFS den Benutzerauthentifizierungsstatus in der Windows-Umgebung nutzt: In diesem Fall wird der Benutzer automatisch authentifiziert, da er bereits bei Windows angemeldet ist, ohne Benutzerinteraktion.

Der Effekt (oder die Nichtauswirkung) der SAML 2.0-Abmeldung wird je nach Authentifizierung des Benutzers untersucht:

• SP startet einen Federation-SSO-Vorgang mit ADFS IdP

• ADFS IdP muss den Benutzer authentifizieren/identifizieren

  • Wenn die FORM-basierte Authentifizierung verwendet wird, zeigt ADFS eine Anmeldeseite an, und der Benutzer gibt seine Zugangsdaten ein

  • Wenn HTTP-Basisauthentifizierung verwendet wird, gibt ADFS den Antwortcode 401 zurück. Der Browser erfasst die Zugangsdaten des Benutzers und zeigt sie ADFS an

  • Bei Verwendung der integrierten Windows-Authentifizierung erhält der Browser automatisch ein Kerberos/NTLMSSP-Token vom Windows-Domaincontroller/KDC, das er dem ADFS-Server darstellt. Es ist keine Benutzerinteraktion vorhanden.

• Benutzer wird mit einer SAML-Assertion an SP umgeleitet

• Benutzer initiiert die SAML 2.0-Abmeldung vom SP

• SP leitet den Benutzer zur ADFS-IdP für die SAML 2.0-Abmeldung um

• ADFS löscht Cookies aus dem Browser des Benutzers (die zuvor verwendeten HTTP-Basisauthentifizierungszugangsdaten werden jedoch nicht gecacht)

• Im selben Browser startet SP einen Federation-SSO-Vorgang mit ADFS IdP

• ADFS IdP muss den Benutzer authentifizieren/identifizieren

  • Wenn die FORM-basierte Authentifizierung verwendet wird, zeigt ADFS eine Anmeldeseite an, und der Benutzer gibt seine Zugangsdaten ein: Benutzer wird aufgefordert und muss seine Zugangsdaten angeben

  • Wenn HTTP-Basisauthentifizierung verwendet wird, gibt ADFS den Antwortcode 401 zurück. Der Browser cacht die zuvor erfassten Zugangsdaten und zeigt sie so automatisch ADFS an. Keine Benutzerinteraktion vorhanden

  • Bei Verwendung der integrierten Windows-Authentifizierung erhält der Browser automatisch ein Kerberos/NTLMSSP-Token vom Windows-Domaincontroller/KDC, das er dem ADFS-Server darstellt. Es ist keine Benutzerinteraktion vorhanden.

Wenn also die HTTP-Basisauthentifizierung oder die integrierte Windows-Authentifizierung als Authentifizierungsmechanismus bei ADFS 2.0 IdP verwendet wird, wird der Benutzer nach einer Abmeldung weiterhin unter IdP "angemeldet". Wenn ein neues Federation-SSO ausgeführt wird, wird der herausgeforderte Benutzer nicht ausgelöst, und der Benutzer wird nach Abschluss des Federation-SSO automatisch beim SP authentifiziert.

Wichtiger Hinweis: Das Verhalten bei der Abmeldung gilt auch für andere IdPs (z.B. OAM), die HTTP-Basisauthentifizierung als Authentifizierungsmechanismus verwenden.

SAML 2.0-Metadaten

So laden Sie die SAML 2.0-Metadaten vom ADFS 2.0/3.0-Server herunter:

1. Öffnen Sie einen Browser.

2. Gehen Sie zu ADFS 2.0/3.0 Metadata Publishing Service: https://adfs-host:adfs-port/FederationMetadata/2007-06/FederationMetadata.xml.

3. Speichern Sie die Metadaten lokal mit der Schaltfläche "Speichern unter" im Browser.

So laden Sie die SAML 2.0-Metadaten aus OAM herunter:

1. Öffnen Sie einen Browser.

2. Gehen Sie zum Veröffentlichungsservice für OAM-Metadaten: http(s)://OAM-runtime-host:OAM-runtimeport/oamfed/idp/metadata oder http(s)://OAM-runtime-host:OAM-runtimeport/oamfed/sp/metadata.

3. Speichern Sie die Metadaten lokal mit der Schaltfläche "Speichern unter" im Browser.

Hinweis: Stellen Sie sicher, dass SSL in OAM zuerst aktiviert ist, bevor Sie die OAM-Metadaten herunterladen, da die Metadaten die OAM-URLs enthalten.

SHA-256 und SHA-1

Nachdem Sie die Föderation zwischen OAM und ADFS eingerichtet haben, müssen Sie:

• Konfigurieren Sie ADFS 2.0 für die Verwendung/Akzeptierung von SHA-1

• Oder konfigurieren Sie OAM so, dass SHA-256 für Signaturen verwendet wird

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

Integrating ADFS 2.0 and 3.0 with OAM Pre-requisite

F60452-01

September 2022

Copyright © 2022, Oracle and/or its affiliates.