CIAM 101 : Authentification, Identité, SSO

Contexte#

J'ai commencé à construire Logto car j'ai remarqué que la Gestion des Identités et des Accès (IAM) était devenue de plus en plus complexe et étendue au fil du temps. Le concept d'IAM est même assez large pour donner naissance à de nouveaux concepts, tels que WIAM (Workforce IAM) et CIAM (Customer IAM).

Bien que WIAM et CIAM partagent la même base, ils ont des cas d'utilisation distincts: WIAM est généralement utilisé pour les utilisateurs internes, tandis que CIAM est utilisé pour les clients externes. Quelques exemples :

• WIAM Votre entreprise dispose d'un système d'identité unifié pour les employés, ainsi chacun peut utiliser le même compte pour accéder aux ressources de l'entreprise, telles que les abonnements logiciels, les services de cloud computing, etc.
• CIAM Votre librairie en ligne nécessite un système d'identité utilisateur pour les clients et les vendeurs. L'expérience de connexion est une partie essentielle de l'intégration, car elle se situe au sommet de l'entonnoir de conversion.

Logto a commencé avec le CIAM pour diverses raisons (nous aurons un autre article à ce sujet). Pendant le développement, nous avons réalisé qu'avoir une compréhension unifiée au sein de l'équipe serait bénéfique avant de porter notre produit au niveau supérieur. Nous espérons que cela vous aidera également à mieux comprendre le paysage IAM.

Commençons !

Les bases du CIAM#

Dans cet article, nous nous concentrerons sur les concepts fondamentaux du CIAM et sur les problèmes que nous pourrions rencontrer pendant ou après le flux d'authentification. Nous aborderons également la connexion unique (SSO) et ses scénarios connexes.

Authentification et autorisation#

💡 L'authentification est initialement définie comme "Qui êtes-vous ?". Cependant, lorsqu'il s'agit d'identités numériques, il est plus précis de démontrer l'authentification en "prouvant la possession de l'identité". (Crédit à Calm-Card-2424)

Si vous découvrez quelque chose qui ne rentre pas dans l'une de ces deux catégories, il est probable qu'il ne soit pas essentiel à l'activité des identités.

• Exemples pour l'authentification
  • Connexion par mot de passe, connexion sans mot de passe, connexion sociale, etc.
  • Authentification Machine-à-Machine
• Exemples pour l'autorisation
  • Contrôle d'accès basé sur les rôles
  • Contrôle d'accès basé sur les attributs
• Exemples pour les exceptions
  • Données non-identitaires
  • Web hooks

Identité et Locataire#

L'identité représente généralement un utilisateur ou une machine. Après une authentification réussie, un jeton ID est émis en tant qu'identité.

En d'autres termes, le principal objectif de l'authentification est d'obtenir une identité.

Un locataire est un groupe d'identités :

Lorsque nous parlons de "multi-locataire", nous faisons référence à plusieurs instances Logto qui sont isolées au niveau des identités les unes des autres. En d'autres termes, plusieurs instances Logto.

Notez qu'il y a deux systèmes d'identités isolés, c'est-à-dire que vous ne pouvez pas utiliser l'Identité du Locataire 1 dans le Locataire 2, même pour le même identifiant (e-mail, téléphone, etc.). C'est comme si votre abonnement à Costco n'était pas valide chez Whole Foods.

Application et Locataire#

Tout comme l'identité, une application appartient également à un locataire. Quelques points à se rappeler :

• Il n'y a généralement pas de relation directe entre une application et une identité.
  • Une identité peut représenter une application, mais il n'y a pas de connexion directe entre elles.
• Comme les utilisateurs, les applications sont également au niveau des locataires.
• Les applications sont du code, tandis que les utilisateurs sont humains.
• Le seul objectif des applications est de terminer l'authentification, c'est-à-dire d'obtenir une identité.

Fournisseur d'identité (IdP) et fournisseur de services (SP)#

La différence entre ces deux fournisseurs est subtile mais importante.

• Fournisseur d'identité est un service qui fournit l'authentification (AuthN) et délivre des identités.

