Afin de renforcer la sécurité et d’améliorer l’expérience utilisateur, F5 NGINX Plus (R29+) prend désormais en charge le langage SAML (Security Assertion Markup Language). Protocole éprouvé permettant l’authentification unique (SSO) aux applications web, SAML permet à un fournisseur d’identité (IdP) d’authentifier les utilisateurs afin qu’ils puissent accéder à une ressource, puis transmet ces informations à un fournisseur de services (SP) à des fins d’autorisation.
Dans cet article de blog, nous expliquons étape par étape comment intégrer NGINX à Microsoft Entra ID, anciennement Azure Active Directory (Azure AD), à l’aide d’une application web qui ne prend pas nativement en charge SAML. Nous expliquons également comment mettre en œuvre l’authentification unique (SSO) pour l’application et l’intégrer à l’écosystème Microsoft Entra ID. En suivant ce tutoriel, vous apprendrez aussi comment NGINX peut extraire les revendications d’une assertion SAML (notamment l’UPN, le prénom, le nom et l’appartenance aux groupes), puis les transmettre à l’application via des en-têtes HTTP.
Le tutoriel comprend trois étapes :
- Configuration de Microsoft Entra ID en tant que fournisseur d’identité
- Configuration des paramètres SAML et de NGINX Plus en tant que proxy inverse
- Test de la configuration
Pour suivre ce tutoriel, vous avez besoin des éléments suivants :
- NGINX Plus (R29+), que vous pouvez essayer gratuitement pendant 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 and dev.sports.com.key») - Pour vérifier les assertions SAML, vous pouvez télécharger le certificat public «
demonginx.cer» depuis l’IdP
Remarque: ce tutoriel ne s’applique pas aux déploiements NGINX Open Source, car le magasin clé-valeur est réservé à NGINX Plus.
Utiliser NGINX Plus comme fournisseur de services SAML
Dans cette configuration, NGINX Plus fait office de fournisseur de services (SP) SAML et peut participer à une mise en œuvre de l’authentification unique (SSO) avec un fournisseur d’identité (IdP) SAML, qui communique indirectement avec NGINX Plus par l’intermédiaire de l’agent utilisateur.
Le schéma ci-dessous illustre le déroulement du processus SSO, avec une initiation par le SP et des liaisons POST pour la requête et la réponse. Il est essentiel de rappeler que ce canal de communication n’est pas direct et qu’il est géré par l’agent utilisateur.
Figure 1 : SSO SAML initié par le SP avec des liaisons POST pour AuthnRequest et Response
Étape 1 : configurer Microsoft Entra ID en tant que fournisseur d’identité
Pour accéder à votre portail de gestion Microsoft Entra ID, connectez-vous et accédez au volet de gauche. Sélectionnez « Microsoft Entra ID », puis cliquez sur le nom de l’annuaire pour lequel vous souhaitez configurer l’authentification unique (SSO). Une fois l’annuaire sélectionné, choisissez « Applications d’entreprise ».

Figure 2 : Sélection d’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éation d’une application dans Microsoft Entra ID
Après avoir été redirigé vers la page Vue d’ensemble de l’application nouvellement créée, accédez à Prise en main dans le menu de gauche, puis cliquez sur Authentification unique sous Gérer. Sélectionnez ensuite 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 (SSO) dans votre application d’entreprise, vous devez enregistrer NGINX Plus en tant que fournisseur de services (SP) dans Microsoft Entra ID. Pour ce faire, cliquez sur l’icône en forme de crayon à côté de Modifier dans Configuration SAML de base, comme illustré à la figure 5.
Ajoutez les valeurs suivantes, puis cliquez sur « Enregistrer » :
- Identifiant (ID d’entité) – https://dev.sports.com
- URL de réponse (URL du service consommateur d’assertions) – https://dev.sports.com/saml/acs
- URL de connexion: https://dev.sports.com
- URL de déconnexion (facultative): https://dev.sports.com/saml/sls
L’utilisation de certificats de vérification est facultative. Lorsque vous activez ce paramètre, deux options de configuration doivent être définies dans NGINX :
- Pour vérifier la signature à l’aide d’une clé publique, vous devez définir
$saml_sp_sign_authnsur true. Cela indique au SP de signer la requête AuthnRequest envoyée à l’IdP. - Indiquez le chemin d’accès à la clé privée qui sera utilisée pour cette signature en configurant
$saml_sp_signing_key. Veillez à charger le certificat de clé publique correspondant dans Microsoft Entra ID afin de permettre la vérification de la signature.
Remarque: dans cette démonstration, 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 correctement paramétrée pour recevoir et traiter ces attributs. Vous pouvez vérifier et ajuster les paramètres associés dans le dépôt GitHub de NGINX.
Téléchargez le certificat (brut) du fournisseur d’identité depuis Microsoft Entra ID et enregistrez-le sur votre instance NGINX Plus.

