Konfigurieren Sie NGINX Plus für SAML SSO mit der Microsoft Entra-ID

Um die Sicherheit zu erhöhen und das Benutzererlebnis zu verbessern, unterstützt F5 NGINX Plus (R29+) jetzt die Security Assertion Markup Language (SAML). SAML ist ein etabliertes Protokoll, das Single Sign-On (SSO) für Webanwendungen bereitstellt. Es ermöglicht einem Identitätsanbieter (IdP), Benutzer für den Zugriff auf eine Ressource zu authentifizieren und diese Informationen dann zur Autorisierung an einen Dienstanbieter (SP) weiterzuleiten.

In diesem Blogbeitrag erläutern wir Schritt für Schritt, wie Sie NGINX mit Microsoft Entra ID , früher bekannt als Azure Active Directory (Azure AD), mithilfe einer Webanwendung integrieren, die SAML nicht nativ unterstützt. Wir erläutern auch, wie SSO für die Anwendung implementiert und in das Microsoft Entra ID-Ökosystem integriert wird. Indem Sie dem Tutorial folgen, erfahren Sie außerdem, wie NGINX Ansprüche aus einer SAML-Assertion (einschließlich UPN, Vorname, Nachname und Gruppenmitgliedschaften) extrahieren und diese dann über HTTP-Header an die Anwendung übergeben kann.

Das Tutorial umfasst drei Schritte:

1. Konfigurieren von Microsoft Entra ID als IdP
2. Konfigurieren der SAML-Einstellungen und NGINX Plus als Reverse-Proxy
3. Testen der Konfiguration

Zum Abschließen dieses Tutorials benötigen Sie:

• NGINX Plus (R29+), das Sie als kostenlose 30-Tage-Testversion erhalten können
• Ein kostenloses oder Enterprise-Microsoft Entra ID-Konto
• Ein gültiges SSL/TLS-Zertifikat, das auf dem NGINX Plus-Server installiert ist (dieses Tutorial verwendet dev.sports.com.crt und dev.sports.com.key )
• Um die SAML-Assertionen zu überprüfen, was durch Herunterladen des öffentlichen Zertifikats demonginx.cer vom IdP erfolgen kann

Notiz : Dieses Tutorial gilt nicht für NGINX Open Source-Bereitstellungen, da der Schlüssel-Wert-Speicher exklusiv für NGINX Plus ist.

Verwenden von NGINX Plus als SAML-Dienstanbieter

In diesem Setup fungiert NGINX Plus als SAML SP und kann an einer SSO-Implementierung mit einem SAML IdP teilnehmen, der indirekt über den User Agent mit NGINX Plus kommuniziert.

Das folgende Diagramm veranschaulicht den SSO-Prozessablauf mit SP-Initiierung und POST-Bindungen für Anforderung und Antwort. Es ist wichtig, noch einmal darauf hinzuweisen, dass dieser Kommunikationskanal nicht direkt ist und über den User Agent verwaltet wird.

Abbildung 1: SAML SP-initiiertes SSO mit POST-Bindungen für AuthnRequest und Response

Schritt 1: Konfigurieren Sie Microsoft Entra ID als Identitätsanbieter

Um auf Ihr Microsoft Entra ID-Verwaltungsportal zuzugreifen, melden Sie sich an und navigieren Sie zum linken Bereich. Wählen Sie „Microsoft Entra ID“ und klicken Sie dann auf den Titel des Verzeichnisses, für das eine SSO-Konfiguration erforderlich ist. Wählen Sie nach der Auswahl „Unternehmensanwendungen“ aus.

Abbildung 2: Auswählen von Enterprise-Anwendungen im Verwaltungsportal

Um eine Anwendung zu erstellen, klicken Sie oben im Portal auf die Schaltfläche Neue Anwendung . In diesem Beispiel haben wir eine Anwendung namens demonginx erstellt.

Abbildung 3: Erstellen einer neuen Anwendung in Microsoft Entra ID

Nachdem Sie zur neu erstellten Anwendung Übersicht weitergeleitet wurden, gehen Sie über das linke Menü zu Erste Schritte und klicken Sie unter Verwalten auf Einmaliges Anmelden . Wählen Sie dann SAML als Single Sign-On-Methode aus.

Abbildung 4: Verwenden des SSO-Abschnitts zum Starten der SAML-Konfiguration