Vous pouvez trouver diverses explications sur le fournisseur de services de Google, bien qu'elles puissent ne pas être satisfaisantes. Dans mon esprit, le fournisseur de services est un concept relatif :

• Fournisseur de services (ou Partie de confiancet dans OIDC) est un service ou un client qui initie l'authentification (AuthN) et demande le résultat aux Fournisseurs d'identité.

Quiz#

Considérez un scénario typique de connexion sociale :

❓ Combien de Fournisseurs de services et de Fournisseurs d'identité dans ce graphique ?

Réponse

Les deux ont deux. L'application iOS est un fournisseur de services pour Logto, tandis que Logto est un fournisseur d'identité. Logto est aussi un fournisseur de services pour GitHub, tandis que GitHub est un fournisseur d'identité. Ainsi, Logto est à la fois un fournisseur de services et un fournisseur d'identité.

Étude de cas : Une entreprise de solutions technologiques#

Vous êtes directeur technique d'une entreprise de solutions technologiques, vous avez plus de 100 partenaires commerciaux et vous avez livré plus de 300 projets.

• Chaque projet est soit une application web soit une application mobile avec un service backend.
• Pour chaque partenaire commercial, vous souhaitez réorganiser le système utilisateur pour fournir le SSO entre ses projets.

❓ Comment Logto (ou un produit CIAM) peut-il aider ?

Réponse

Créez une instance Logto pour chaque partenaire commercial. Chaque partenaire détient un Locataire. Les projets sont mappés à "Apps" dans Logto.

