IdP-initiated SSO (SAML uniquement)

L'authentification unique (SSO) initiée par l'IdP est un processus d'authentification unique où le fournisseur d'identité (IdP) contrôle principalement le flux d'authentification. Ce processus commence lorsqu'un utilisateur se connecte à la plateforme de l'IdP, telle qu'un portail d'entreprise ou un tableau de bord d'identité centralisé. Une fois authentifié, l'IdP génère une assertion SAML et dirige l'utilisateur vers le fournisseur de services (SP) pour accéder à l'application ou au service.

Risques et considérations

L'authentification unique initiée par l'IdP peut introduire plusieurs vulnérabilités de sécurité dont les organisations doivent être conscientes. Étant donné que le processus d'authentification est initié par l'IdP sans demande directe de l'utilisateur, il peut être susceptible à diverses attaques, y compris Cross-Site Request Forgery (CSRF).

Cette absence d'authentification initiée par l'utilisateur peut conduire à un accès non autorisé si des mesures de protection appropriées ne sont pas en place. De plus, la dépendance à un point unique d'authentification augmente le risque de violation de sécurité, car compromettre l'IdP pourrait exposer toutes les applications connectées.

Il est donc fortement recommandé d'utiliser l'authentification unique initiée par le SP, qui offre un flux d'authentification plus sécurisé et contrôlé, garantissant que les utilisateurs demandent explicitement l'accès aux services.

Connecter l'authentification unique initiée par l'IdP avec les applications Logto OIDC

Logto en tant que fournisseur OpenID Connect (OIDC) ne prend pas en charge l'authentification unique initiée par l'IdP. Cependant, vous pouvez configurer Logto en tant que SP pour prendre en charge l'authentification unique initiée par l'IdP avec votre IdP d'entreprise en utilisant SAML. Cette configuration vous permet de tirer parti des capacités d'authentification de Logto tout en maintenant le contrôle de l'IdP sur le flux d'authentification.

remarque

Par défaut, cette fonctionnalité n'est pas activée dans Logto. Si vous avez besoin que l'authentification unique initiée par l'IdP soit activée pour votre locataire, veuillez contacter notre équipe de support.

Prérequis

Avant de configurer l'authentification unique initiée par l'IdP, vous devez d'abord créer un connecteur SAML. Accédez à la Console > SSO d'entreprise et suivez le guide étape par étape pour configurer un connecteur SAML avec votre IdP.

Une fois le connecteur SAML configuré, vous pouvez activer la méthode de connexion SSO dans la section Expérience de connexion et tester le flux SSO initié par le SP pour vous assurer que la configuration est correcte. Assurez-vous que le SSO initié par le SP fonctionne comme prévu avant de passer à l'authentification unique initiée par l'IdP.

Activer l'authentification unique initiée par l'IdP

Une fois la fonctionnalité d'authentification unique initiée par l'IdP activée pour votre locataire, vous devriez voir un onglet supplémentaire dans la page des paramètres de votre connecteur SAML, appelé IdP-initiated SSO. Activez le bascule IdP-initiated SSO pour activer la fonctionnalité pour le connecteur.

Sélectionner l'application SP

Contrairement à l'authentification unique initiée par le SP, où le flux d'authentification commence à partir du SP, l'authentification unique initiée par l'IdP nécessite une application SP côté client pour rediriger les utilisateurs après le processus d'authentification. Vous pouvez sélectionner l'application SP dans la liste des applications enregistrées dans le menu déroulant Application par défaut.

Seules les applications Traditional Web App et Single Page App sont prises en charge pour l'authentification unique initiée par l'IdP. Assurez-vous de sélectionner le type d'application approprié en fonction de votre cas d'utilisation.

remarque

Du côté de votre IdP, laissez le paramètre RelayState à EMPTY pour que le flux d'authentification unique initiée par l'IdP fonctionne correctement. Logto gérera la redirection en fonction de l'application SP par défaut sélectionnée.

Configurer le flux d'authentification initié par l'IdP

Afin de connecter l'authentification unique SAML initiée par l'IdP avec OIDC, Logto propose deux options de configuration pour gérer la requête d'authentification.

Option A : Rediriger vers l'application SP par défaut (Recommandé)

Lorsque l'IdP initie le flux SSO et envoie l'assertion SAML à Logto, une session d'assertion SSO initiée par l'IdP sera créée. Logto redirigera l'utilisateur vers l'application SP par défaut pour initier une requête d'authentification OIDC standard côté client.

Pour configurer cette option, sélectionnez la carte Rediriger vers le client pour l'authentification initiée par le SP dans l'onglet IdP-initiated SSO des paramètres du connecteur SAML.

1. Fournissez une URL de redirection client pour rediriger l'utilisateur vers l'application SP par défaut après le flux SSO initié par l'IdP. Logto redirigera l'utilisateur vers cette URL avec le paramètre de requête ?ssoConnectorId={connectorId} ajouté à l'URL. L'application cliente doit gérer la redirection et initier la requête d'authentification OIDC. (Nous recommandons d'utiliser une route ou une page dédiée dans votre application cliente pour gérer la requête d'authentification SSO initiée par l'IdP.)