Um SSO in Ihrer Unternehmensanwendung einzurichten, müssen Sie NGINX Plus als SP innerhalb von Microsoft Entra ID registrieren. Klicken Sie dazu auf das Bleistiftsymbol neben „Bearbeiten“ in der grundlegenden SAML-Konfiguration , wie in Abbildung 5 dargestellt.

Fügen Sie die folgenden Werte hinzu und klicken Sie dann auf Speichern :

• Kennung (Entitäts-ID) – https://dev.sports.com
• Antwort-URL (Assertion Consumer Service-URL) – https://dev.sports.com/saml/acs
• Anmelde-URL : https://dev.sports.com
• Abmelde-URL (optional) : https://dev.sports.com/saml/sls

Die Verwendung von Verifizierungszertifikaten ist optional. Beim Aktivieren dieser Einstellung müssen zwei Konfigurationsoptionen in NGINX berücksichtigt werden:

1. Um die Signatur mit einem öffentlichen Schlüssel zu verifizieren, müssen Sie $saml_sp_sign_authn auf true setzen. Dadurch wird der SP angewiesen, die an den IdP gesendete AuthnRequest zu signieren.
2. Geben Sie den Pfad zum privaten Schlüssel an, der für diese Signatur verwendet wird, indem Sie $saml_sp_signing_key konfigurieren. Denken Sie daran, das entsprechende öffentliche Schlüsselzertifikat zur Signaturüberprüfung auf die Microsoft Entra ID hochzuladen.

Notiz : In dieser Demo wurden Attribute und Ansprüche geändert und neue SAML-Attribute hinzugefügt. Diese SAML-Attribute werden vom IdP gesendet. Stellen Sie sicher, dass Ihre NGINX-Konfiguration so eingerichtet ist, dass diese Attribute ordnungsgemäß empfangen und verarbeitet werden. Sie können die zugehörigen Einstellungen im NGINX-GitHub-Repository überprüfen und anpassen.

Laden Sie das IdP -Zertifikat (Raw) von Microsoft Entra ID herunter und speichern Sie es in Ihrer NGINX Plus-Instanz.

Abbildung 5: Herunterladen des IdP-Zertifikats (Raw) von Microsoft Entra ID

Abbildung 6: Hinzufügen eines neuen Benutzers oder einer neuen Gruppe

In Microsoft Entra ID können Sie Zugriff auf Ihre SSO-fähigen Unternehmensanwendungen gewähren, indem Sie Benutzer und Gruppen hinzufügen oder zuweisen.

Klicken Sie im linken Menü auf „Benutzer und Gruppen“ und dann auf die obere Schaltfläche „Benutzer/Gruppe hinzufügen“ .

Schritt 2: Konfigurieren Sie SAML-Einstellungen und NGINX Plus als Reverse-Proxy

Stellen Sie sicher, dass Sie über die erforderlichen Zertifikate verfügen, bevor Sie Dateien in Ihrem NGINX Plus SP konfigurieren:

• Zertifikate zum Beenden der TLS-Sitzung ( dev.sports.com.crt und dev.sports.com.key )
• Von Microsoft Entra ID heruntergeladenes Zertifikat zur IdP-Signaturüberprüfung ( demonginx.cer )

Notiz : Die Zertifikate müssen im SPKI-Format vorliegen.

Laden Sie zum Starten dieses Schritts das IdP-Zertifikat von Microsoft Entra ID zur Signaturüberprüfung herunter. Konvertieren Sie dann PEM in das DER-Format:

Falls Sie SAML SP-Assertionen überprüfen möchten, wird empfohlen, andere öffentliche/private Schlüssel zu verwenden als die, die für die TLS-Terminierung verwendet werden.

Extrahieren Sie das öffentliche Schlüsselzertifikat im SPKI-Format:

Bearbeiten Sie die Datei frontend.conf, um diese Elemente zu aktualisieren:

• ssl_certificate – Update, um den TLS-Zertifikatspfad einzuschließen.
• ssl_certificate_key – Update, um den privaten TLS-Schlüsselpfad einzuschließen.

Bei der Produktionsbereitstellung können Sie je nach Geschäftsanforderung unterschiedliche Back-End-Ziele verwenden. In diesem Beispiel liefert das Backend eine angepasste Antwort:

Wir haben die Attribute und Ansprüche in Microsoft Entra ID geändert, indem wir neue Ansprüche für die E-Mail und Objekt-ID des Benutzers hinzugefügt haben. Diese Aktualisierungen ermöglichen Ihnen eine persönlichere und maßgeschneiderte Antwort auf Ihre Bewerbung, was zu einem verbesserten Benutzererlebnis führt.

Abbildung 7: Geänderte Attribute und Ansprüche in Microsoft Entra ID

Der nächste Schritt besteht darin, NGINX zu konfigurieren, das den Datenverkehr an die Backend-Anwendung weiterleitet. In dieser Demo ist die SAML-Backend-Anwendung öffentlich unter https://dev.sports.com verfügbar.

Bearbeiten Sie Ihre Datei frontend.conf :

# Dies ist die Datei frontend.conf 
# Dies ist die Backend-Anwendung, die wir mit SAML SSO schützen 
upstream my_backend { 
zone my_backend 64k; 
server dev.sports.com; 
} 

# Benutzerdefiniertes Protokollformat, um das Thema „NameID“ in das Feld REMOTE_USER aufzunehmen 
log_format saml_sso '$remote_addr - $saml_name_id [$time_local] "$request" "$host" ' 
'$status $body_bytes_sent "$http_referer" ' 
'"$http_user_agent" "$http_x_forwarded_for"'; 

# Der Frontend-Server – Reverse-Proxy mit SAML SSO-Authentifizierung 
# 
server { 
# Funktionale Standorte, die SAML SSO-Unterstützung implementieren 
include conf.d/saml_sp.server_conf; 

# Schweregrad nach Bedarf reduzieren 
error_log /var/log/nginx/error.log debug; 
listen 443 ssl; 
ssl_certificate /home/ubuntu/dev.sports.com.crt; 
ssl_certificate_key /home/ubuntu/dev.sports.com.key; 
ssl_session_cache shared:SSL:5m; 

location / { 
# Wenn ein Benutzer nicht authentifiziert ist (d. h. die Variable „saml_access_granted.“ 
# ist nicht auf „1“ gesetzt), wird ein HTTP 401 Unauthorized-Fehler 
# zurückgegeben, der vom benannten Standort @do_samlsp_flow behandelt wird. 
error_page 401 = @do_samlsp_flow; 

if ($saml_access_granted != „1“) { 
return 401; 
} 

# Erfolgreich authentifizierte Benutzer werden per Proxy an das Backend weitergeleitet, 
# wobei das NameID-Attribut als HTTP-Header übergeben wird 
proxy_set_header mail $saml_attrib_mail; # user.mail der Microsoft Entra-ID 
proxy_set_header objectid $saml_attrib_objectid; # objectid der Microsoft Entra-ID 
access_log /var/log/nginx/access.log saml_sso; 
proxy_pass http://my_backend; 
proxy_set_header Host dev.sports.com; 
return 200 „Willkommen auf der Anwendungsseite\n Meine Objectid ist $http_objectid\n Meine E-Mail ist $http_mail\n“; 
default_type text/plain; 

} 
} 
# vim: syntax=nginx         

Damit die Attribute saml_attrib_mail und saml_attrib_objectid in NGINX-Konfigurationen berücksichtigt werden, aktualisieren Sie den Schlüssel-Wert-Speicherteil von saml_sp_configuration.conf wie folgt:

keyval_zone zone=saml_attrib_mail:1M status=/var/lib/nginx/state/saml_attrib_email.json timeout=1h; 
keyval $cookie_auth_token $saml_attrib_mail zone=saml_attrib_mail; 

keyval_zone zone=saml_attrib_objectid:1M status=/var/lib/nginx/state/saml_attrib_objectid.json timeout=1h; 
keyval $cookie_auth_token $saml_attrib_objectid zone=saml_attrib_objectid; 

Konfigurieren Sie als Nächstes die SAML SSO-Konfigurationsdatei. Diese Datei enthält die primären Konfigurationen für SP und IdP. Um es entsprechend Ihrem spezifischen SP- und IdP-Setup anzupassen, müssen Sie die mehreren in der Datei enthaltenen Map{}-Blöcke anpassen.

Diese Tabelle enthält Beschreibungen der Variablen in saml_sp_configuration.conf :

Der folgende Code zeigt die bearbeiteten Werte nur für diesen Anwendungsfall in saml_sp_configuration.conf.

