Configurer le SSO initié par le fournisseur d’identité SAML

Décrit comment configurer le SSO initié par le fournisseur d’identité SAML.

Bon nombre d’instructions pour configurer une fédération SAML commencent par une authentification unique (SSO) initiée par le fournisseur de services. Le fournisseur de services redirige l’utilisateur vers le fournisseur d’identité (IdP) pour l’authentification. Ce processus est couramment utilisé dans les scénarios destinés au grand public.

Cependant, dans les scénarios d’entreprise, il n’est pas rare que le SSO soit initié par l’IdP plutôt que par le fournisseur de services. Par exemple, une entreprise peut configurer un portail pour s’assurer que les utilisateurs accèdent à la bonne application après s’être connectés au portail.

​

Risques et considérations

Les flux initiés par l’IdP présentent un risque de sécurité et ne sont donc pas recommandés. Il est recommandé d’utiliser des flux initiés par le SP chaque fois que possible.

Assurez-vous de bien comprendre les risques avant d’activer le SSO initié par l’IdP. Dans ce scénario, Auth0 reçoit la réponse non sollicitée de l’IdP, et l’application reçoit la réponse non sollicitée d’Auth0. Aucune des deux entités ne peut vérifier que l’utilisateur a lancé le flux. Par conséquent, l’activation de ce flux rend possible une attaque CSRF de connexion, dans laquelle un attaquant peut amener un utilisateur légitime à se connecter à l’application, à son insu, avec l’identité de l’attaquant.

​

Flux OpenID Connect initié par l’IdP

OpenID Connect (OIDC) ne prend pas en charge le concept de flux initié par l’IdP. Ainsi, même si Auth0 offre la possibilité de convertir un flux SAML initié par l’IdP (à partir d’une connexion SAML) en réponse OIDC pour une application, toute application qui implémente correctement le protocole OIDC/OAuth2 rejettera une réponse non sollicitée.

Lorsque vous utilisez des applications OIDC, la meilleure option consiste à faire en sorte que votre application crée un point de terminaison de connexion. Le seul objectif de ce point de terminaison est d’initier la redirection vers l’IdP (votre locataire Auth0).

Si vous utilisez plusieurs fournisseurs d’identité (IdP), assurez-vous que le point de terminaison de connexion est soit propre au fournisseur d’identité, soit en mesure d’accepter un paramètre permettant d’identifier quel IdP initie le processus.

Une autre approche consiste à faire en sorte que les utilisateurs démarrent le flux de connexion dans l’application.

​

URL de retour

Lorsque vous utilisez le SSO initié par l’IdP, assurez-vous d’inclure le paramètre connexion dans l’URL de retour :

Si vous utilisez la fonctionnalité Organisations, vous pouvez également inclure un paramètre organization contenant l’id de l’organisation voulue :

Pour que les utilisateurs puissent se connecter avec succès à l’aide de cette méthode, la connexion doit être activée pour l’Organisation. De plus, vous devez soit configurer l’adhésion automatique pour la connexion activée, soit vous assurer que les utilisateurs sont membres de l’Organisation.

​

Lock/Auth0.js

Si votre application est une application monopage qui utilise Lock ou Auth0.js pour traiter les résultats de l’authentification, vous devez indiquer explicitement que vous souhaitez autoriser les flux initiés par l’IdP, et donc exposer l’application à d’éventuelles attaques CSRF de connexion.

Si vous utilisez Auth0.js, vous devez mettre à jour webAuth.parseHash dans la bibliothèque et définir l’indicateur __enableIdPInitiatedLogin à true.