Figure 5 : Téléchargement du certificat du fournisseur d’identité (brut) depuis Microsoft Entra ID

Figure 6 : Ajout d’un nouvel utilisateur ou groupe
Dans Microsoft Entra ID, vous pouvez accorder l’accès aux applications de votre entreprise compatibles avec l’authentification unique (SSO) en ajoutant ou en affectant des utilisateurs et des groupes.
Dans le menu de gauche, cliquez sur « Utilisateurs et groupes », puis sur le bouton « Ajouter un utilisateur/groupe » en haut de la page.
Étape 2 : configurer les paramètres SAML et NGINX Plus en tant que proxy inverse
Assurez-vous de disposer des certificats nécessaires avant de configurer les fichiers dans votre fournisseur de services NGINX Plus :
- Certificats permettant de terminer la session TLS (
dev.sports.com.crt et dev.sports.com.key) - Certificat téléchargé depuis Microsoft Entra ID pour vérifier la signature de l’IdP (
demonginx.cer)
Remarque : les certificats doivent être au format SPKI.
Pour commencer cette étape, téléchargez le certificat de l’IdP depuis Microsoft Entra ID afin de vérifier la signature. Convertissez ensuite le format PEM au format DER :
openssl x509 -in demonginx.cer -outform DER -out demonginx.der
Si vous souhaitez vérifier les assertions du fournisseur de services SAML, il est recommandé d’utiliser des clés publiques/privées différentes de celles utilisées pour la terminaison TLS.
Extrayez le certificat de clé publique au format SPKI :
openssl x509 -inform DER -in demonginx.der -pubkey -noout > demonginx.spki
Modifiez le fichier frontend.conf pour mettre à jour les éléments suivants :
ssl_certificate– Mettez à jour ce paramètre pour inclure le chemin d’accès au certificat TLS.ssl_certificate_key– Mettez à jour ce paramètre pour inclure le chemin d’accès à la clé privée TLS.
Dans un déploiement en production, vous pouvez utiliser différentes destinations de backend en fonction des besoins métier. Dans cet exemple, le backend fournit une réponse personnalisée :
« Bienvenue sur la page de l’applicationn Mon identifiant d’objet est $http_objectidn Mon adresse e-mail est $http_mailn » ;
Nous avons modifié les attributs et les revendications dans Microsoft Entra ID en ajoutant de nouvelles revendications pour l’adresse e-mail de l’utilisateur (« mail ») et son identifiant d’objet (« objectid »). Ces mises à jour vous permettent de proposer une réponse plus personnalisée et mieux adaptée dans votre application, améliorant ainsi l’expérience utilisateur.