Notiz : Stellen Sie sicher, dass die restlichen Teile der Konfigurationsdatei weiterhin in der Datei enthalten sind (z. B. die Schlüssel-Wert-Speicher). Stellen Sie außerdem sicher, dass Sie die Variablen in der Datei saml_sp_configuration.conf basierend auf Ihrer Bereitstellung richtig anpassen.

 # SAML SSO-Konfiguration 

map $host $saml_sp_entity_id { 
# Eindeutige Kennung, die den SP gegenüber dem IdP identifiziert. 
# Muss eine URL oder URN sein. 
default "https://dev.sports.com"; 
} 

map $host $saml_sp_acs_url { 
# Die ACS-URL, ein Endpunkt auf dem SP, zu dem der IdP 
# mit seiner Authentifizierungsantwort umleitet. 
# Muss mit dem ACS-Standort übereinstimmen, der in der Datei "saml_sp.serer_conf" definiert ist. 
default "https://dev.sports.com/saml/acs"; 
} 

map $host $saml_sp_request_binding { 
# Bezieht sich auf die Methode, mit der eine Authentifizierungsanforderung während des Single Sign-On (SSO)-Prozesses vom 
# SP an einen IdP gesendet wird. 
# Nur HTTP-POST- oder HTTP-Redirect-Methoden sind zulässig. 
Standard „HTTP-POST“; 
} 

map $host $saml_sp_sign_authn { 
# Ob der SP die an den IdP gesendete AuthnRequest signieren soll. 
Standard „false“; 
} 

map $host $saml_sp_decryption_key { 
# Gibt den privaten Schlüssel an, den der SP verwendet, um die verschlüsselte Assertion 
# oder NameID vom IdP zu entschlüsseln. 
Standard „“; 
} 

map $host $saml_sp_force_authn { 
# Ob der SP eine erneute Authentifizierung des Benutzers durch den IdP erzwingen soll. 
Standard „false“; 
} 

map $host $saml_sp_nameid_format { 
# Gibt das gewünschte Format des Namensbezeichners in der vom IdP generierten SAML-Assertion 
# an. Überprüfen Sie Abschnitt 8.3 der SAML 2.0 Core-Spezifikation 
# (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) 
# für die Liste der zulässigen NameID-Formate. 
default "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"; 
} 

map $host $saml_sp_relay_state { 
# Relative oder absolute URL, zu der der SP umleiten soll 
# nach erfolgreicher Anmeldung. 
default ""; 
} 

map $host $saml_sp_want_signed_response { 
# Ob der SP möchte, dass die SAML-Antwort vom IdP 
# digital signiert wird. 
default "false"; 
} 

map $host $saml_sp_want_signed_assertion { 
# Ob der SP möchte, dass die SAML-Assertion vom IdP 
# digital signiert wird. 
default "true"; 
} 

map $host $saml_sp_want_encrypted_assertion { 
# Ob der SP möchte, dass die SAML-Assertion vom IdP 
# verschlüsselt wird. 
default "false"; 
} 

map $host $saml_idp_entity_id { 
# Eindeutige Kennung, die den IdP für den SP identifiziert. 
# Muss URL oder URN sein. 
default "https://sts.windows.net/8807dced-9637-4205-a520-423077750c60/"; 
} 

