NGINX Plus für SAML-SSO mit Microsoft Entra ID konfigurieren

NGINX | 31. Oktober 2023

Akash AnanthanarayananManager für technisches Marketing | F5 NGINX

Zur Erhöhung der Sicherheit und Verbesserung der Benutzerfreundlichkeit unterstützt F5 NGINX Plus (ab R29) jetzt die Security Assertion Markup Language (SAML). SAML ist ein bewährtes Protokoll, das Single Sign-on (SSO) für Webanwendungen ermöglicht. Dabei authentifiziert ein Identitätsanbieter (IdP) Benutzer für den Zugriff auf eine Ressource und übermittelt diese Informationen anschließend zur Autorisierung an einen Dienstanbieter (SP).

In diesem Blogbeitrag zeigen wir Ihnen Schritt für Schritt, wie Sie NGINX mithilfe einer Webanwendung, die SAML nicht nativ unterstützt, in Microsoft Entra ID, ehemals Azure Active Directory (Azure AD), integrieren. Außerdem erläutern wir, wie Sie SSO für die Anwendung implementieren und sie in das Microsoft Entra ID-Ökosystem integrieren. Im Rahmen des Tutorials erfahren Sie darüber hinaus, wie NGINX Ansprüche aus einer SAML-Assertion extrahieren kann (darunter UPN, Vorname, Nachname und Gruppenmitgliedschaften) und diese anschließend über HTTP-Header an die Anwendung weitergibt.

Das Tutorial umfasst drei Schritte:

Microsoft Entra ID als IdP konfigurieren
Konfigurieren der SAML-Einstellungen und von NGINX Plus als Reverse-Proxy
Testen der Konfiguration

Um dieses Tutorial abzuschließen, benötigen Sie:

NGINX Plus (R29+), das Sie 30 Tage lang kostenlos testen können
Ein kostenloses Microsoft Entra ID-Konto oder ein Unternehmenskonto
Ein gültiges SSL/TLS-Zertifikat, das auf dem NGINX Plus-Server installiert ist (in diesem Tutorial werden dev.sports.com.crt und dev.sports.com.key verwendet)
Zur Überprüfung der SAML-Assertions kann das öffentliche Zertifikat demonginx.cer vom IdP heruntergeladen werden.

Hinweis: Dieses Tutorial gilt nicht für Bereitstellungen von NGINX Open Source, da der Schlüssel-Wert-Speicher ausschließlich in NGINX Plus verfügbar ist.

NGINX Plus als SAML-Dienstanbieter verwenden

In dieser Konfiguration fungiert NGINX Plus als SAML-SP und kann an einer SSO-Implementierung mit einem SAML-IdP teilnehmen, der über den Benutzeragenten indirekt mit NGINX Plus kommuniziert.

Das folgende Diagramm veranschaulicht den Ablauf des SSO-Prozesses mit SP-Initiierung und POST-Bindings für Anfrage und Antwort. Es ist nochmals ausdrücklich darauf hinzuweisen, dass dieser Kommunikationskanal nicht direkt ist, sondern über den User Agent verwaltet wird.

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

Schritt 1: Microsoft Entra ID als Identitätsanbieter konfigurieren

Um auf Ihr Microsoft Entra ID-Verwaltungsportal zuzugreifen, melden Sie sich an und navigieren Sie zum linken Bereich. Wählen Sie Microsoft Entra ID aus und klicken Sie anschließend auf den Namen des Verzeichnisses, für das SSO konfiguriert werden soll. Wählen Sie danach Unternehmensanwendungen aus.

Abbildung 2: Auswählen von „Unternehmensanwendungen“ 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 weitergeleitet wurden, öffnen Sie deren Übersicht, navigieren Sie über das linke Menü zu Erste Schritte und klicken Sie unter Einmaliges Anmelden im Bereich Verwalten auf die entsprechende Option. Wählen Sie anschließend SAML als Methode für einmaliges Anmelden aus.

Abbildung 4: Starten der SAML-Konfiguration über den SSO-Bereich

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