var data = webAuth.parseHash(
      {
        ...
        __enableIdPInitiatedLogin: true
        ...
      }

Si vous utilisez Lock, vous pouvez inclure cet indicateur à l’aide du paramètre options transmis au constructeur.

const lock = new Auth0Lock(clientID, domain, options)

Voici l’indicateur lui-même :

var options = { _enableIdPInitiatedLogin: true };

Notez que l’indicateur enableIdPInitiatedLogin est précédé d’un trait de soulignement lorsqu’il est utilisé avec Lock, et de deux traits de soulignement lorsqu’il est utilisé avec la bibliothèque auth0.js.

​

Configurer le SSO initié par l’IdP

1. Accédez à Dashboard > Authentication > Enterprise et choisissez SAMLP Identity Provider.

2. Sous Settings, vous pouvez voir la configuration du SSO initié par l’IdP.

   

• IdP-initiated SSO Behavior : cette option vous permet d’activer les connexions initiées par l’IdP pour la connexion SAML. Sélectionnez Accept Requests et remplissez tous les champs requis.
• Default Application: lorsque la connexion initiée par l’IdP réussit, les utilisateurs sont dirigés vers cette application. Ce paramètre affiche les applications disponibles qui sont activées pour cette connexion. Sélectionnez dans la liste déroulante l’application avec laquelle vous voulez que les utilisateurs se connectent par l’intermédiaire d’un flux initié par l’IdP. Une seule application peut être sélectionnée pour une connexion initiée par l’IdP par connexion SAML.
• Response Protocol: il s’agit du protocole utilisé pour connecter la Default Application sélectionnée. Le plus souvent, les applications sont configurées avec le protocole OpenID Connect (voir ci-dessus). Toutefois, si vous avez configuré un module complémentaire SAML2 Web App pour votre application et que vous souhaitez acheminer l’assertion SAML, vous devrez sélectionner SAML. Une fois qu’une assertion SAML valide a été transmise à l’URL de postback, Auth0 envoie une réponse de connexion à la première URL de rappel autorisée de l’application par défaut configurée au moyen du protocole de réponse choisi. Ce comportement peut être modifié à l’aide du champ de chaîne de requête pour préciser un redirect_uri si vous utilisez OIDC.
  • Si l’URL de rappel configurée pour l’application comprend un espace réservé Multiple Custom Domains (MCD), le système le remplit dynamiquement à l’aide de la valeur de métadonnées correspondant au domaine personnalisé de l’URL de postback qui a reçu la demande initiale de l’IdP. Pour en savoir plus, consultez Multiple Custom Domains.
• Query String: les options de chaîne de requête permettent de personnaliser le comportement lorsque le protocole OpenID Connect est utilisé. Vous pouvez définir plusieurs options, comme lorsque vous ajoutez des paramètres à une chaîne de requête. Vous pouvez définir :

Paramètre	Description
redirect_uri	Une fois la connexion initiée par l’IdP terminée, la requête est redirigée vers la première URL indiquée dans Allowed Callback URLs pour l’application. Toutefois, si vous définissez un redirect_uri, l’IdP redirigera vers cette URL. Cela offre plus de souplesse, par exemple si vous utilisez un schéma de sous-domaines avec caractère générique et que vous voulez rediriger uniquement vers un sous-domaine précis.
scope	Définissez les scopes du ID Token envoyé. Vous pouvez définir plusieurs scopes.
response_type	Définissez le jeton pour le flux Implicit Grant destiné aux SPA. Vous pouvez définir code pour le flux Authorization Code Grant des applications Web classiques.

Dans un flux initié par l’IdP, les serveurs Auth0 suppriment les scopes d’un jeton si l’URL de rappel correspond à un domaine non vérifié. Auth0 considère uniquement localhost et 127.0.0.1 comme des domaines non vérifiés. Si vous utilisez l’un ou l’autre comme URL de rappel, les jetons du point de terminaison /userinfo retourneront une réponse vide. Pour obtenir une réponse de jeton avec les scopes demandés, utilisez un domaine vérifié.

Exemple de chaîne de requête : redirect_uri=https://jwt.io&scope=openid email&response_type=token

​

Liste déroulante d’applications limitée à 100

Si vous souhaitez sélectionner une application comme Default Application dans le cadre du SSO initié par l’IdP, et que l’application ne figure pas parmi les 100 premières affichées dans la liste déroulante de votre locataire, vous devez utiliser Management API pour sélectionner cette application. Vous devez exécuter une requête PATCH :

{
"options": {
"signInEndpoint": "yourIdpSignInUrl",
"idpinitiated": {
"client_id": "yourClientId",
"client_protocol": "saml",
"client_authorizequery": ""
},
"signingCert": "[copied-from-GET]"
}
}

​

En savoir plus

• Utiliser des certificats et des clés sous forme de chaînes de caractères