Implémenter la multilocation dans Azure B2C / Blogs / Perficient

Aperçu

Dans un article précédent sur Azure B2C, nous avons discuté des bases d’Azure B2C et des raisons pour lesquelles vous pourriez envisager de l’utiliser pour votre logiciel ou votre application. Voyons maintenant quelques exemples des cas d’utilisation les plus courants.

Implémentation d’applications multi-locataires avec Azure B2C

La multilocation est un modèle d’architecture dans lequel une seule instance ou le déploiement d’une application logicielle dessert plusieurs clients. Chaque client est appelé locataire. Les locataires peuvent avoir la possibilité de personnaliser certaines parties de leur application, telles que la couleur de l’interface utilisateur ou certaines règles métier, mais ils ne peuvent pas personnaliser le code principal de l’application. Ceci est très répandu dans les entreprises SaaS et les scénarios de type Business to Business.

Vous trouverez ci-dessous une démonstration étape par étape de la mise en œuvre de la multilocation dans un exemple d’application. Le modèle lui-même est applicable à la plupart des piles technologiques, mais pour cette démo, j’ai utilisé un serveur Node.Js/Express pour le backend et une application React statique pour le frontend.

Architecture multi-locataires

Étape 1 : configurer l’annuaire Azure B2C

La première étape pour implémenter votre application mutualisée consiste à configurer un annuaire Azure B2C. Azure B2C utilise également le terme « Tenant » pour décrire un seul répertoire d’utilisateurs, ce qui peut prêter à confusion lorsque vous créez des applications multi-Tenant où le terme « Tenant » fait référence aux clients du système. Par souci de clarté, nous utiliserons donc le terme « Annuaire » pour désigner l’instance Azure B2C et « Tenants » désignera les clients de l’application qui vont interagir avec l’application en question.

Dans la plupart des cas, il est conseillé de n’utiliser qu’un (1) répertoire Azure Active Directory B2C pour l’environnement de production de votre application et un (1) répertoire pour votre ou vos environnements de non-production. Microsoft fournit une bonne documentation ici. Les répertoires Azure B2C contiendront nos flux d’utilisateurs, nos politiques d’utilisateur personnalisées et les connexions à d’autres fournisseurs d’identité autorisés à se connecter à notre application.

Étape 2 : Configurer les inscriptions d’applications

Une fois notre répertoire B2C créé, il sera essentiellement vide – et nous devons commencer à remplir les informations pour les applications logicielles que nous prévoyons d’intégrer au fournisseur d’identité. Accédez au menu « App Registrations » dans Azure Active Directory et sélectionnez l’option permettant de créer de nouvelles inscriptions :

Créez une (1) inscription pour le backend de votre application.

Si votre logiciel a une architecture de microservices, vous pouvez choisir de diviser les enregistrements d’applications en un seul enregistrement par base de code OU de les centraliser sous un seul enregistrement. Dans la majorité des cas, il est plus facile de centraliser les applications backend sous un seul enregistrement

Créez plusieurs enregistrements de clients pour chaque « locataire », « client » ou « site » qui utilisera votre logiciel – par exemple, si votre application a Ford et General Motors comme deux groupes différents de clients accédant à votre site – chacun pourrait être fourni avec leur propre inscription

Étape 3 : Configurer les flux d’utilisateurs

Après avoir configuré les inscriptions de l’application, accédez au menu « Flux d’utilisateurs » dans Azure Active Directory et sélectionnez les options pour créer de nouveaux flux pour les scénarios requis (c’est-à-dire User SigIn/SignUp, Password Reset, etc.)

Si vous souhaitez que différents locataires aient des expériences utilisateur différentes pour l’un des processus communs (Connexion/Inscription, Réinitialisation du mot de passe, etc.), vous devrez créer des flux d’utilisateurs supplémentaires uniques pour ce client (par exemple, si un client autoriser les connexions sociales ou les connexions d’un autre fournisseur d’identité Oauth)

Étape 4 : Configurer les champs d’application de l’API d’application

Une fois les flux d’utilisateurs provisionnés et les inscriptions d’application créées, les inscriptions de serveur et de client doivent être connectées à différentes étendues disponibles pour chaque locataire.