2. Gérez la requête d'authentification OIDC côté client en utilisant le paramètre de requête ssoConnectorId pour identifier le connecteur SAML qui a initié le flux d'authentification SSO initié par l'IdP.

3. Passez le paramètre d'authentification connexion directe dans la requête de connexion à Logto pour compléter le flux d'authentification SSO.

// Exemple React
import { Prompt, useLogto } from '@logto/react';
import { useEffect } from 'react';
import { useNavigate, useSearchParams } from 'react-router-dom';

const SsoDirectSignIn = () => {
  const { signIn } = useLogto();
  const [searchParams] = useSearchParams();

  useEffect(() => {
    const ssoConnectorId = searchParams.get('ssoConnectorId');
    if (ssoConnectorId) {
      void signIn({
        redirectUri,
        prompt: Prompt.Login,
        directSignIn: {
          method: 'sso',
          target: ssoConnectorId,
        },
      });
    }
  }, [searchParams, signIn]);
};

• redirectUri: L' redirect_uri pour rediriger l'utilisateur après la fin du flux d'authentification OIDC.
• prompt=login: Force l'utilisateur à se connecter en utilisant l'identité SSO initiée par l'IdP.
• directSignIn=sso:{connectorId}: Spécifie la méthode de connexion directe comme sso et l'ID du connecteur SAML cible. Ce paramètre déclenchera directement le flux d'authentification SSO sans afficher la page de connexion. L'utilisateur sera automatiquement authentifié en utilisant la session d'assertion SSO initiée par l'IdP préservée si l'ID du connecteur correspond et que la session est valide.

Cette méthode garantit que le flux d'authentification est sécurisé et suit le protocole OIDC standard, tout en maintenant le contrôle de l'IdP sur le processus d'authentification. L'application cliente peut tirer parti de la session d'assertion SSO initiée par l'IdP pour authentifier l'utilisateur sans étapes de connexion supplémentaires, tout en gardant le flux d'authentification sécurisé et contrôlé. L'application cliente peut toujours valider les paramètres state et PKCE pour s'assurer que la requête d'authentification est sécurisée.

remarque

Cette méthode est disponible pour les applications Traditional Web App et Single Page App. Et elle est recommandée pour tous les cas d'utilisation.

Option B : Authentifier directement l'utilisateur avec l'authentification unique initiée par l'IdP

Dans certaines circonstances, le SP peut ne pas être en mesure de gérer le rappel SSO initié par l'IdP et d'initier la requête d'authentification OIDC. Dans ce cas, Logto propose une option alternative pour authentifier directement l'utilisateur avec la session d'assertion SSO initiée par l'IdP.

Cette option est considérée comme moins sécurisée et n'est pas recommandée. Le flux d'authentification contourne le protocole OIDC standard. Étant donné que la requête d'authentification est initiée par l'IdP, l'application cliente peut ne pas être en mesure de valider la requête d'authentification de manière sécurisée. Par exemple, l'application cliente ne peut pas valider les paramètres state et PKCE pour s'assurer que la requête d'authentification est sécurisée.

attention

Cette méthode n'est pas disponible pour les applications Single Page App, car elle nécessite que l'application cliente gère la requête d'authentification de manière sécurisée en utilisant le paramètre PKCE. Si vous devez implémenter l'authentification unique initiée par l'IdP pour une application SPA, veuillez utiliser l'option ci-dessus à la place.

Pour configurer cette option, sélectionnez l'option Connexion directe en utilisant l'authentification unique initiée par l'IdP dans l'onglet IdP-initiated SSO des paramètres du connecteur SAML.

1. Sélectionnez l' URI de redirection après connexion pour rediriger l'utilisateur vers l'application cliente après une authentification réussie. Cette URL sera utilisée comme redirect_uri dans la requête d'authentification OIDC. L'URI doit être l'une des URIs de redirection autorisées enregistrées dans l'application cliente.

   remarque

   Il est fortement recommandé d'utiliser une URI de redirection dédiée pour l'authentification unique initiée par l'IdP. Étant donné que la requête d'authentification est non sollicitée, l'application cliente doit gérer la réponse de manière indépendante, séparément du flux d'authentification standard initié par le SP.

2. Personnalisez les paramètres de la requête d'autorisation si nécessaire en utilisant l'éditeur json Paramètres d'authentification supplémentaires (suivant le type Map<string,string>).

   Par exemple, par défaut Logto ne demande que les portées openid et profile. Vous pouvez ajouter des portées ou des paramètres supplémentaires à la requête d'authentification.

   {
     "scope": "email offline_access"
   }
   • ajouter la portée supplémentaire email pour demander l'adresse e-mail de l'utilisateur.
   • ajouter la portée offline_access pour demander le jeton de rafraîchissement.

   Nous vous recommandons également de fournir un paramètre state personnalisé pour valider la réponse d'authentification de manière sécurisée.

   {
     "state": "custom-state-value"
   }

   L'application cliente doit valider le paramètre state dans la réponse du code d'autorisation pour s'assurer que la requête d'authentification est valide.