Figure 7 : Attributs et revendications modifiés dans Microsoft Entra ID
L’étape suivante consiste à configurer NGINX, qui transmettra le trafic à l’application backend via un proxy. Dans cette démonstration, l’application SAML backend est accessible publiquement à l’adresse https://dev.sports.com.
Modifiez votre fichier « 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
Pour que les attributs « saml_attrib_mail » et « saml_attrib_ objectid » soient pris en compte dans les configurations NGINX, mettez à jour la partie relative au magasin clé-valeur de saml_sp_configuration.conf comme suit :
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;
Ensuite, configurez le fichier de configuration de l’authentification unique SAML. Ce fichier contient les principaux paramètres de configuration du SP et de l’IdP. Pour l’adapter à votre configuration spécifique du SP et de l’IdP, vous devez modifier les différents blocs map{} qu’il contient.
Ce tableau décrit les variables du fichier « saml_sp_configuration.conf » :
| Variable | Description |
|---|---|
saml_sp_entity_id | URL utilisée par les utilisateurs pour accéder à l’application. |
saml_sp_acs_url | URL utilisée par le fournisseur de services pour recevoir et traiter la réponse SAML, extraire l’identité de l’utilisateur, puis autoriser ou refuser l’accès à la ressource demandée en fonction des informations fournies. |
saml_sp_sign_authn | Indique si la requête SAML envoyée par le SP à l’IdP doit être signée. La signature est effectuée à l’aide de la clé de signature du SP. Vous devez charger le certificat associé sur l’IdP afin de vérifier la signature. |
saml_sp_signing_key | Clé de signature utilisée pour signer la requête SAML envoyée par le SP à l’IdP. Veillez à charger le certificat associé sur l’IdP afin de vérifier la signature. |
saml_idp_entity_id | Identité utilisée pour définir l’IdP. |
saml_idp_sso_url | Point de terminaison de l’IdP auquel le SP envoie la requête d’assertion SAML afin de lancer la demande d’authentification. |
saml_idp_verification_certificate | Certificat utilisé pour vérifier les assertions SAML signées reçues de l’IdP. Le certificat est fourni par l’IdP et doit être au format SPKI. |
saml_sp_slo_url | Point de terminaison du SP auquel l’IdP envoie la requête SAML LogoutRequest (lors du lancement d’un processus de déconnexion) ou la réponse LogoutResponse (lors de la confirmation de la déconnexion). |
saml_sp_sign_slo | Indique si le message SAML de déconnexion doit être signé par le SP. |
saml_idp_slo_url | Point de terminaison de l’IdP auquel le SP envoie la requête LogoutRequest (lors du lancement d’un processus de déconnexion) ou la réponse LogoutResponse (lors de la confirmation de la déconnexion). |
saml_sp_want_signed_slo | Indique si le SP SAML exige que la réponse ou la requête SAML de déconnexion provenant de l’IdP soit signée. |
Le code ci-dessous présente uniquement les valeurs modifiées pour ce cas d’utilisation dans le fichier saml_sp_configuration.conf.
Remarque: assurez-vous que les autres parties du fichier de configuration figurent toujours dans le fichier (par exemple, les magasins clé-valeur). Veillez également à adapter correctement les variables du fichier saml_sp_configuration.conf en fonction de votre déploiement.
# 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;
Étape 3 : tester la configuration
Deux éléments sont nécessaires pour tester la configuration :
- Vérification du flux SAML
- Test de la fonctionnalité de déconnexion initiée par le SP
Vérification du flux SAML
Après avoir configuré le fournisseur de services SAML à l’aide de NGINX Plus et le fournisseur d’identité à l’aide de Microsoft Entra ID, il est essentiel de valider le flux SAML. Ce processus de validation permet de vérifier que l’authentification des utilisateurs auprès du fournisseur d’identité aboutit et que l’accès aux ressources protégées par le fournisseur de services est accordé.
Pour vérifier le flux SAML initié par le SP, ouvrez le navigateur de votre choix et saisissez https://dev.sports.com dans la barre d’adresse. Vous êtes alors redirigé vers la page de connexion de l’IdP.

Figure 8 : page de connexion de l’IdP
Saisissez les identifiants d’un utilisateur configuré sur la page de connexion de l’IdP. L’IdP authentifiera l’utilisateur lors de la validation.

Figure 9 : Saisie des identifiants de l’utilisateur configuré
Une fois la session établie avec succès, l’utilisateur pourra accéder à la ressource protégée précédemment demandée. Cette ressource s’affichera alors dans le navigateur de l’utilisateur.

Figure 10 : page de l’application chargée avec succès
Des informations précieuses sur le flux SAML peuvent être obtenues en consultant les journaux du SP et de l’IdP. Côté SP (NGINX Plus), vérifiez que les cookies auth_token sont correctement définis. Côté IdP (Microsoft Entra ID), vérifiez que le processus d’authentification se termine sans erreur et que l’assertion SAML est envoyée au SP.
Le fichier access.log de NGINX doit se présenter comme suit :
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" "-
Tandis que le fichier debug.log de NGINX ressemble à ceci :
2023/08/14 21:25:49 [info] 27513#27513: *399 js: SAML SP success, creating session _d4db9b93c415ee7b4e057a4bb195df6cd0be7e4d
Test de la fonctionnalité de déconnexion initiée par le SP
La déconnexion unique SAML (SLO) permet aux utilisateurs de se déconnecter en une seule action de tous les IdP et SP concernés. NGINX Plus prend en charge les scénarios de déconnexion initiée par le SP et par l’IdP, ce qui renforce la sécurité et améliore l’expérience utilisateur dans les environnements SSO. Dans cet exemple, nous utilisons un scénario de déconnexion initiée par le SP.
Figure 11 : SLO SAML initiée par le SP 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 défini 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 opération met effectivement fin à la session de l’utilisateur, puis l’IdP envoie une réponse SAML afin de rediriger le navigateur de l’utilisateur vers le SP.
Conclusion
Félicitations ! NGINX Plus peut désormais faire office de fournisseur de services (SP) SAML, offrant ainsi un niveau supplémentaire de sécurité et de simplicité au processus d’authentification. Cette nouvelle fonctionnalité constitue une avancée majeure pour NGINX Plus, qui devient une solution plus robuste et polyvalente pour les organisations accordant la priorité à 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 profitant d’un essai gratuit de 30 jours de NGINX Plus. Nous espérons que cette solution vous sera utile et vos commentaires sont les bienvenus.
Vous trouverez davantage d’informations sur NGINX Plus avec SAML dans les ressources ci-dessous.
- Annonce de NGINX Plus R29
- Prise en charge de SAML dans NGINX Plus sous forme d’implémentation de référence sur GitHub
À propos de l’auteur

Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.

Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.