Fügen Sie die folgenden Werte hinzu und klicken Sie anschließend auf „Speichern“:

Bezeichner (Entitäts-ID) – https://dev.sports.com
Antwort-URL (URL des Assertion Consumer Service) – 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. Wenn Sie diese Einstellung aktivieren, müssen zwei Konfigurationsoptionen in NGINX berücksichtigt werden:

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.
Geben Sie den Pfad zum privaten Schlüssel an, der für diese Signatur verwendet werden soll, indem Sie $saml_sp_signing_key konfigurieren. Laden Sie unbedingt das zugehörige Zertifikat des öffentlichen Schlüssels zur Signaturprüfung in Microsoft Entra ID hoch.

Hinweis: 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. Die entsprechenden Einstellungen können Sie im NGINX-GitHub-Repository überprüfen und anpassen.

Laden Sie das IdP-Zertifikat (Rohformat) aus Microsoft Entra ID herunter und speichern Sie es auf Ihrer NGINX Plus-Instanz.

Abbildung 5: Herunterladen des IdP-Zertifikats (Rohformat) aus Microsoft Entra ID

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

In Microsoft Entra ID können Sie Benutzern und Gruppen Zugriff auf die SSO-fähigen Anwendungen Ihres Unternehmens gewähren, indem Sie sie hinzufügen oder zuweisen.

Klicken Sie im Menü auf der linken Seite auf „Benutzer und Gruppen“ und anschließend oben auf die Schaltfläche „Benutzer/Gruppe hinzufügen“.

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

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 Überprüfung der IdP-Signatur (demonginx.cer)

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

Laden Sie zu Beginn dieses Schritts das IdP-Zertifikat zur Signaturprüfung aus Microsoft Entra ID herunter. Konvertieren Sie anschließend das PEM-Format in das DER-Format:

openssl x509 -in demonginx.cer -outform DER -out demonginx.der

Wenn Sie SAML-SP-Assertions überprüfen möchten, empfiehlt es sich, andere öffentliche/private Schlüssel als für die TLS-Terminierung zu verwenden.

Extrahieren Sie das Public-Key-Zertifikat im SPKI-Format:

openssl x509 -inform DER -in demonginx.der -pubkey -noout > demonginx.spki

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

ssl_certificate – Aktualisieren Sie den Eintrag, sodass er den Pfad zum TLS-Zertifikat enthält.
ssl_certificate_key – Aktualisieren Sie den Eintrag, sodass er den Pfad zum privaten TLS-Schlüssel enthält.

In einer Produktionsumgebung können Sie je nach Geschäftsanforderung unterschiedliche Backend-Ziele verwenden. In diesem Beispiel liefert das Backend eine benutzerdefinierte Antwort:

„Willkommen auf der Anwendungsseite. Meine Objekt-ID ist $http_objectidn. Meine E-Mail-Adresse ist $http_mailn“;

Wir haben die Attribute und Ansprüche in Microsoft Entra ID geändert, indem wir neue Ansprüche für die Benutzerattribute mail und objectid hinzugefügt haben. Mit diesen Aktualisierungen können Sie die Antwort Ihrer Anwendung stärker personalisieren und individuell anpassen und so die Benutzerfreundlichkeit verbessern.

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

Im nächsten Schritt wird NGINX so konfiguriert, dass der Datenverkehr an die Backend-Anwendung weitergeleitet wird. In dieser Demo ist die SAML-Backend-Anwendung öffentlich unter https://dev.sports.com erreichbar.

Bearbeiten Sie Ihre Datei „frontend.conf“:

# This is file frontend.conf 
# This is the backend application we are protecting with SAML SSO 
upstream my_backend { 
    zone my_backend 64k; 
    server dev.sports.com; 
} 

# Custom log format to include the 'NameID' subject in the REMOTE_USER field 
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"'; 