Commencez par ouvrir l’enregistrement de l’application « Serveur » et utilisez le menu « Exposer une API » pour créer différentes portées pour chaque client autorisé à envoyer des requêtes aux API du serveur.

Créez différentes étendues selon les besoins en fonction du nombre de locataires différents et des types d’autorisations dont les différentes applications de locataire peuvent avoir besoin (par exemple, si le client 2 a une application de portail angulaire qui n’a besoin que de lire des données et également un client Web .NET MVC qui doit à la fois lire et écrire des données, créez deux portées différentes pour les deux applications clientes).

Une fois les étendues créées dans l’enregistrement de l’application serveur, utilisez le menu « Autorisations API » sur les enregistrements de l’application cliente pour attribuer les bonnes étendues aux différents locataires :

Étape 5 : Implémenter la validation des jetons d’API

Une fois que les autorisations et les étendues entre les inscriptions de l’application cliente et les serveurs/API ont été configurées, une logique peut être ajoutée à la base de code côté serveur pour valider les jetons envoyés à partir des applications locataires individuelles.

Toute bibliothèque de validation JWT de choix peut être sélectionnée pour valider l’émetteur du jeton ainsi que les champs d’audience sont définis correctement. Pour cet exemple, j’ai choisi le porteur express-oauth2-jwt bibliothèque qui permet aux utilisateurs de transmettre les valeurs d’audience et d’émetteur et la bibliothèque validera automatiquement le jeton par rapport aux paramètres :

La valeur de l’URL de l’émetteur indique que le jeton d’accès présenté au serveur est valide et émis par le locataire B2C. L’URL de l’émetteur est généralement au format : https://{Azure B2C Tenant Domain Name}.b2clogin.com/{Azure B2C Tenant GUID}/{User Flow That Generated the Identity Token}/v2.0/

La valeur Audience indique l’inscription de l’application pour laquelle le jeton d’accès a été généré – dans ce cas, le GUID de l’ID client d’inscription de l’application du serveur.
Si tous les clients utilisent un flux utilisateur de connexion similaire OU si des instances distinctes de la base de code du serveur sont déployées pour chaque locataire, l’émetteur et l’audience peuvent être définis en tant que variables d’environnement statiques.

Si, toutefois, les différents locataires auront des expériences de flux utilisateur différentes (par exemple, si le client 1 autorise une connexion Oauth ou sociale différente de celle des autres clients), les valeurs JWT Audience et Issuer peuvent être déplacées vers un fichier de configuration, comme indiqué ci-dessous :

Dans de tels cas, la validation du jeton doit être déplacée après la définition des itinéraires d’API afin qu’un identifiant de locataire ou de site puisse être extrait d’un paramètre d’itinéraire d’URL, d’un en-tête de demande ou d’un objet de corps de demande à utiliser pour sélectionner l’émetteur et l’audience appropriés. valeurs pour ce locataire :

Étape 6 : Configurer l’authentification basée sur le locataire dans la ou les applications frontales

Enfin, une fois que le serveur est prêt à valider les jetons, la dernière étape consiste à configurer la ou les applications clientes pour utiliser les flux appropriés et demander les jetons d’accès corrects en fonction du locataire donné. Lorsqu’une seule base de code est utilisée pour desservir plusieurs locataires différents, l’approche la plus courante consiste à utiliser différents sous-domaines pour chaque client unique.

L’exemple suivant utilise un assistant de sous-domaine pour analyser le sous-domaine à partir de l’URL active et le valider par rapport à une liste de locataires viables. Une fois l’ID de locataire identifié, les politiques de flux d’utilisateurs et les portées de jeton d’API appropriées peuvent être sélectionnées à partir des fichiers de configuration.

Cet exemple est celui d’une application cliente React utilisant le Bibliothèque d’authentification Microsoft pour les navigateursmais le motif doit être similaire quelle que soit la bibliothèque sélectionnée.

Avec cette dernière étape, l’architecture multi-locataire est réalisée ! La solution ci-dessus fournit des connexions flexibles pour différents locataires configurés via le code, la séparation des étendues d’API et différentes autorisations pour différents locataires, et des expériences utilisateur configurables pour chaque client lors de la connexion à la même application.