Configurer NGINX Plus pour SAML SSO avec Microsoft Entra ID

Pour améliorer la sécurité et l'expérience utilisateur, F5 NGINX Plus (R29+) prend désormais en charge le langage SAML (Security Assertion Markup Language). Protocole bien établi qui fournit une authentification unique (SSO) aux applications Web, SAML permet à un fournisseur d'identité (IdP) d'authentifier les utilisateurs pour l'accès à une ressource, puis de transmettre ces informations à un fournisseur de services (SP) pour autorisation.

Dans cet article de blog, nous expliquons étape par étape comment intégrer NGINX à Microsoft Entra ID , anciennement connu sous le nom d’Azure Active Directory (Azure AD), à l’aide d’une application Web qui ne prend pas en charge nativement SAML. Nous expliquons également comment implémenter SSO pour l'application et l'intégrer à l'écosystème Microsoft Entra ID. En suivant le didacticiel, vous apprendrez également comment NGINX peut extraire des revendications d'une assertion SAML (y compris le nom d'utilisateur principal, le prénom, le nom et les appartenances aux groupes), puis les transmettre à l'application via des en-têtes HTTP.

Le tutoriel comprend trois étapes :

1. Configuration de Microsoft Entra ID en tant qu'IdP
2. Configuration des paramètres SAML et NGINX Plus comme proxy inverse
3. Tester la configuration

Pour réaliser ce tutoriel, vous avez besoin de :

• NGINX Plus (R29+), que vous pouvez obtenir en essai gratuit de 30 jours
• Un compte Microsoft Entra ID gratuit ou d'entreprise
• Un certificat SSL/TLS valide installé sur le serveur NGINX Plus (ce tutoriel utilise dev.sports.com.crt et dev.sports.com.key )
• Pour vérifier les assertions SAML, ce qui peut être fait en téléchargeant le certificat public demonginx.cer depuis l'IdP

Note : Ce didacticiel ne s'applique pas aux déploiements NGINX Open Source car le magasin clé-valeur est exclusif à NGINX Plus.

Utilisation de NGINX Plus comme fournisseur de services SAML

Dans cette configuration, NGINX Plus agit comme un SP SAML et peut participer à une implémentation SSO avec un IdP SAML, qui communique indirectement avec NGINX Plus via l'agent utilisateur.

Le diagramme ci-dessous illustre le flux du processus SSO, avec l'initiation SP et les liaisons POST pour la demande et la réponse. Il est essentiel de noter à nouveau que ce canal de communication n’est pas direct et est géré via l’agent utilisateur.

Figure 1 : SSO initié par SAML SP avec liaisons POST pour AuthnRequest et Response

Étape 1 : Configurer Microsoft Entra ID comme fournisseur d'identité

Pour accéder à votre portail de gestion Microsoft Entra ID, connectez-vous et accédez au panneau de gauche. Sélectionnez Microsoft Entra ID , puis cliquez sur le titre du répertoire qui nécessite une configuration SSO. Une fois sélectionné, choisissez Applications d'entreprise .

Figure 2 : Choix des applications d'entreprise dans le portail de gestion

Pour créer une application, cliquez sur le bouton Nouvelle application en haut du portail. Dans cet exemple, nous avons créé une application appelée demonginx .

Figure 3 : Créer une nouvelle application dans Microsoft Entra ID

Après avoir été redirigé vers l' aperçu de l'application nouvellement créée, accédez à Mise en route via le menu de gauche et cliquez sur Authentification unique sous Gérer . Ensuite, sélectionnez SAML comme méthode d’authentification unique .

Figure 4 : Utilisation de la section SSO pour démarrer la configuration SAML

Pour configurer l'authentification unique dans votre application d'entreprise, vous devez enregistrer NGINX Plus en tant que fournisseur de services dans Microsoft Entra ID. Pour ce faire, cliquez sur l'icône en forme de crayon en regard de Modifier dans la configuration SAML de base , comme illustré à la Figure 5.

Ajoutez les valeurs suivantes puis cliquez sur Enregistrer :

• Identifiant (Entity ID) – https://dev.sports.com
• URL de réponse (URL du service client d'assertion) – https://dev.sports.com/saml/acs
• URL de connexion : https://dev.sports.com
• URL de déconnexion (facultatif) : https://dev.sports.com/saml/sls

L'utilisation de certificats de vérification est facultative. Lors de l'activation de ce paramètre, deux options de configuration dans NGINX doivent être traitées :

1. Pour vérifier la signature avec une clé publique, vous devez définir $saml_sp_sign_authn sur true . Cela demande au SP de signer l'AuthnRequest envoyée à l'IdP.
2. Fournissez le chemin d'accès à la clé privée qui sera utilisée pour cette signature en configurant $saml_sp_signing_key . Assurez-vous de télécharger le certificat de clé publique correspondant sur Microsoft Entra ID pour la vérification de la signature.

Note : Dans cette démo, les attributs et les revendications ont été modifiés et de nouveaux attributs SAML ont été ajoutés. Ces attributs SAML sont envoyés par l'IdP. Assurez-vous que votre configuration NGINX est configurée pour recevoir et traiter correctement ces attributs. Vous pouvez vérifier et ajuster les paramètres associés dans le référentiel GitHub NGINX .

Téléchargez le certificat IdP (brut) depuis Microsoft Entra ID et enregistrez-le sur votre instance NGINX Plus.

Figure 5 : Téléchargement du certificat IdP (brut) depuis Microsoft Entra ID

Figure 6 : Ajouter un nouvel utilisateur ou groupe

Dans Microsoft Entra ID, vous pouvez accorder l’accès à vos applications d’entreprise compatibles SSO en ajoutant ou en attribuant des utilisateurs et des groupes.

Dans le menu de gauche, cliquez sur Utilisateurs et groupes puis sur le bouton supérieur Ajouter un utilisateur/groupe .

Étape 2 : Configurer les paramètres SAML et NGINX Plus comme proxy inverse

Assurez-vous de disposer des certificats nécessaires avant de configurer les fichiers dans votre SP NGINX Plus :

• Certificats pour terminer la session TLS ( dev.sports.com.crt et dev.sports.com.key )
• Certificat téléchargé depuis Microsoft Entra ID pour la vérification de la signature IdP ( demonginx.cer )

Note : Les certificats doivent être au format SPKI.

Pour commencer cette étape, téléchargez le certificat IdP depuis Microsoft Entra ID pour la vérification de la signature. Ensuite, convertissez le format PEM au format DER :

Si vous souhaitez vérifier les assertions SAML SP, il est recommandé d’utiliser des clés publiques/privées différentes de celles utilisées pour la terminaison TLS.

Extraire le certificat de clé publique au format SPKI :

Modifiez le fichier frontend.conf pour mettre à jour ces éléments :

• ssl_certificate – Mise à jour pour inclure le chemin du certificat TLS.
• ssl_certificate_key – Mise à jour pour inclure le chemin de la clé privée TLS.

Dans le déploiement de production, vous pouvez utiliser différentes destinations back-end en fonction des besoins de l'entreprise. Dans cet exemple, le backend fournit une réponse personnalisée :

Nous avons modifié les attributs et les revendications dans Microsoft Entra ID en ajoutant de nouvelles revendications pour le courrier électronique et l'ID d'objet de l'utilisateur. Ces mises à jour vous permettent de fournir une réponse plus personnalisée et adaptée à votre application, ce qui se traduit par une expérience utilisateur améliorée.

Figure 7 : Attributs et revendications modifiés dans Microsoft Entra ID

L’étape suivante consiste à configurer NGINX, qui dirigera le trafic vers l’application backend. Dans cette démo, l'application SAML backend est disponible publiquement sur https://dev.sports.com .

Modifiez votre fichier frontend.conf :

# Ceci est le fichier frontend.conf 
# Ceci est l'application backend que nous protégeons avec SAML SSO 
upstream my_backend { 
zone my_backend 64k; 
server dev.sports.com; 
} 

# Format de journal personnalisé pour inclure le sujet 'NameID' dans le champ REMOTE_USER 
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"'; 

# Le serveur frontend - proxy inverse avec authentification SAML SSO 
# 
server { 
# Emplacements fonctionnels implémentant la prise en charge SAML SSO 
include conf.d/saml_sp.server_conf; 

# Réduisez le niveau de gravité si nécessaire 
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 / { 
# Lorsqu'un utilisateur n'est pas authentifié (c'est-à-dire que la variable "saml_access_granted." 
# n'est pas définie sur "1"), une erreur HTTP 401 Unauthorized est 
# renvoyée, qui est gérée par l'emplacement nommé @do_samlsp_flow. 
error_page 401 = @do_samlsp_flow; 

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

# Les utilisateurs authentifiés avec succès sont envoyés par proxy au backend, 
# avec l'attribut NameID transmis comme en-tête HTTP 
proxy_set_header mail $saml_attrib_mail; # ID Microsoft Entra user.mail 
proxy_set_header objectid $saml_attrib_objectid; # ID Microsoft Entra objectid 
access_log /var/log/nginx/access.log saml_sso; 
proxy_pass http://my_backend; 
proxy_set_header Host dev.sports.com; 
return 200 "Bienvenue sur la page d'application\n Mon objectid est $http_objectid\n Mon email est $http_mail\n"; 
default_type text/plain; 

} 
} 
# vim: syntax=nginx         

Pour que les attributs saml_attrib_mail et saml_attrib_objectid soient reflétés dans les configurations NGINX, mettez à jour la partie clé-valeur du fichier saml_sp_configuration.conf comme suit :

keyval_zone zone=saml_attrib_mail:1M état=/var/lib/nginx/state/saml_attrib_email.json délai d'attente=1h; 
keyval $cookie_auth_token $saml_attrib_mail zone=saml_attrib_mail; 

keyval_zone zone=saml_attrib_objectid:1M état=/var/lib/nginx/state/saml_attrib_objectid.json délai d'attente=1h; 
keyval $cookie_auth_token $saml_attrib_objectid zone=saml_attrib_objectid; 

Ensuite, configurez le fichier de configuration SAML SSO. Ce fichier contient les configurations principales du SP et de l'IdP. Pour le personnaliser en fonction de votre configuration SP et IdP spécifique, vous devez ajuster les multiples blocs map{} inclus dans le fichier.

Ce tableau fournit des descriptions des variables dans saml_sp_configuration.conf :

Le code ci-dessous affiche les valeurs modifiées uniquement pour ce cas d'utilisation dans saml_sp_configuration.conf.

Note : Assurez-vous que les parties restantes du fichier de configuration apparaissent toujours dans le fichier (par exemple, les magasins de clés-valeurs). Assurez-vous également d’ajuster correctement les variables dans le fichier saml_sp_configuration.conf en fonction de votre déploiement.

 # Configuration SSO SAML 

map $host $saml_sp_entity_id { 
# Identifiant unique qui identifie le SP auprès de l'IdP. 
# Doit être une URL ou une URN. 
default "https://dev.sports.com"; 
} 

map $host $saml_sp_acs_url { 
# L'URL ACS, un point de terminaison sur le SP vers lequel l'IdP 
# redirigera avec sa réponse d'authentification. 
# Doit correspondre à l'emplacement ACS défini dans le fichier "saml_sp.serer_conf". 
default "https://dev.sports.com/saml/acs"; 
} 

map $host $saml_sp_request_binding { 
# Fait référence à la méthode par laquelle une demande d'authentification est envoyée depuis 
# le SP vers un IdP pendant le processus d'authentification unique (SSO). 
# Seules les méthodes HTTP-POST ou HTTP-Redirect sont autorisées. 
default 'HTTP-POST'; 
} 

map $host $saml_sp_sign_authn { 
# Indique si le SP doit signer l'AuthnRequest envoyée à l'IdP. 
default "false"; 
} 

map $host $saml_sp_decryption_key { 
# Spécifie la clé privée que le SP utilise pour déchiffrer l'assertion 
# chiffrée ou le NameID de l'IdP. 
default ""; 
} 

map $host $saml_sp_force_authn { 
# Indique si le SP doit forcer la ré-authentification de l'utilisateur par l'IdP. 
default "false"; 
} 

map $host $saml_sp_nameid_format { 
# Indique le format souhaité de l'identifiant de nom dans l'assertion SAML 
# générée par l'IdP. Consultez la section 8.3 de la spécification SAML 2.0 Core 
# (http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) 
# pour la liste des formats NameID autorisés. 
default "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"; 
} 

map $host $saml_sp_relay_state { 
# URL relative ou absolue vers laquelle le SP doit rediriger 
# après une connexion réussie. 
default ""; 
} 

map $host $saml_sp_want_signed_response { 
# Indique si le SP souhaite que la réponse SAML de l'IdP 
# soit signée numériquement. 
default "false"; } 

map $host $saml_sp_want_signed_assertion { 
# Indique si le SP souhaite que l'assertion SAML de l'IdP 
# soit signée numériquement. 
par défaut "true"; 
} 

map $host $saml_sp_want_encrypted_assertion { 
# Indique si le SP souhaite que l'assertion SAML de l'IdP 
# soit chiffrée. 
par défaut "false"; 
} 

map $host $saml_idp_entity_id { 
# Identifiant unique qui identifie l'IdP auprès du SP. 
# Doit être une URL ou une URN. 
par défaut "https://sts.windows.net/8807dced-9637-4205-a520-423077750c60/"; 
} 

map $host $saml_idp_sso_url { 
# Point de terminaison IdP auquel le SP enverra la SAML AuthnRequest pour initier 
# un processus d'authentification. 
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_idp_verification_certificate { 
# Fichier de certificat qui sera utilisé pour vérifier la signature numérique 
# sur la réponse SAML, la LogoutRequest ou la LogoutResponse reçue de l'IdP. 
# Doit être une clé publique au format PKCS#1. Consultez la documentation sur la conversion 
# X.509 PEM au format DER. 
default "/etc/nginx/conf.d/demonginx.spki"; 
} 

######## Déconnexion unique (SLO) ######### 

map $host $saml_sp_slo_url { 
# Point de terminaison SP auquel l'IdP enverra la SAML LogoutRequest pour initier 
# un processus de déconnexion ou une LogoutResponse pour confirmer la déconnexion. 
default "https://dev.sports.com/saml/sls"; 
} 

map $host $saml_sp_slo_binding { 
# Fait référence à la méthode par laquelle une LogoutRequest ou une LogoutResponse 
# est envoyée du SP à un IdP pendant le processus de déconnexion unique (SLO). 
# Seules les méthodes HTTP-POST ou HTTP-Redirect sont autorisées. 
default 'HTTP-POST'; 
} 

map $host $saml_sp_sign_slo { 
# Indique si le SP doit signer la LogoutRequest ou la LogoutResponse 
# envoyée à l'IdP. 
default "false"; 
} 

map $host $saml_idp_slo_url { 
# Point de terminaison IdP auquel le SP enverra la LogoutRequest pour initier 
# un processus de déconnexion ou une LogoutResponse pour confirmer la déconnexion. 
# Si elle n'est pas définie, la fonctionnalité SAML Single Logout (SLO) est DÉSACTIVÉE et 
# les demandes à l'emplacement 'logout' entraîneront la fin 
# de la session utilisateur et une redirection vers la page de destination de déconnexion. 
default "https://login.microsoftonline.com/8807dced-9637-4205-a520-423077750c60/saml2"; 
} 

map $host $saml_sp_want_signed_slo { 
# Indique si le fournisseur de services souhaite que la demande de déconnexion SAML ou la réponse de déconnexion de l'IdP
# soit signée numériquement. 
default "true"; 
} 

map $host $saml_logout_landing_page { 
# Où rediriger l'utilisateur après avoir demandé l'emplacement de /logout. Cela peut être 
# remplacé par une page de déconnexion personnalisée ou une URL complète. 
default "/_logout"; # Page de déconnexion simple et intégrée 
} 

map $proto $saml_cookie_flags { 
http "Path=/; SameSite=lax;"; # Pour les tests HTTP/texte brut 
https "Path=/; SameSite=lax; HttpOnly; Secure;"; # Recommandation de production 
} 

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; } 
# CONFIGURATION AVANCÉE SOUS CETTE LIGNE 
# Configuration avancée supplémentaire (contexte du serveur) dans saml_sp.server_conf 

########## Zones de mémoire partagée qui conservent les bases de données clé-valeur liées à SAML 

# Zone de stockage des identifiants de message AuthnRequest et LogoutRequest (ID) 
# pour empêcher les attaques par relecture. (OBLIGATOIRE) 
# Le délai d'attente détermine la durée pendant laquelle le SP attend une réponse de l'IDP, 
# c'est-à-dire la durée du processus d'authentification de l'utilisateur. 
keyval_zone zone=saml_request_id:1M state=/var/lib/nginx/state/saml_request_id.json timeout=5m; 

# Zone de stockage des identifiants de message de réponse SAML (ID) pour empêcher les attaques par relecture. (OBLIGATOIRE) 
# Le délai d'expiration détermine la durée pendant laquelle le SP conserve les identifiants pour empêcher leur réutilisation. 
keyval_zone zone=saml_response_id:1M state=/var/lib/nginx/state/saml_response_id.json timeout=1h; 

# Zone de stockage des informations d'accès aux sessions SAML. (OBLIGATOIRE) 
# Le délai d'expiration détermine la durée pendant laquelle le SP conserve la décision d'accès à la session (la durée de vie de la session). 
keyval_zone zone=saml_session_access:1M state=/var/lib/nginx/state/saml_session_access.json timeout=1h; 

# Zone de stockage des valeurs SAML NameID. (OBLIGATOIRE) 
# Le délai d'expiration détermine la durée pendant laquelle le SP conserve les valeurs NameID. Doit être égal à la durée de vie de la session. 
keyval_zone zone=saml_name_id:1M state=/var/lib/nginx/state/saml_name_id.json timeout=1h; 

# Zone de stockage des valeurs au format SAML NameID. (OBLIGATOIRE) 
# Le délai d'expiration détermine la durée pendant laquelle le SP conserve les valeurs de format NameID. Doit être égal à la durée de vie de la session. 
keyval_zone zone=saml_name_id_format:1M state=/var/lib/nginx/state/saml_name_id_format.json timeout=1h; 

# Zone de stockage des valeurs SAML SessionIndex. (OBLIGATOIRE) 
# Le délai d'expiration détermine la durée pendant laquelle le SP conserve les valeurs SessionIndex. Doit être égal à la durée de vie de la session. 
keyval_zone zone=saml_session_index:1M state=/var/lib/nginx/state/saml_session_index.json timeout=1h; 

# Zone de stockage des valeurs SAML AuthnContextClassRef. (OBLIGATOIRE) 
# Le délai d'expiration détermine la durée pendant laquelle le SP conserve les valeurs AuthnContextClassRef. Doit être égal à la durée de vie de la session. 
keyval_zone zone=saml_authn_context_class_ref:1M state=/var/lib/nginx/state/saml_authn_context_class_ref.json timeout=1h; 

# Zones de stockage des valeurs des attributs SAML. (FACULTATIF) 
# Le délai d'expiration détermine la durée pendant laquelle le SP conserve les valeurs des attributs. Doit être égal à la durée de vie de la session. 
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; 

######### Variables liées à SAML dont la valeur est recherchée par la clé (cookie de session) dans la base de données clé-valeur. 

# Obligatoire : 
keyval $saml_request_id $saml_request_redeemed zone=saml_request_id; # ID de requête SAML 
keyval $saml_response_id $saml_response_redeemed zone=saml_response_id; # ID de réponse SAML 
keyval $cookie_auth_token $saml_access_granted zone=saml_session_access; # Décision d'accès SAML 
keyval $cookie_auth_token $saml_name_id zone=saml_name_id; # ID de nom SAML 
keyval $cookie_auth_token $saml_name_id_format zone=saml_name_id_format; # Format d'ID de nom SAML 
keyval $cookie_auth_token $saml_session_index zone=saml_session_index; # Index de session SAML 
keyval $cookie_auth_token $saml_authn_context_class_ref zone=saml_authn_context_class_ref; # SAML AuthnContextClassRef 

# Facultatif : 
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; 

######### Importe un module qui implémente les fonctionnalités SAML SSO et SLO 
js_import samlsp depuis conf.d/saml_sp.js; 

Étape 3 : Tester la configuration

Deux parties sont nécessaires pour tester la configuration :

1. Vérification du flux SAML
2. Test de la fonctionnalité de déconnexion initiée par le SP

Vérification du flux SAML

Après avoir configuré le SP SAML à l’aide de NGINX Plus et l’IdP à l’aide de Microsoft Entra ID, il est essentiel de valider le flux SAML. Ce processus de validation garantit que l’authentification de l’utilisateur via l’IdP est réussie et que l’accès aux ressources protégées par le SP est accordé.

Pour vérifier le flux SAML initié par SP, ouvrez votre navigateur préféré et saisissez https://dev.sports.com dans la barre d'adresse. Cela vous dirige vers la page de connexion IdP.

Figure 8 : La page de connexion IdP

Saisissez les informations d’identification d’un utilisateur configuré dans la page de connexion de l’IdP. L'IdP authentifiera l'utilisateur lors de la soumission.

Figure 9 : Saisie des identifiants de l’utilisateur configuré

L'utilisateur se verra accorder l'accès à la ressource protégée précédemment demandée une fois la session établie avec succès. Par la suite, cette ressource sera affichée dans le navigateur de l’utilisateur.

Figure 10 : La page d'application chargée avec succès

Des informations précieuses sur le flux SAML peuvent être obtenues en vérifiant les journaux SP et IdP. Du côté SP (NGINX Plus), assurez-vous que les cookies auth_token sont correctement définis. Du côté IdP (Microsoft Entra ID), assurez-vous que le processus d’authentification se termine sans erreur et que l’assertion SAML est envoyée au SP.

Le journal d'accès NGINX devrait ressembler à ceci :

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, comme Gecko) Version/16.1 Safari/605.1.15" "-" 99.187.244.63 - Akash Ananthanarayanan [14/août/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, comme Gecko) Version/16.1 Safari/605.1.15" "- 

Alors que le fichier de débogage NGINX ressemble à ceci :

14/08/2023 21:25:49 [info] 27513#27513: *399 js: Succès SAML SP, création de session _d4db9b93c415ee7b4e057a4bb195df6cd0be7e4d 

Test de la fonctionnalité de déconnexion initiée par le SP

SAML Single Logout (SLO) permet aux utilisateurs de se déconnecter de tous les IdP et SP impliqués en une seule action. NGINX Plus prend en charge les scénarios de déconnexion initiés par le SP et l'IdP, améliorant ainsi la sécurité et l'expérience utilisateur dans les environnements SSO. Dans cet exemple, nous utilisons un scénario de déconnexion initié par SP.

Figure 11 : SLO initié par le SP SAML avec liaisons POST/redirection pour LogoutRequest et LogoutResponse

Après avoir authentifié votre session, déconnectez-vous en accédant à l'URL de déconnexion configurée dans votre SP. Par exemple, si vous avez configuré https://dev.sports.com/logout comme URL de déconnexion dans NGINX Plus, saisissez cette URL dans la barre d'adresse de votre navigateur.

Figure 12 : Déconnexion réussie de la session

Pour garantir une déconnexion sécurisée, le SP doit lancer une requête SAML qui est ensuite vérifiée et traitée par l'IdP. Cette action met effectivement fin à la session de l’utilisateur, et l’IdP enverra alors une réponse SAML pour rediriger le navigateur de l’utilisateur vers le SP.

Conclusion

Félicitations ! NGINX Plus peut désormais servir de SP SAML, offrant une autre couche de sécurité et de commodité au processus d'authentification. Cette nouvelle fonctionnalité constitue une avancée significative pour NGINX Plus, ce qui en fait une solution plus robuste et polyvalente pour les organisations privilégiant la sécurité et l’efficacité. 

En savoir plus sur l'utilisation de SAML avec NGINX Plus

Vous pouvez commencer à utiliser SAML avec NGINX Plus dès aujourd'hui en démarrant un essai gratuit de 30 jours de NGINX Plus . Nous espérons que vous le trouverez utile et serons ravis de recevoir vos commentaires.

Plus d'informations sur NGINX Plus avec SAML sont disponibles dans les ressources ci-dessous.

• Annonce de NGINX Plus R29
• Prise en charge de SAML dans NGINX Plus en tant qu'implémentation de référence sur GitHub