# The frontend server - reverse proxy with SAML SSO authentication 
# 
server { 
    # Functional locations implementing SAML SSO support 
    include conf.d/saml_sp.server_conf; 
 

    # Reduce severity level as required 
    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 / { 
        # When a user is not authenticated (i.e., the "saml_access_granted." 
        # variable is not set to "1"), an HTTP 401 Unauthorized error is 
        # returned, which is handled by the @do_samlsp_flow named location. 
        error_page 401 = @do_samlsp_flow; 

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

        # Successfully authenticated users are proxied to the backend, 
        # with the NameID attribute passed as an HTTP header        
        proxy_set_header mail $saml_attrib_mail;  # Microsoft Entra ID's user.mail 
        proxy_set_header objectid $saml_attrib_objectid; # Microsoft Entra ID's objectid 
        access_log /var/log/nginx/access.log saml_sso; 
        proxy_pass http://my_backend; 
        proxy_set_header Host dev.sports.com; 
        return 200 "Welcome to Application pagen My objectid is $http_objectidn My email is $http_mailn"; 
        default_type text/plain; 

   } 
} 
# vim: syntax=nginx

Damit die Attribute „saml_attrib_mail“ und „saml_attrib_ objectid“ in den NGINX-Konfigurationen berücksichtigt werden, aktualisieren Sie den Schlüssel-Wert-Speicher in „saml_sp_configuration.conf“ wie folgt:

keyval_zone    zone=saml_attrib_mail:1M                state=/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            state=/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 wichtigsten Konfigurationseinstellungen für den SP und den IdP. Um sie an Ihre spezifische SP- und IdP-Konfiguration anzupassen, müssen Sie die verschiedenen in der Datei enthaltenen map{}-Blöcke ändern.

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

Variable	Beschreibung
`saml_sp_entity_id`	Die URL, über die Benutzer auf die Anwendung zugreifen.
`saml_sp_acs_url`	Die URL, über die der Dienstanbieter die SAML-Antwort empfängt und verarbeitet, die Identität des Benutzers ermittelt und anschließend anhand der bereitgestellten Informationen den Zugriff auf die angeforderte Ressource gewährt oder verweigert.
`saml_sp_sign_authn`	Gibt an, ob die SAML-Anfrage vom SP an den IdP signiert werden soll. Die Signatur wird mit dem Signaturschlüssel des SP erstellt. Das zugehörige Zertifikat muss zur Überprüfung der Signatur auf den IdP hochgeladen werden.
`saml_sp_signing_key`	Der Signaturschlüssel, mit dem die SAML-Anfrage vom SP an den IdP signiert wird. Laden Sie das zugehörige Zertifikat zur Überprüfung der Signatur auf den IdP hoch.
`saml_idp_entity_id`	Die Identität, über die der IdP definiert wird.
`saml_idp_sso_url`	Der IdP-Endpunkt, an den der SP die SAML-Assertion-Anfrage sendet, um die Authentifizierungsanfrage einzuleiten.
`saml_idp_verification_certificate`	Das Zertifikat, mit dem vom IdP empfangene signierte SAML-Assertions überprüft werden. Das Zertifikat wird vom IdP bereitgestellt und muss im SPKI-Format vorliegen.
`saml_sp_slo_url`	Der SP-Endpunkt, an den der IdP die SAML-LogoutRequest (beim Einleiten eines Abmeldevorgangs) oder die LogoutResponse (beim Bestätigen der Abmeldung) sendet.
`saml_sp_sign_slo`	Gibt an, ob die SAML-Abmeldenachricht vom SP signiert werden soll.
`saml_idp_slo_url`	Der IdP-Endpunkt, an den der SP die LogoutRequest (beim Einleiten eines Abmeldevorgangs) oder die LogoutResponse (beim Bestätigen der Abmeldung) sendet.
`saml_sp_want_signed_slo`	Gibt an, ob der SAML-SP verlangt, dass die SAML-Abmeldeantwort oder -anfrage vom IdP signiert wird.

Der folgende Code zeigt nur die für diesen Anwendungsfall geänderten Werte in der Datei saml_sp_configuration.conf.

Hinweis: Stellen Sie sicher, dass die übrigen 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 entsprechend Ihrer Bereitstellung anpassen.

 # SAML SSO configuration 