Logto offre une expérience de connexion universelle (c'est-à-dire le SSO) au sein d'un Locataire, donc les utilisateurs n'ont pas besoin de se reconnecter lorsqu'ils accèdent à une autre application dans le même Locataire s'ils sont déjà connectés.

Ce que nous entendons par SSO#

Nous avons constaté que le terme "SSO" cause souvent de la confusion. Nous considérons la connexion unique (SSO) comme un comportement, non un concept commercial. Par conséquent, SSO n'équivaut pas à "SSO dans WIAM".

Lorsque nous disons "il faut le SSO", cela peut faire référence à l'un des cas suivants :

Cas SSO 1#

👉🏽 Dans une grande entreprise, les employés utilisent les mêmes identifiants pour se connecter à toutes les ressources sous licence de l'entreprise (par exemple, e-mail, IM, services cloud).

C'est le scénario typique de WIAM. Dans ce cas, seul un Fournisseur d'identité est impliqué. Nous ne nous intéressons pas actuellement.

Cas SSO 2#

👉🏽 Les utilisateurs finaux utilisent les mêmes identifiants pour se connecter à tous les services développés par la même entreprise (par exemple, GSuite).

Logto se concentre actuellement sur l'approche décrite ci-dessus. Plusieurs fournisseurs d'identité externes, tels qu'un fournisseur de connexion sociale tiers, peuvent exister indépendamment et sans lien.

Malgré cela, Logto reste la source unique de vérité pour les identités, simplement "empruntées" à d'autres fournisseurs. Dans ce cas, Logto agit à la fois comme un Fournisseur d'identité (pour les applications GSuite) et comme un Fournisseur de services (pour les Fournisseurs d'identité externes).

Cas SSO 3#

👉🏽 Les utilisateurs finaux ne peuvent utiliser que le Fournisseur d'identité spécifique à leur domaine de messagerie pour effectuer l'authentification. Par exemple, se connecter à Figma avec Google Workspace.

C'est le cas d'utilisation le plus courant de SSO dans CIAM. Regardons cela de plus près.

Si nous voulons nous connecter à Figma en utilisant notre adresse email @silverhand.io, nous pouvons utiliser soit la connexion sociale soit le SSO. Les figures ci-dessous illustrent la différence entre les deux :

En mots :

• Après la connexion sociale, les utilisateurs peuvent librement définir un mot de passe ou changer l'adresse e-mail dans Figma
• Après le SSO, les utilisateurs ne peuvent pas définir de mot de passe ou modifier les informations personnelles, y compris l'adresse e-mail, car leurs Identités sont gérées par Google Workspace

Dans ce cas, Logto est à la fois un Fournisseur d'identité et un Fournisseur de services. Il semble que le SSO soit plus complexe qu'un processus de connexion normal. Quels sont les avantages pour le propriétaire de l'identité ?

• Contrôle centralisé : Garder les informations d'identité et les processus d'authentification en un seul endroit, et s'assurer que les informations utilisateur sont toujours à jour. Il n'est pas nécessaire d'ajouter et de supprimer des licences à travers différentes applications en cas de changements.
• Amélioration de l'expérience utilisateur : Les propriétaires d'identité qui nécessitent le SSO sont généralement des entreprises. Leurs employés peuvent utiliser les mêmes identifiants et session partagée pour les applications entre entreprises, telles que Figma, Zoom, Slack, etc.
• Sécurité renforcée : Vous avez peut-être remarqué que certaines entreprises requièrent des méthodes de connexion spécifiques, telles que les codes de vérification dynamiques. L'utilisation du SSO peut garantir que chaque employé utilise la même combinaison de méthodes de connexion pour accéder à toutes les ressources.

🤔 Intelligent comme vous, vous avez dû remarquer qu'il s'agit en fait du Cas SSO 1 du point de vue SaaS.

Il est temps de discuter du "X" dans le graphique SSO. Cela représente le processus par lequel Figma connecte le domaine de l'e-mail à un Fournisseur d'identité spécifique. Mais, comment cela fonctionne-t-il ?

Mappage SSO#

Étant donné que la demande provient souvent de clients d'entreprise, nous appelons le processus de "Cas SSO 3" de la section précédente "SSO d'entreprise" pour plus de clarté.

Nous pouvons facilement concevoir une solution naïve : créer un mappage entre les domaines d'e-mail et les méthodes de SSO, puis le mettre à jour manuellement.

L'action du processus "X" est maintenant claire :

🔍 Retrouver la méthode SSO d'entreprise mappée du domaine d'e-mail donné

Ainsi, si vous configurez silverhand.io comme un domaine d'e-mail valide qui se connecte à une URL SSO de Google Workspace, les utilisateurs qui tentent de se connecter avec un e-mail @silverhand.io seront redirigés vers la page de connexion Google Workspace correspondante, au lieu d'être traités sur place.

Lorsque vous n'avez que quelques dizaines de clients qui ont besoin du SSO d'entreprise, gérer manuellement le mappage est correct. Cependant, il y a plus de considérations à prendre en compte :

1. Que faire s'il y a des centaines ou des milliers de clients SSO d'entreprise ?
2. Quelle est la relation entre les "utilisateurs normaux" et les "utilisateurs SSO d'entreprise" ?
3. Les données doivent-elles être isolées entre les différents clients SSO d'entreprise ?
4. Y a-t-il besoin de fournir un tableau de bord pour les administrateurs SSO d'entreprise afin de voir les utilisateurs actifs, les journaux d'audit, etc. ?
5. Comment les comptes peuvent-ils être automatiquement désactivés lorsqu'un utilisateur est supprimé du Fournisseur d'identité SSO d'entreprise ?

Et bien plus encore. Comme presque tous les SSO d'entreprise sont basés sur le domaine de l'e-mail, nous pouvons rapidement trouver une meilleure solution :

• Si l'utilisateur peut prouver la propriété de ce domaine, il peut configurer le SSO d'entreprise de ce domaine de manière autonome.

Cette solution résout les deux premières questions :

1. Que faire s'il y a des centaines ou des milliers de clients SSO d'entreprise ?

• Ils peuvent configurer le SSO d'entreprise de manière autonome.

2. Quelle est la relation entre les "utilisateurs normaux" et les "utilisateurs SSO d'entreprise" ?

• Nous ouvrons toutes les méthodes de connexion possibles aux utilisateurs normaux sauf le SSO d'entreprise ; tandis que nous limitons la méthode de connexion au SSO d'entreprise uniquement aux utilisateurs qui tentent de se connecter avec les domaines configurés.

Quant à la troisième question :

3. Faut-il isoler les données entre différents clients SSO d'entreprise ?

• Oui et non. Il est temps d'introduire l'organisation.

Organisation#

Nous avons mentionné l'utilisation des domaines d'e-mail pour reconnaître la méthode SSO d'entreprise spécifique à utiliser ; en d'autres termes, appliquer un traitement spécifique à un lot particulier d'utilisateurs.

Cependant, les exigences des clients vont souvent au-delà du seul SSO d'entreprise ; par exemple, les questions 4 et 5 de la section précédente. Au fil des ans, un modèle mature a été développé par des entreprises SaaS exceptionnelles pour résoudre ce genre de problèmes : les Organisations.

Règles des Organisations

1. Une organisation est un groupe d'identités, généralement plus petit qu'un Locataire.
2. Toutes les organisations sont associées à un Locataire.

Vous pouvez voir d'autres termes, tels que "Workspace", "Équipe", ou même "Locataire" dans le logiciel. Pour identifier si c'est le concept dont nous discutons, vérifiez simplement s'il représente "un groupe d'identités".

Dans cet article, nous utiliserons le terme "Organisation" pour plus de cohérence.

Dans Notion, vous pouvez créer et rejoindre plusieurs espaces de travail (c'est-à-dire les Organisations) avec la même adresse email et basculer facilement entre eux.

Pour Slack, ça semble être pareil, mais nous soupçonnons qu'il utilise différentes Identités en coulisses puisque nous devons créer un nouveau compte pour chaque espace de travail.

Notion a un "Plan Personnel" disponible, qui est normalement une Organisation sous-jacente, avec le seul utilisateur (vous) à l'intérieur. Nous ne connaissons pas l'implémentation exacte de Notion, mais cette explication est raisonnable et archivable pour notre modèle.

Chaque Organisation a également un identifiant, généralement appelé "domaine de l'Organisation".

Quiz#

❓ Une application peut-elle être associée à une Organisation ?

Réponse

Oui, tout à fait. Comme nous l'avons discuté au début, une application peut avoir une Identité. Pouvez-vous élaborer un scénario commercial de cela ?

Questions en suspens#

3. Les données doivent-elles être isolées entre les différents clients SSO d'entreprise ?

• Oui : Isoler les données commerciales, telles que les messages et les documents, au niveau de l'Organisation.
• Non : Conserver les Identités indépendantes, puisqu'elles n'ont pas besoin d'être associées à une Organisation.
• Notez qu'il y a trois entités distinctes impliquées ici : les Identités, les Organisations, et les configurations Enterprise SSO ; ce qui a considérablement augmenté la complexité. La question elle-même n'est pas assez spécifique.

4. Y a-t-il besoin de fournir un tableau de bord pour les administrateurs SSO d'entreprise afin de voir les utilisateurs actifs, les journaux d'audit, etc. ?

5. Comment désactiver automatiquement le compte lorsqu'un utilisateur est supprimé du Fournisseur d'identité SSO d'entreprise ?

• Ces demandes sont plus orientées vers les affaires et peuvent être mises en œuvre au niveau de l'Organisation. Nous les laissons ouvertes ici.

Notes finales#

Nous avons introduit plusieurs concepts : Authentification (AuthN), Autorisation (AuthZ), Identité, Locataire, Application, Fournisseur d'identité (IdP), Fournisseur de services (SP), Connexion unique (SSO), et SSO d'Entreprise (Organisation). Cela peut prendre du temps pour tout comprendre.

En écrivant cet article, j'ai remarqué qu'intéressamment, les plans en ligne les plus coûteux incluent souvent des fonctionnalités exclusives liées à l'autorisation, qui ne sont absolument pas mentionnées dans cet article. Vous avez peut-être déjà quelques questions sur l'autorisation, telles que :

• Comment pouvons-nous attribuer des permissions à un utilisateur et les vérifier ?
• Quel modèle d'autorisation devrais-je utiliser ?
• Quelle est la meilleure pratique pour appliquer un modèle d'autorisation ?