map $host $saml_idp_sso_url { 
# IdP-Endpunkt, an den der SP die SAML AuthnRequest sendet, um 
# einen Authentifizierungsprozess zu initiieren. 
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_idp_verification_certificate { 
# Zertifikatsdatei, die verwendet wird, um die digitale Signatur 
# auf der vom IdP empfangenen SAML-Antwort, LogoutRequest oder LogoutResponse zu verifizieren. 
# Muss ein öffentlicher Schlüssel im PKCS#1-Format sein. Informationen zum Konvertieren von 
# X.509 PEM in das DER-Format finden Sie in der Dokumentation. 
default "/etc/nginx/conf.d/demonginx.spki"; 
} 

######### Single Logout (SLO) ######### 

map $host $saml_sp_slo_url { 
# SP-Endpunkt, an den der IdP die SAML LogoutRequest sendet, um 
# einen Abmeldevorgang zu initiieren, oder LogoutResponse, um die Abmeldung zu bestätigen. 
default "https://dev.sports.com/saml/sls"; 
} 

map $host $saml_sp_slo_binding { 
# Bezieht sich auf die Methode, mit der eine LogoutRequest oder LogoutResponse 
# während des Single Logout (SLO)-Prozesses vom SP an einen IdP gesendet wird. 
# Es sind nur HTTP-POST- oder HTTP-Redirect-Methoden zulässig. 
default 'HTTP-POST'; 
} 

map $host $saml_sp_sign_slo { 
# Ob der SP die LogoutRequest oder LogoutResponse signieren muss, 
# die an den IdP gesendet werden. 
default "false"; 
} 

map $host $saml_idp_slo_url { 
# IdP-Endpunkt, an den der SP die LogoutRequest sendet, um 
# einen Abmeldevorgang zu initiieren, oder LogoutResponse, um die Abmeldung zu bestätigen. 
# Wenn nicht festgelegt, ist die SAML Single Logout (SLO)-Funktion DEAKTIVIERT und 
# Anfragen an den „Logout“-Standort führen zur Beendigung 
# der Benutzersitzung und einer Umleitung zur Abmelde-Zielseite. 
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_sp_want_signed_slo { 
# Ob der SP möchte, dass die SAML LogoutRequest oder LogoutResponse vom IdP 
# digital signiert wird. 
default "true"; 
} 

map $host $saml_logout_landing_page { 
# Wohin der Benutzer nach der Anforderung des /logout-Standorts umgeleitet werden soll. Dies kann 
# durch eine benutzerdefinierte Abmeldeseite oder eine vollständige URL ersetzt werden. 
default "/_logout"; # Integrierte, einfache Abmeldeseite 
} 

map $proto $saml_cookie_flags { 
http "Path=/; SameSite=lax;"; # Für HTTP/Klartext-Tests 
https "Path=/; SameSite=lax; HttpOnly; Secure;"; # Produktionsempfehlung 
} 

map $http_x_forwarded_port $redirect_base { 
"" $proto://$host:$server_port; 
default $proto://$host:$http_x_forwarded_port; 
} 

map $http_x_forwarded_proto $proto { 
"" $scheme; 
default $http_x_forwarded_proto; 
} 
# ERWEITERTE KONFIGURATION UNTER DIESER ZEILE 
# Zusätzliche erweiterte Konfiguration (Serverkontext) in saml_sp.server_conf 

######### Gemeinsam genutzte Speicherzonen, in denen die SAML-bezogenen Schlüsselwertdatenbanken gespeichert werden 

# Zone zum Speichern der AuthnRequest- und LogoutRequest-Nachrichtenkennungen (ID) 
# um Replay-Angriffe zu verhindern. (ERFORDERLICH) 
# Timeout bestimmt, wie lange der SP auf eine Antwort vom IDP wartet, 
# d. h. wie lange der Benutzerauthentifizierungsprozess dauern kann. 
keyval_zone zone=saml_request_id:1M state=/var/lib/nginx/state/saml_request_id.json timeout=5m; 

# Zone zum Speichern von SAML-Antwortnachrichtenkennungen (ID), um Replay-Angriffe zu verhindern. (ERFORDERLICH) 
# Timeout bestimmt, wie lange der SP IDs behält, um eine Wiederverwendung zu verhindern. 
keyval_zone zone=saml_response_id:1M state=/var/lib/nginx/state/saml_response_id.json timeout=1h; 

# Zone zum Speichern von SAML-Sitzungszugriffsinformationen. (ERFORDERLICH) 
# Timeout bestimmt, wie lange der SP die Entscheidung zum Sitzungszugriff behält (die Sitzungslebensdauer). 
keyval_zone zone=saml_session_access:1M state=/var/lib/nginx/state/saml_session_access.json timeout=1h; 

# Zone zum Speichern von SAML-NameID-Werten. (ERFORDERLICH) 
# Timeout bestimmt, wie lange der SP NameID-Werte speichert. Muss der Sitzungslebensdauer entsprechen. 
keyval_zone zone=saml_name_id:1M state=/var/lib/nginx/state/saml_name_id.json timeout=1h; 

# Zone zum Speichern von Werten im SAML-NameID-Format. (ERFORDERLICH) 
# Timeout bestimmt, wie lange der SP NameID-Formatwerte behält. Muss der Sitzungslebensdauer entsprechen. 
keyval_zone zone=saml_name_id_format:1M state=/var/lib/nginx/state/saml_name_id_format.json timeout=1h; 

# Zone zum Speichern von SAML-SessionIndex-Werten. (ERFORDERLICH) 
# Timeout bestimmt, wie lange der SP SessionIndex-Werte speichert. Muss der Sitzungslebensdauer entsprechen. 
keyval_zone zone=saml_session_index:1M state=/var/lib/nginx/state/saml_session_index.json timeout=1h; 

# Zone zum Speichern von SAML AuthnContextClassRef-Werten. (ERFORDERLICH) 
# Timeout bestimmt, wie lange der SP AuthnContextClassRef-Werte behält. Muss der Sitzungslebensdauer entsprechen. 
keyval_zone zone=saml_authn_context_class_ref:1M state=/var/lib/nginx/state/saml_authn_context_class_ref.json timeout=1h; 

# Zonen zum Speichern von SAML-Attributwerten. (OPTIONAL) 
# Timeout bestimmt, wie lange der SP Attributwerte speichert. Muss der Sitzungslebensdauer entsprechen. 
keyval_zone zone=saml_attrib_uid:1M state=/var/lib/nginx/state/saml_attrib_uid.json timeout=1h; 
keyval_zone zone=saml_attrib_name:1M state=/var/lib/nginx/state/saml_attrib_name.json timeout=1h; 
keyval_zone zone=saml_attrib_memberOf:1M state=/var/lib/nginx/state/saml_attrib_memberOf.json timeout=1h; 

########## SAML-bezogene Variablen, deren Wert vom Schlüssel (Sitzungscookie) in der Schlüssel-Wert-Datenbank gesucht wird. 

# Erforderlich: 
keyval $saml_request_id $saml_request_redeemed zone=saml_request_id; # SAML-Anforderungs-ID 
keyval $saml_response_id $saml_response_redeemed zone=saml_response_id; # SAML-Antwort-ID 
keyval $cookie_auth_token $saml_access_granted zone=saml_session_access; # SAML-Zugriffsentscheidung 
keyval $cookie_auth_token $saml_name_id zone=saml_name_id; # SAML-Namens-ID 
keyval $cookie_auth_token $saml_name_id_format zone=saml_name_id_format; # SAML-Namens-ID-Format 
keyval $cookie_auth_token $saml_session_index zone=saml_session_index; # SAML-Sitzungsindex 
keyval $cookie_auth_token $saml_authn_context_class_ref zone=saml_authn_context_class_ref; # SAML AuthnContextClassRef 

# Optional: 
keyval $cookie_auth_token $saml_attrib_uid zone=saml_attrib_uid; 
keyval $cookie_auth_token $saml_attrib_name zone=saml_attrib_name; 
keyval $cookie_auth_token $saml_attrib_memberOf zone=saml_attrib_memberOf; 

keyval_zone zone=saml_attrib_mail:1M state=/var/lib/nginx/state/saml_attrib_mail.json timeout=1h; 
keyval $cookie_auth_token $saml_attrib_mail zone=saml_attrib_mail; 

keyval $cookie_auth_token $saml_attrib_objectid zone=saml_attrib_objectid; 
keyval_zone zone=saml_attrib_objectid:1M state=/var/lib/nginx/state/saml_attrib_objectid.json timeout=1h; 

########## Importiert ein Modul, das SAML SSO- und SLO-Funktionalität implementiert 
js_import samlsp from conf.d/saml_sp.js; 

Schritt 3: Testen der Konfiguration

Zum Testen der Konfiguration sind zwei Teile erforderlich:

1. Überprüfen des SAML-Flusses
2. Testen der SP-initiierten Abmeldefunktion

Überprüfen des SAML-Flusses

Nachdem Sie den SAML SP mit NGINX Plus und den IdP mit Microsoft Entra ID konfiguriert haben, muss unbedingt der SAML-Fluss validiert werden. Dieser Validierungsprozess stellt sicher, dass die Benutzerauthentifizierung durch den IdP erfolgreich ist und der Zugriff auf SP-geschützte Ressourcen gewährt wird.

Um den vom SP initiierten SAML-Fluss zu überprüfen, öffnen Sie Ihren bevorzugten Browser und geben Sie https://dev.sports.com in die Adressleiste ein. Sie werden zur IdP-Anmeldeseite weitergeleitet.

Abbildung 8: Die IdP-Anmeldeseite

Geben Sie die Anmeldeinformationen eines Benutzers ein, der auf der Anmeldeseite des IdP konfiguriert ist. Der IdP authentifiziert den Benutzer beim Absenden.

Abbildung 9: Eingabe der Anmeldeinformationen des konfigurierten Benutzers

Nach erfolgreichem Sitzungsaufbau wird dem Benutzer Zugriff auf die zuvor angeforderte geschützte Ressource gewährt. Anschließend wird diese Ressource im Browser des Benutzers angezeigt.

Abbildung 10: Die erfolgreich geladene Anwendungsseite

Wertvolle Informationen zum SAML-Fluss können durch Überprüfen der SP- und IdP-Protokolle erhalten werden. Stellen Sie auf der SP-Seite (NGINX Plus) sicher, dass die Auth_token-Cookies richtig gesetzt sind. Stellen Sie auf der IdP-Seite (Microsoft Entra ID) sicher, dass der Authentifizierungsprozess ohne Fehler abgeschlossen wird und die SAML-Assertion an den SP gesendet wird.

Das NGINX access.log sollte folgendermaßen aussehen:

127.0.0.1 - - [14.08.2023:21:25:49 +0000] "GET / HTTP/1.0" 200 127 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, wie Gecko) Version/16.1 Safari/605.1.15" "-" 

99.187.244.63 - Akash Ananthanarayanan [14.08.2023:21:25:49 +0000] "GET / HTTP/1.1" "dev.sports.com" 200 127 "https://login.microsoftonline.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, wie Gecko) Version/16.1 Safari/605.1.15" "- 

Während das NGINX- Debug.log folgendermaßen aussieht:

14.08.2023 21:25:49 [info] 27513#27513: *399 js: SAML SP erfolgreich, Sitzung wird erstellt _d4db9b93c415ee7b4e057a4bb195df6cd0be7e4d 

Testen der SP-initiierten Abmeldefunktion

Mit SAML Single Logout (SLO) können sich Benutzer mit einer Aktion von allen beteiligten IdPs und SPs abmelden. NGINX Plus unterstützt SP- und IdP-initiierte Abmeldeszenarien und verbessert so die Sicherheit und das Benutzererlebnis in SSO-Umgebungen. In diesem Beispiel verwenden wir ein SP-initiiertes Abmeldeszenario.

Abbildung 11: SAML SP-initiiertes SLO mit POST/Redirect-Bindungen für LogoutRequest und LogoutResponse

Melden Sie sich nach der Authentifizierung Ihrer Sitzung ab, indem Sie auf die in Ihrem SP konfigurierte Abmelde-URL zugreifen. Wenn Sie beispielsweise https://dev.sports.com/logout als Abmelde-URL in NGINX Plus eingerichtet haben, geben Sie diese URL in die Adressleiste Ihres Browsers ein.

Abbildung 12: Erfolgreiche Abmeldung von der Sitzung

Um eine sichere Abmeldung zu gewährleisten, muss der SP eine SAML-Anfrage initiieren, die dann vom IdP überprüft und verarbeitet wird. Durch diese Aktion wird die Benutzersitzung effektiv beendet und der IdP sendet dann eine SAML-Antwort, um den Browser des Benutzers zurück zum SP umzuleiten.

Abschluss

Glückwunsch! NGINX Plus kann jetzt als SAML SP dienen und dem Authentifizierungsprozess eine weitere Sicherheitsebene und mehr Komfort bieten. Diese neue Funktion stellt einen bedeutenden Fortschritt für NGINX Plus dar und macht es zu einer robusteren und vielseitigeren Lösung für Unternehmen, bei denen Sicherheit und Effizienz im Vordergrund stehen. 

Erfahren Sie mehr über die Verwendung von SAML mit NGINX Plus

Sie können noch heute mit der Verwendung von SAML mit NGINX Plus beginnen, indem Sie eine 30-tägige kostenlose Testversion von NGINX Plus starten. Wir hoffen, Sie finden es nützlich und freuen uns über Ihr Feedback.

Weitere Informationen zu NGINX Plus mit SAML finden Sie in den folgenden Ressourcen.

• Ankündigung von NGINX Plus R29
• SAML-Unterstützung in NGINX Plus als Referenzimplementierung auf GitHub