map $host $saml_sp_entity_id { 
    # Unique identifier that identifies the SP to the IdP. 
    # Must be URL or URN. 
    default "https://dev.sports.com"; 
} 

map $host $saml_sp_acs_url { 
    # The ACS URL, an endpoint on the SP where the IdP  
    # will redirect to with its authentication response. 
    # Must match the ACS location defined in the "saml_sp.serer_conf" file. 
    default "https://dev.sports.com/saml/acs"; 
} 

map $host $saml_sp_request_binding { 
    # Refers to the method by which an authentication request is sent from 
    # the SP to an IdP during the Single Sign-On (SSO) process. 
    # Only HTTP-POST or HTTP-Redirect methods are allowed. 
    default 'HTTP-POST'; 
} 

map $host $saml_sp_sign_authn { 
    # Whether the SP should sign the AuthnRequest sent to the IdP. 
    default "false"; 
} 

map $host $saml_sp_decryption_key { 
    # Specifies the private key that the SP uses to decrypt encrypted assertion 
    # or NameID from the IdP. 
    default ""; 
} 

map $host $saml_sp_force_authn { 
    # Whether the SP should force re-authentication of the user by the IdP. 
    default "false"; 
} 

map $host $saml_sp_nameid_format { 
    # Indicates the desired format of the name identifier in the SAML assertion 
    # generated by the IdP. Check section 8.3 of the SAML 2.0 Core specification 
    # (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) 
    # for the list of allowed NameID Formats. 
    default "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"; 
} 

map $host $saml_sp_relay_state { 
    # Relative or absolute URL the SP should redirect to 
    # after successful sign on. 
    default ""; 
} 

map $host $saml_sp_want_signed_response { 
    # Whether the SP wants the SAML Response from the IdP 
    # to be digitally signed. 
    default "false"; 
} 

map $host $saml_sp_want_signed_assertion { 
    # Whether the SP wants the SAML Assertion from the IdP 
    # to be digitally signed. 
    default "true"; 
} 

map $host $saml_sp_want_encrypted_assertion { 
    # Whether the SP wants the SAML Assertion from the IdP 
    # to be encrypted. 
    default "false"; 
} 

map $host $saml_idp_entity_id { 
    # Unique identifier that identifies the IdP to the SP. 
    # Must be URL or URN. 
    default "https://sts.windows.net/8807dced-9637-4205-a520-423077750c60/"; 
} 

