Identités externes

Cet article fournit des informations supplémentaires concernant l'utilisation des identités externes avec Identity-Aware Proxy (IAP) à la place des comptes Google.

Présentation

IAP contrôle l'accès à vos applications App Engine et Compute Engine qui s'exécutent sur Google Cloud. Il détermine si un utilisateur doit être autorisé à y accéder en fonction de son identité et du contexte d'une requête. Ce service est la pierre angulaire de BeyondCorp, un modèle de sécurité d'entreprise qui permet aux employés de travailler sur des réseaux non approuvés sans passer par un VPN.

Par défaut, IAP utilise les identités Google et IAM. En exploitant Identity Platform à la place, vous pouvez authentifier les utilisateurs avec un large éventail de fournisseurs d'identité externes, par exemple :

Adresse e-mail/Mot de passe
OAuth (Google, Facebook, Twitter, GitHub, Microsoft, etc.)
SAML
OIDC
N° de téléphone
Personnalisé
Anonyme

Cela s'avère utile si votre application utilise déjà un système d'authentification externe, et si la migration de vos utilisateurs vers des comptes Google s'avère problématique.

Architecture mutualisée

À l'origine, l'architecture mutualisée d'Identity Platform a été conçue pour les scénarios B2B, où une entreprise vend un service à d'autres entreprises. Dans ce cas, il est fréquent que les développeurs souhaitent séparer les populations d'utilisateurs dans des pools isolés. Ces silos sont appelés locataires.

Considérons le schéma de relations fictives ci-dessous :

Hiérarchie mutualisée

Dans cet exemple, Acme est un constructeur automobile (l'agent) qui utilise Identity Platform pour fournir un service à des concessionnaires (les locataires). Ces concessionnaires fournissent à leur tour des services à leurs clients, employés et sous-traitants. Bien que le constructeur automobile soit propriétaire du service, chaque concessionnaire peut utiliser son propre ensemble de fournisseurs d'identité pour l'authentification. Les données et les sessions utilisateur sont limitées à un locataire. Par conséquent, si un utilisateur a des relations avec plusieurs concessionnaires, chacune est gérée indépendamment.

En fonction de votre cas d'utilisation, vous pouvez structurer votre hiérarchie de locataires de plusieurs façons.

Aucun locataire

Vous n'avez besoin de l'architecture mutualisée que si vous devez isoler des ressources. Cela n'est pas obligatoire pour toutes les applications. Par exemple, si vous possédez une seule application App Engine et que vous souhaitez bloquer l'accès pour tous les utilisateurs extérieurs à votre réseau, il n'est pas nécessaire de recourir à l'architecture mutualisée. Par défaut, Identity Platform stocke et authentifie les utilisateurs par projet. Par conséquent, aucune configuration supplémentaire n'est requise dans ce cas.

Un autre exemple concerne un conglomérat composé de plusieurs filiales. Même si chaque filiale dispose de son propre système d'authentification géré (utilisant OIDC ou SAML), tous les employés peuvent bénéficier des mêmes avantages généraux, par exemple en ce qui concerne les soins de santé, les vacances et la paie. Dans ce cas, l'authentification au niveau du projet est suffisante.

Un locataire par ressource

Par défaut, les jetons Identity Platform non locataires sont valides au niveau du projet. En théorie, cela signifie qu'un utilisateur peut s'authentifier auprès d'une ressource IAP, puis utiliser le jeton pour accéder à un autre service du même projet. Cela représente un risque pour la sécurité.

Pour éviter toute fuite de jeton, isolez chaque ressource IAP en attribuant à chacune son propre locataire. Les jetons générés dans un contexte propre à un locataire ne sont valides que pour ce locataire spécifique. Si l'utilisateur tente d'accéder à une autre ressource IAP utilisant un locataire différent, il est invité à s'authentifier de nouveau.

Plusieurs locataires par ressource

Une même ressource IAP peut être associée à plusieurs locataires.

Lorsqu'un utilisateur accède à la ressource, vous disposez de plusieurs options pour déterminer le locataire à utiliser. Par exemple, vous pouvez inviter l'utilisateur à saisir d'abord son adresse e-mail, puis à localiser de manière automatisée un locataire correspondant au domaine de l'adresse e-mail. Vous pouvez également afficher une UI répertoriant tous les locataires valides, puis demander à l'utilisateur d'en choisir un.

Les utilisateurs peuvent appartenir à plusieurs locataires ayant différents niveaux d'accès. Bien que vous ne puissiez pas utiliser IAM pour gérer le contrôle des accès avec des identités externes, le jeton Web JSON généré par IAP porte les revendications du jeton d'ID Identity Platform, et l'application peut filtrer l'accès en fonction de ces revendications.

Prenons comme exemple d'architecture mutualisée une entreprise d'avantages sociaux dont de nombreux clients partagent un même portail Web. Lorsqu'un utilisateur accède au portail, il sélectionne d'abord son entreprise (le locataire), puis s'authentifie avec le fournisseur que son employeur utilise au moyen de ses identifiants professionnels.