Configurer l’authentification unique initiée par le fournisseur d’identité SAML

De nombreuses instructions pour la mise en place d’une fédération SAML commencent par l’authentification unique (SSO) initiée par le fournisseur de services. Le fournisseur de services redirige l’utilisateur vers le fournisseur d’identité (IdP) à des fins d’authentification. Ce processus est couramment utilisé pour les scénarios orientés vers le consommateur.

Cependant, dans les scénarios d’entreprise, il est parfois courant de commencer par l’IdP qui initie le SSO au lieu du fournisseur de services. Par exemple, une entreprise peut mettre en place un portail pour s’assurer que les utilisateurs accèdent à l’application voulue une fois connectés au portail.

Les flux initiés par IdP présentent un risque de sécurité et ne sont donc pas recommandés. Nous vous recommandons d’utiliser, dans la mesure du possible, des flux initiés par le fournisseur de services.

Assurez-vous de bien comprendre les risques avant d’activer une authentification unique (SSO) initiée par un fournisseur d’identité (IdP). Dans ce scénario, Auth0 reçoit la réponse non sollicitée du fournisseur d’identité 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 démarré le flux. Pour cette raison, l’activation de ce flux augmente la possibilité d’une attaque CSRF par connexion, où un attaquant peut amener un utilisateur légitime à se connecter à l’application à son insu avec l’identité de l’attaquant.

OpenID Connect (OIDC) ne prend pas en charge le concept de flux initié par le fournisseur d’identité. Ainsi, si Auth0 offre la possibilité de traduire un flux initié par IdP SAML (à partir d’une connexion SAML) en une réponse OIDC pour une application, n’importe quelle application qui met correctement en œuvre le protocole OIDC/OAuth2 rejettera une réponse non demandée.

Lorsque vous utilisez des applications OIDC, la meilleure solution consiste à demander à votre application de créer un point de terminaison de connexion. Le seul objectif de ce point de terminaison est d’initier la redirection vers le fournisseur d’identité (votre locataire Auth0).

Si vous utilisez plusieurs fournisseurs d’identité, assurez-vous que le point de terminaison de connexion est spécifique au fournisseur d’identité ou qu’il peut accepter un paramètre permettant d’identifier le fournisseur d’identité qui initie le flux de travail.

Une autre approche consiste à demander aux utilisateurs de démarrer le flux de connexion au niveau de l’application.

Lorsque vous utilisez le SSO initié par le fournisseur d’identité, assurez-vous d’inclure le paramètre de connexion dans l’URL de post-back :

https://{yourDomain}/login/callback?connection={yourConnectionName}

Si vous utilisez la fonctionnalité Organizations, vous pouvez éventuellement inclure un paramètre d’organization contenant l’ID de l’organization souhaitée :

https://{yourDomain}/login/callback?connection={yourConnectionName}&organization={yourCustomersOrganizationId}

Si votre application est de type monopage et 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 le fournisseur d’identité, ce qui expose l’application à d’éventuelles attaques CSRF par connexion.

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

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

Si vous utilisez Lock, vous pouvez inclure l’indicateur en utilisant le paramètre options envoyé au constructeur.

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

L’indicateur est le suivant :

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.

1. Accédez à Dashboard > Authentification > Entreprise et choisissez SAMLP Identity Provider (Fournisseur d’identité SAMLP).

2. Sous Settings (Paramètres), vous pouvez voir la configuration de l’authentification unique initiée par un fournisseur d’identité.

   

• Comportement d’authentification unique initié par un fournisseur d’identité : cette option vous permet d’activer les connexions initiées par un fournisseur d’identité pour la connexion SAML. Sélectionnez Accept Requests (Accepter les demandes) et remplissez tous les champs requis.

• Application par défaut : lorsque la connexion initiée par IdP réussit, les utilisateurs sont acheminés vers cette application. Ce paramètre affiche les applications disponibles activées pour cette connexion. Sélectionnez dans le menu déroulant l’application pour laquelle vous souhaitez que les utilisateurs se connectent à l’aide du fournisseur d’identité. Une seule application peut être sélectionnée pour une connexion initiée par un fournisseur d’identité 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, la configuration des applications se fait avec le protocole OpenID Connect (voir ci-dessus). Cependant, si vous avez configuré un module complémentaire SAML2 Web App pour votre application et que vous souhaitez acheminer l’assertion SAML, vous devez sélectionner SAML. Une fois qu’une assertion SAML valide a été transmise à l’URL de publication, 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, qui peut être modifié à l’aide du champ Chaîne de requête pour indiquer un redirect_uri si vous utilisez OIDC.

• Chaîne de requête : les options de la chaîne de requête permettent de personnaliser le comportement lorsque le protocole OpenID Connect est utilisé. Vous pouvez définir plusieurs options de la même manière que pour les paramètres d’une chaîne de requête. Vous pouvez définir :

  Paramètre

  Description

  redirect_uri

  Lorsque la connexion initiée par l’IdP est terminée, la demande est ensuite redirigée vers la première URL répertoriée dans les URL de rappel autorisées pour l’application. Cependant, si vous définissez un redirect_uri, l’IdP redirigera vers cette URL. Cela ajoute de la flexibilité au cas où, par exemple, vous avez un schéma de sous-domaine défini avec un caractère générique et que vous souhaitez uniquement rediriger vers un sous-domaine spécifique.

  | scope | Définit les permissions du jeton d’ID envoyé. Vous pouvez définir plusieurs permissions. | | response_type | Définir le jeton pour le Flux d’autorisation implicite pour applications à page unique. Vous pouvez définir le code pour le flux de code d’autorisation pour les applications web classiques. |

  Dans un flux initié par IdP, les serveurs Auth0 suppriment les permissions dans un jeton si l’URL de rappel correspond à un domaine non vérifié. Auth0 définit 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 renverront une réponse vide. Pour obtenir une réponse de jeton avec les permissions demandées, utilisez un domaine vérifié.

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

Si vous souhaitez sélectionner une application comme application par défaut dans l’authentification unique (SSO) initiée par un fournisseur d’identité (IdP), et que l’application ne figure pas dans les 100 premières applications répertoriées dans la liste déroulante de votre locataire, vous devez utiliser Management API pour sélectionner cette application. Vous devez exécuter un correctif :

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

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