Architecture interentreprises

Bien comprendre votre application est essentiel pour savoir comment Auth0 peut être mis à profit pour répondre à vos besoins. D’après notre expérience, les clients qui réussissent le mieux commencent par une visualisation de l’architecture proposée — ou, dans bien des cas, de l’architecture existante — et s’en servent comme point de référence au fil de leur progression. Il est aussi important de comprendre comment votre application s’inscrit dans votre organisation; les Accounts and Tenants d’Auth0 constituent la base du regroupement et de la structuration des ressources Auth0, et il se peut que vous deviez tirer parti d’un déploiement Auth0 existant afin de vous intégrer au Single Sign-on (SSO), à la gestion centralisée des profils utilisateurs, à la facturation consolidée, ou à d’autres éléments du même genre. Le temps investi dès le départ pour définir l’architecture globale porte généralement ses fruits à long terme, et il y a plusieurs éléments à prendre en compte lorsque vous examinez les fonctionnalités et le workflow :

• À quoi devrait ressembler l’URL quand Auth0 doit présenter une page Web à un utilisateur ?
• Comment Auth0 peut-il être structuré pour prendre en charge votre SDLC (cycle de vie du développement logiciel) ?
• Comment pouvez-vous vous assurer que vos tenants Auth0 sont correctement associés à votre contrat ?
• Que devez-vous prendre en compte s’il existe d’autres projets dans votre organisation en intégration avec Auth0 ? En particulier des projets qui ciblent leur propre domaine d’utilisateurs, ou un domaine d’utilisateurs différent (par exemple, des applications que seuls les employés utiliseront) ?
• Comment pouvez-vous harmoniser la structure et le domaine de l’organisation de vos clients avec votre déploiement Auth0 ?

Les organisations servent souvent plus d’un domaine d’utilisateurs — clients, employés et affiliés étant les plus fréquemment rencontrés — avec généralement peu ou pas de chevauchement : les employés, par exemple, n’utilisent pas les mêmes applications que les clients, et vice-versa. Dans certains cas, il peut aussi être nécessaire de partitionner davantage à l’intérieur d’un domaine — des groupes distincts de clients, par exemple, qui utilisent des produits différents et sans lien entre eux. Auth0 offre un moyen de séparer vos utilisateurs et les éléments connexes associés, et le provisionnement de tenant traite cette question plus en détail. Si vous devez provisionner un tenant indépendant, vous voudrez aussi l’associer à votre compte Auth0 existant, afin de pouvoir profiter pleinement des avantages offerts par le niveau d’abonnement contractuel de votre organisation. De plus, vous aurez sans aucun doute déjà mis en place un ensemble de processus et de procédures dans le cadre de votre cycle de vie du développement logiciel (SDLC). Vous voudrez donc aussi consulter notre guide sur le soutien du SDLC concernant le provisionnement de tenant Auth0 à cet égard. Pour les applications destinées aux clients, nous constatons généralement qu’OpenID Connect (OIDC) est le protocole le plus fréquemment utilisé. OIDC s’appuie sur des workflows Web avec des URL de navigateur présentées à l’utilisateur. Par défaut, les URL destinées aux clients dans le cadre de la prise en charge d’OIDC par Auth0 portent l’image de marque d’Auth0; toutefois, nous recommandons d’utiliser la fonctionnalité de domaine personnalisé d’Auth0 afin d’offrir une image de marque cohérente et de répondre à d’éventuelles préoccupations des utilisateurs en matière de confiance avant qu’elles ne surgissent. Si certaines ou toutes les organisations de vos clients ont chacune besoin de leur propre URL personnalisée, ou si elles utilisent des fournisseurs d’identité sociale qui nécessitent une page de consentement personnalisée aux couleurs de l’organisation, nous vous recommandons de créer des tenants Auth0 distincts pour ces organisations; consultez provisionnement de tenant pour les organisations complexes pour plus de détails.

​

Provisionnement de tenant

Tout commence par un tenant Auth0. C’est là que vous configurerez votre utilisation d’Auth0 et que les ressources Auth0 — comme les Applications, les Connections et les profils utilisateur — sont définies, gérées et stockées. L’accès à un tenant Auth0 se fait au moyen du Dashboard d’Auth0, et à partir du Dashboard, vous pouvez aussi créer d’autres tenants associés; vous pouvez créer plus d’un tenant Auth0 afin de structurer vos tenants de manière à isoler différents domaines d’utilisateurs et à prendre en charge votre cycle de vie du développement logiciel (SDLC). Déterminer le niveau d’isolation dont vous avez besoin pour vos domaines d’utilisateurs est une étape importante et, combiné à vos exigences en matière d’image de marque, cela vous aidera ensuite à déterminer le nombre de tenants Auth0 nécessaires dans votre environnement de production. Comme nous vous recommandons de créer un ensemble complet de tenants prenant en charge le SDLC pour chaque tenant Auth0 que vous exploiterez dans un environnement de production, le nombre de tenants Auth0 à gérer peut rapidement augmenter. Vous devriez donc réfléchir attentivement avant de créer plusieurs tenants Auth0 pour la production et consulter nos conseils sur l’image de marque avant de prendre votre décision finale.

​

provisionnement de tenant pour les organisations complexes