map $host $saml_idp_sso_url { 
    # IdP endpoint that the SP will send the SAML AuthnRequest to initiate 
    # an authentication process. 
    default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_idp_verification_certificate { 
    # Certificate file that will be used to verify the digital signature 
    # on the SAML Response, LogoutRequest or LogoutResponse received from IdP. 
    # Must be public key in PKCS#1 format. See documentation on how to convert 
    # X.509 PEM to DER format. 
    default "/etc/nginx/conf.d/demonginx.spki"; 
} 

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

map $host $saml_sp_slo_url { 
    # SP endpoint that the IdP will send the SAML LogoutRequest to initiate 
    # a logout process or LogoutResponse to confirm the logout. 
    default "https://dev.sports.com/saml/sls"; 
} 

map $host $saml_sp_slo_binding { 
    # Refers to the method by which a LogoutRequest or LogoutResponse 
    # is sent from the SP to an IdP during the Single Logout (SLO) process. 
    # Only HTTP-POST or HTTP-Redirect methods are allowed. 
    default 'HTTP-POST'; 
} 

map $host $saml_sp_sign_slo { 
    # Whether the SP must sign the LogoutRequest or LogoutResponse 
    # sent to the IdP. 
    default "false"; 
} 

map $host $saml_idp_slo_url { 
    # IdP endpoint that the SP will send the LogoutRequest to initiate 
    # a logout process or LogoutResponse to confirm the logout. 
    # If not set, the SAML Single Logout (SLO) feature is DISABLED and 
    # requests to the 'logout' location will result in the termination 
    # of the user session and a redirect to the logout landing page. 
    default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_sp_want_signed_slo { 
    # Whether the SP wants the SAML LogoutRequest or LogoutResponse from the IdP 
    # to be digitally signed. 
    default "true"; 
} 

map $host $saml_logout_landing_page { 
    # Where to redirect user after requesting /logout location. This can be 
    # replaced with a custom logout page, or complete URL. 
    default "/_logout"; # Built-in, simple logout page 
} 

map $proto $saml_cookie_flags { 
    http  "Path=/; SameSite=lax;"; # For HTTP/plaintext testing 
    https "Path=/; SameSite=lax; HttpOnly; Secure;"; # Production recommendation 
} 

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; 
} 
# ADVANCED CONFIGURATION BELOW THIS LINE 
# Additional advanced configuration (server context) in saml_sp.server_conf 

######### Shared memory zones that keep the SAML-related key-value databases 

# Zone for storing AuthnRequest and LogoutRequest message identifiers (ID) 
# to prevent replay attacks. (REQUIRED) 
# Timeout determines how long the SP waits for a response from the IDP, 
# i.e. how long the user authentication process can take. 
keyval_zone zone=saml_request_id:1M                 state=/var/lib/nginx/state/saml_request_id.json                  timeout=5m; 

# Zone for storing SAML Response message identifiers (ID) to prevent replay attacks. (REQUIRED) 
# Timeout determines how long the SP keeps IDs to prevent reuse. 
keyval_zone zone=saml_response_id:1M                state=/var/lib/nginx/state/saml_response_id.json                 timeout=1h; 

# Zone for storing SAML session access information. (REQUIRED) 
# Timeout determines how long the SP keeps session access decision (the session lifetime). 
keyval_zone zone=saml_session_access:1M             state=/var/lib/nginx/state/saml_session_access.json              timeout=1h; 

# Zone for storing SAML NameID values. (REQUIRED) 
# Timeout determines how long the SP keeps NameID values. Must be equal to session lifetime. 
keyval_zone zone=saml_name_id:1M                    state=/var/lib/nginx/state/saml_name_id.json                     timeout=1h; 

# Zone for storing SAML NameID format values. (REQUIRED) 
# Timeout determines how long the SP keeps NameID format values. Must be equal to session lifetime. 
keyval_zone zone=saml_name_id_format:1M             state=/var/lib/nginx/state/saml_name_id_format.json              timeout=1h; 

# Zone for storing SAML SessionIndex values. (REQUIRED) 
# Timeout determines how long the SP keeps SessionIndex values. Must be equal to session lifetime. 
keyval_zone zone=saml_session_index:1M              state=/var/lib/nginx/state/saml_session_index.json               timeout=1h; 
  
# Zone for storing SAML AuthnContextClassRef values. (REQUIRED) 
# Timeout determines how long the SP keeps AuthnContextClassRef values. Must be equal to session lifetime. 
keyval_zone zone=saml_authn_context_class_ref:1M    state=/var/lib/nginx/state/saml_authn_context_class_ref.json     timeout=1h; 

# Zones for storing SAML attributes values. (OPTIONAL) 
# Timeout determines how long the SP keeps attributes values. Must be equal to session lifetime. 
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-related variables whose value is looked up by the key (session cookie) in the key-value database. 

# Required: 
keyval $saml_request_id     $saml_request_redeemed          zone=saml_request_id;               # SAML Request ID 
keyval $saml_response_id    $saml_response_redeemed         zone=saml_response_id;              # SAML Response ID 
keyval $cookie_auth_token   $saml_access_granted            zone=saml_session_access;           # SAML Access decision 
keyval $cookie_auth_token   $saml_name_id                   zone=saml_name_id;                  # SAML NameID 
keyval $cookie_auth_token   $saml_name_id_format            zone=saml_name_id_format;           # SAML NameIDFormat 
keyval $cookie_auth_token   $saml_session_index             zone=saml_session_index;            # SAML SessionIndex 
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; 
  

######### Imports a module that implements SAML SSO and SLO functionality 
js_import samlsp from conf.d/saml_sp.js;

Schritt 3: Testen der Konfiguration

Zum Testen der Konfiguration sind zwei Schritte erforderlich:

Überprüfen des SAML-Ablaufs
Testen der vom SP initiierten Abmeldefunktion

Überprüfen des SAML-Ablaufs

Nach der Konfiguration des SAML-SP mit NGINX Plus und des IdP mit Microsoft Entra ID muss der SAML-Ablauf unbedingt überprüft werden. Durch diese Überprüfung wird sichergestellt, dass die Benutzerauthentifizierung über den IdP erfolgreich ist und der Zugriff auf die vom SP geschützten Ressourcen gewährt wird.

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

Abbildung 8: Die Anmeldeseite des IdP

Geben Sie die Anmeldedaten eines Benutzers ein, der auf der Anmeldeseite des IdP konfiguriert ist. Nach dem Absenden authentifiziert der IdP den Benutzer.

Abbildung 9: Eingabe der Anmeldedaten des konfigurierten Benutzers

Nach erfolgreichem Aufbau einer Sitzung erhält der Benutzer Zugriff auf die zuvor angeforderte geschützte Ressource. Anschließend wird diese Ressource im Browser des Benutzers angezeigt.

Abbildung 10: Die erfolgreich geladene Anwendungsseite

Wertvolle Informationen zum SAML-Ablauf erhalten Sie durch Überprüfen der SP- und IdP-Protokolle. Stellen Sie auf der SP-Seite (NGINX Plus) sicher, dass die auth_token-Cookies korrekt gesetzt sind. Stellen Sie auf der IdP-Seite (Microsoft Entra ID) sicher, dass der Authentifizierungsvorgang fehlerfrei abgeschlossen und die SAML-Assertion an den SP gesendet wird.

Das NGINX-access.log sollte wie folgt aussehen:

127.0.0.1 - - [14/Aug/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, like Gecko) Version/16.1 Safari/605.1.15" "-" 

99.187.244.63 - Akash Ananthanarayanan [14/Aug/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, like Gecko) Version/16.1 Safari/605.1.15" "-

Während das NGINX-debug.log wie folgt aussieht:

2023/08/14 21:25:49 [info] 27513#27513: *399 js: SAML SP success, creating session _d4db9b93c415ee7b4e057a4bb195df6cd0be7e4d

Testen der SP-initiierten Abmeldefunktion

SAML Single Logout (SLO) ermöglicht es Benutzern, sich mit einer einzigen Aktion von allen beteiligten IdPs und SPs abzumelden. NGINX Plus unterstützt sowohl SP-initiierte als auch IdP-initiierte Abmeldeszenarien und verbessert so die Sicherheit und Benutzerfreundlichkeit in SSO-Umgebungen. In diesem Beispiel verwenden wir ein SP-initiiertes Abmeldeszenario.

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

Nachdem Sie Ihre Sitzung authentifiziert haben, melden Sie sich ab, indem Sie die in Ihrem SP konfigurierte Abmelde-URL aufrufen. 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 anschließend vom IdP überprüft und verarbeitet wird. Dadurch wird die Sitzung des Benutzers beendet. Der IdP sendet daraufhin eine SAML-Antwort, um den Browser des Benutzers zurück zum SP umzuleiten.

Fazit

Herzlichen Glückwunsch! NGINX Plus kann jetzt als SAML-SP fungieren und bietet damit eine zusätzliche Ebene an Sicherheit und Komfort für den Authentifizierungsprozess. Diese neue Funktion ist ein bedeutender Fortschritt für NGINX Plus und macht es zu einer noch robusteren und vielseitigeren Lösung für Organisationen, die Sicherheit und Effizienz priorisieren.

Weitere Informationen zur Verwendung von SAML mit NGINX Plus

Sie können SAML mit NGINX Plus noch heute nutzen, indem Sie eine 30-tägige kostenlose Testversion von NGINX Plus starten. Wir hoffen, dass sie Ihnen nützlich ist, und freuen uns über Ihr Feedback.

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