Skip to main content
Bon nombre d’instructions pour configurer une fédération commencent par une (SSO) initiée par le fournisseur de services. Le fournisseur de services redirige l’utilisateur vers le (IdP) à des fins d’authentification. Ce processus est couramment utilisé dans les scénarios destinés aux consommateurs. Cependant, dans les contextes d’entreprise, il arrive qu’on commence plutôt par une SSO initiée par l’IdP que par le fournisseur de services. Par exemple, une entreprise peut mettre en place un portail pour s’assurer que les utilisateurs sont dirigés vers la bonne application après s’y être connectés.

​
Risques et considérations

Les flux IdP-Initiated comportent un risque de sécurité et ne sont donc pas recommandés. Il est recommandé d’utiliser des flux SP-Initiated chaque fois que possible. Assurez-vous de bien comprendre les risques avant d’activer le SSO IdP-Initiated. Dans ce scénario, Auth0 reçoit une réponse non sollicitée de l’IdP, et l’application reçoit une réponse non sollicitée d’Auth0. Aucune des deux entités ne peut vérifier que l’utilisateur est bien à l’origine du flux. Par conséquent, l’activation de ce flux ouvre la porte à une attaque Login CSRF, dans laquelle un attaquant peut amener un utilisateur légitime à se connecter à l’application, à son insu, avec l’identité de l’attaquant.

​
Flux IdP-Initiated d’OpenID Connect

Connect (OIDC) ne prend pas en charge le concept de flux IdP-Initiated. Ainsi, même si Auth0 offre la possibilité de convertir un flux SAML IdP-Initiated (à 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 est que votre application crée un endpoint de connexion. Cet endpoint a pour seul objectif d’amorcer la redirection vers l’IdP (votre tenant Auth0). Si vous utilisez plusieurs IdP, assurez-vous que l’endpoint de connexion est soit propre au fournisseur d’identité, soit en mesure d’accepter un paramètre pour identifier quel IdP lance le workflow. Une autre approche consiste à demander aux utilisateurs de démarrer le flux de connexion à partir de l’application.

​
URL de retour

Lorsque vous utilisez le SSO initié par l’IdP, veillez à inclure le paramètre connection dans l’URL de retour : Si vous utilisez la fonctionnalité Organizations, vous pouvez inclure, au besoin, un paramètre organization contenant l’ID de l’organisation souhaitée :
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 IdP-Initiated et ainsi exposer l’application à d’éventuelles attaques de type Login CSRF. Si vous utilisez Auth0.js, vous devez mettre à jour la méthode webAuth.parseHash de la bibliothèque et définir l’indicateur __enableIdPInitiatedLogin à true.
Si vous utilisez Lock, vous pouvez inclure l’indicateur au moyen du paramètre options transmis au constructeur. const lock = new Auth0Lock(clientID, domain, options) Voici l’indicateur en question : 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.
    Écran de configuration des protocoles pour le SSO initié par l’IdP
  • Comportement du SSO initié par l’IdP : 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.
  • Application par défaut : Lorsque la connexion initiée par l’IdP réussit, les utilisateurs sont redirigés vers cette application. Ce paramètre affiche les applications disponibles 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’entremise de l’IdP. Une seule application peut être sélectionnée pour une connexion initiée par l’IdP par connexion SAML.
  • Protocole de réponse : Il s’agit du protocole utilisé pour connecter l’Application par défaut sélectionnée. Le plus souvent, les applications sont configurées avec le protocole OpenID Connect (voir ci-dessus). Toutefois, si vous avez configuré le module complémentaire SAML2 Web App pour votre application et que vous voulez 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 à l’aide du protocole de réponse choisi, lequel 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 custom domain de l’URL de postback qui a reçu la requête initiale de l’IdP. Pour en savoir plus, consultez Multiple Custom Domains.
  • Chaîne de requête : 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, de façon semblable à des paramètres dans une chaîne de requête. Vous pouvez définir :
Dans un flux initié par l’IdP, les serveurs Auth0 suppriment les scopes à l’intérieur d’un token si l’URL de rappel est 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 tokens du endpoint /userinfo renverront une réponse vide. Pour obtenir une réponse de token 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 Application par défaut dans le cadre du SSO initié par l’IdP et que l’application ne figure pas parmi les 100 premières de la liste déroulante de votre tenant, vous devez utiliser la pour sélectionner cette application. Vous devez effectuer une requête PATCH :

​
En savoir plus