Dans la plupart des cas, il n’est pas nécessaire de provisionner des tenants Auth0 distincts pour les organisations de vos clients. Cela est devenu encore plus simple avec le lancement de notre nouvelle fonctionnalité Organizations. Toutefois, dans certaines situations, cela peut s’avérer utile pour réduire la complexité de votre configuration. Par exemple, comme pratique exemplaire, nous recommandons de provisionner un tenant Auth0 distinct pour l’organisation de vos clients si :

• Les organisations de vos clients ont besoin d’une URL de connexion personnalisée qui leur est propre. C’est généralement le cas seulement si vous leur permettez d’avoir leur propre URL personnalisée au lieu d’utiliser une URL de connexion commune. Auth0 prend en charge un domaine personnalisé par tenant.
• Les organisations de vos clients utilisent des fournisseurs d’identité sociale pour la connexion. Dans ce cas, il est souvent souhaitable que l’organisation dispose d’une page de consentement personnalisée pour le fournisseur d’identité sociale, adaptée à son image de marque.

Si l’une ou l’autre de ces situations s’applique, nous recommandons de créer un tenant Auth0 distinct pour chaque organisation qui répond à l’un des critères ci-dessus.

​

Association de tenant

Pour vous assurer que vos tenants sont tous associés à votre entente contractuelle avec Auth0 et qu’ils disposent des mêmes fonctionnalités, assurez-vous que tous vos tenants sont associés au compte de votre entreprise. Si certains développeurs souhaitent créer leurs propres sandboxes à des fins de test, assurez-vous qu’ils sont eux aussi associés à votre compte afin d’avoir les mêmes permissions. Pour ce faire, vous devez communiquer avec votre représentant Auth0 ou le Auth0 Support Center.

​

Domaines personnalisés

Lorsque vous configurez votre tenant Auth0, l’URL permettant d’y accéder est de la forme https://{yourTenant}.auth0.com. Fournir un domaine personnalisé (aussi appelé URL personnalisée) pour votre tenant Auth0 est non seulement important pour respecter vos exigences en matière d’image de marque, mais vous procure aussi, et surtout, des avantages sur le plan de la sécurité :

• Par défaut, certains navigateurs compliquent la communication dans une iFrame si vous n’avez pas de domaine partagé. Par exemple, l’ITP de Safari entraîne des problèmes de renouvellement de token Auth0.
• Il est plus difficile d’hameçonner votre domaine si vous utilisez une URL personnalisée, puisque l’attaquant doit lui aussi créer une URL personnalisée pour imiter la vôtre. Par exemple, avec un domaine personnalisé, vous pouvez utiliser votre propre certificat pour obtenir une « validation étendue », ce qui complique encore davantage l’hameçonnage.

Votre nom de domaine personnalisé devrait aussi inspirer confiance aux utilisateurs en leur indiquant qu’il s’agit bien du bon endroit où saisir leurs identifiants. Nous vous recommandons également de créer votre domaine personnalisé dans tous les environnements dès le départ afin de vous assurer que vos tests sont cohérents d’un environnement à l’autre. Il est extrêmement important d’apprendre à vos utilisateurs à repérer les URL suspectes lorsqu’ils saisissent leurs identifiants ! Dans presque tous les cas, les clients obtiennent les meilleurs résultats en adoptant une stratégie de domaine centralisé pour l’authentification à travers plusieurs marques de produits ou de services. Cette stratégie offre aux utilisateurs une expérience cohérente et réduit aussi la complexité liée au déploiement et à la maintenance de plusieurs tenants Auth0 dans un environnement de production. Si vous envisagez d’utiliser plusieurs domaines pour différentes marques, consultez les lignes directrices sur la image de marque avant de commencer la mise en œuvre.

​

Soutien du SDLC

Chaque entreprise suit une forme ou une autre de cycle de vie du développement logiciel (SDLC), et vous voudrez harmoniser votre processus de développement avec cette stratégie. Par exemple, vous devez pouvoir tester votre intégration à Auth0 de la même façon que vous testez les applications elles-mêmes. Il est donc important de structurer les tenants Auth0 pour prendre en charge votre cycle de vie du développement logiciel. À cette fin, nos clients suivent généralement un modèle cohérent en matière de pratiques exemplaires pour l’organisation des tenants : Dans certains cas, vous pouvez aussi vouloir créer un ou plusieurs environnements de test isolés (p. ex., company-sandbox1, company-sandbox2) afin de tester des changements sans compromettre votre environnement de développement. C’est souvent là que vous testerez les scripts de déploiement et autres éléments du genre.

​

Guide de planification de projet

Nous mettons à votre disposition un guide de planification en format PDF, que vous pouvez télécharger et consulter pour en savoir plus sur nos stratégies recommandées. Guide de planification de projet B2B IAM

​

Multiple Organization Architecture (Multitenancy)

De nombreuses plateformes B2B mettent en place une certaine forme d’isolation ou d’image de marque pour les organisations de leurs clients, ce qui peut complexifier tout système de gestion des identités et des accès (IAM). Si cela correspond à votre situation, nous vous recommandons de prendre le temps de consulter nos directives et nos conseils sur les pratiques exemplaires pour ce type d’environnement. Multiple Organization Architecture