Single Identity Provider : Autorisation

Découvrez comment autoriser les utilisateurs pour organisations dans les architectures multilocataires.

Lorsqu’on réfléchit à l’autorisation, il faut généralement se demander comment déterminer ce qu’une personne a le droit de faire et comment communiquer cette information à vos applications et/ou API. Selon les applications dont vous disposez, vous pouvez être concerné par l’un ou l’autre de ces aspects, ou par les deux. Dans nos scénarios d’architecture, nous fournissons des conseils d’ordre général sur la B2B Authorization, que nous vous recommandons de consulter en complément des conseils fournis ici.

• Les jetons ID sont souvent utilisés pour transmettre aux applications des informations d’autorisation sur l’utilisateur au moyen de claims personnalisés, qui peuvent être ajoutés à l’aide de la fonctionnalité d’extensibilité Rules. Les claims ajoutés peuvent vous permettre de présenter une interface utilisateur dans laquelle les utilisateurs ne peuvent pas tenter d’effectuer une action qu’ils n’ont pas la permission d’exécuter. Les informations d’autorisation contenues dans un jeton ID donnent également au backend de toute application un moyen d’empêcher les utilisateurs de contourner les contrôles du frontend dans les applications Web traditionnelles.

Bonne pratique

Vous pouvez tirer parti de Auth0 Role-Based Access Control (RBAC) au moyen de la fonctionnalité Auth0 Authorization Core pour définir des permissions d’accès, qui peuvent être automatiquement appliquées aux jetons d’accès. Pour en savoir plus, consultez Enable Role-Based Access Control for APIs.

La fonctionnalité RBAC d’Auth0 peut également fournir des informations que vous pouvez ajouter comme claims personnalisés aux jetons d’identité (et aux jetons d’accès, si vous préférez les appliquer manuellement). Auth0 organisations peut tirer parti des capacités RBAC d’Auth0 au moyen d’un ou de plusieurs rôles attribués à l’adhésion. Pour en savoir plus, consultez Add Roles to Organization Members.

• Les API qui offrent un accès public à des services de ressources partagées sont généralement protégées par des mécanismes de contrôle d’accès. À cette fin, Auth0 permet de créer un bearer token d’autorisation, ou OAuth 2 jeton d’accès, qui peut transmettre à une API des informations d’autorisation sur l’utilisateur, généralement en utilisant le Role-Based Access Control (RBAC) d’Auth0 pour appliquer un ou plusieurs membership-assigned roles, ou en ajoutant des claims personnalisés au moyen de la fonctionnalité d’extensibilité Rules. Vous pouvez également tirer parti des capacités RBAC d’Auth0 pour ajuster automatiquement le claim scope d’un jeton d’accès. Les API peuvent ensuite utiliser cette information pour appliquer le niveau approprié de contrôle d’accès, ce qui permet à votre API d’appliquer des règles de politique sans avoir à effectuer une recherche supplémentaire pour obtenir des informations sur l’utilisateur.
• Dans certains cas, vous pourriez vouloir mettre en œuvre des politiques au niveau de l’application dans le tenant Auth0; cela vous permet d’appliquer des politiques à tout un ensemble d’applications et de services de ressources (API) sans avoir à modifier chacun d’eux séparément. Cette mise en œuvre se fait généralement au moyen de la fonctionnalité d’extensibilité Rules.

Bonne pratique

Auth0 organisations donne à Auth0 Rules accès à des informations centrées sur l’organisation, accessibles lors de l’authentification d’un utilisateur. Cette information est accessible au moyen de l’objet organization contenu dans l’objet context de Rules. L’objet organization donne également accès à toutes les métadonnées provisionnées pour une définition d’organisation dans Auth0. Pour en savoir plus, consultez Custom Development for Organizations.

​

Claims du jeton ID

En général, des claims peuvent être ajoutées aux jetons d’identité, comme indiqué dans notre guide de pratique exemplaire sur les claims du jeton ID. Lorsque vous utilisez la fonctionnalité Auth0 Organizations, une claim org_id est automatiquement ajoutée à tout jeton d’identité (pour un exemple, consultez Travailler avec les jetons et les organisations) émis pour les utilisateurs membres d’une organisation. Ce paramètre est validé par les SDK Auth0. Vous pouvez aussi ajouter des renseignements complémentaires associés à une organisation Auth0 en ajoutant une claim personnalisée au jeton d’identité :

context.idToken['http://travel0.net/multifactor'] = context.multifactor;

Remarque : Si vous avez configuré votre tenant pour prendre en charge les noms d’organisation dans l’Authentication API, la claim org_name est automatiquement incluse dans les jetons ID. Pour en savoir plus, consultez Use Organization Names in Authentication API.

​

Assertion SAML

Une assertion SAML générée par un fournisseur d’identité en amont (IdP) peut être configurée pour renseigner des claims standard ou personnalisés dans un jeton d’identité utilisé en aval.

Par exemple, vous pouvez définir la section des mappages d’une connexion d’entreprise SAML :

{ 
  "user_id": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ],
  "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
  "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
  "given_name": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
  ], 
  "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
  "groups": "http://schemas.xmlsoap.org/claims/Group"
}

Dans cet exemple, chaque champ de l’objet user dans une Action se verra attribuer une valeur, qui sera soit mappée à des claims standard dans un jeton ID, soit à des claims personnalisés. Pour en savoir plus sur la personnalisation des mappages SAML, consultez Connect Your App to SAML Identity Providers: Set up mappings.

Lorsque votre application utilise SAML et qu’Auth0 agit comme IdP, vous pouvez inclure une Organisation dans la demande de connexion SAML à l’aide du paramètre de requête organization :

https://{YOUR_AUTH0_DOMAIN}/samlp/{YOUR_APP_CLIENT_ID}?organization={YOUR_ORGANIZATION_ID}

Auth0 renvoie l’organisation dans la réponse SAML sous forme d’attribut personnalisé :

http://schemas.auth0.com/org_id

Tous les claims non standard inclus dans un jeton OIDC, comme les claims personnalisés définis dans une Action, sont également inclus dans la réponse SAML et précédés de http://schemas.auth0.com/.

​

Claims du jeton d’accès

En plus de tout autre claim que vous ajoutez à votre jeton d’accès pour les décisions de contrôle d’accès (consultez nos conseils généraux de bonne pratique sur les claims du jeton d’accès), vous voudrez généralement indiquer l’organisation à laquelle l’utilisateur appartient.

Comme pour le jeton d’identité, lorsque vous utilisez la fonctionnalité Auth0 Organizations, le claim org_id est automatiquement ajouté à tout jeton d’accès (pour un exemple, consultez Utiliser les jetons et les organisations) émis pour les utilisateurs ayant une appartenance à une organisation. Vous pouvez également ajouter des renseignements supplémentaires associés à une Auth0 organisation en ajoutant un claim personnalisé au jeton d’accès :

context.accessToken['http://travel0.net/multifactor'] = context.multifactor;

Remarque : Si vous avez configuré votre tenant pour prendre en charge les noms d’organisation dans l’Authentication API, le claim org_name est automatiquement inclus dans les jetons d’accès. Pour en savoir plus, consultez Use Organization Names in Authentication API.

Vous pouvez aussi créer une audience d’API unique pour chaque organisation, ce qui donnerait une définition d’API distincte dans Auth0. Bien que ce mécanisme puisse réduire le recours à la fonctionnalité Rule personnalisée, la complexité qu’il ajoute peut être difficile à gérer. Voici une comparaison simple :

Approach	Pros	Cons
Audience d’API unique	Prise en charge intégrée de l’accès machine à machine pour une seule organisation. L’audience est un claim standard dans un jeton d’accès. Le traitement du refresh token ne nécessite aucune logique organisationnelle supplémentaire.	La création d’une API doit être automatisée pour chaque organisation. Il peut être nécessaire de créer des rôles distincts si vous utilisez RBAC. Le provisionnement de Roles vers Membership doit être automatisé. La mise en œuvre de l’API doit prendre en charge plusieurs audiences.
Claim personnalisé	Simplifie la configuration du tenant Auth0.	Du code personnalisé dans une rule est nécessaire pour ajouter l’organisation au jeton d’accès.

​

Rôles

La fonctionnalité Auth0 organisations prend également en charge le Role-Based Access Control (RBAC) au moyen de la fonctionnalité Authorization Core associée à un tenant Auth0. Le RBAC est appliqué au niveau de l’appartenance à une organisation Auth0.

Vous pouvez activer Auth0 Authorization Core RBAC pour une API, ce qui modifiera automatiquement le claim scope par défaut dans les jetons d’accès et ajoutera aussi, par défaut, un claim permission (pour voir un exemple, consultez Work with Tokens and Organizations). Vous pouvez également ajouter des renseignements sur les rôles aux jetons d’identité sous forme de claims personnalisés en accédant à l’objet authorization disponible dans l’objet context de Rules. Pour en savoir plus, consultez Rules with Authorization Sample Use Cases: Add User Roles to Tokens.

​

Contrôle d’accès

L’application des politiques au niveau des ressources relève des applications et/ou des API de votre système. Si vous tentez d’appliquer des politiques dans un Authorization Server centralisé, comme votre tenant Auth0, vous vous retrouverez rapidement avec un système de contrôle complexe, difficile à maintenir et à comprendre. Votre Authorization Server centralisé peut plutôt veiller à ce que les renseignements appropriés sur un utilisateur soient inclus dans les jetons, afin que vos applications et vos API disposent de l’information nécessaire pour prendre des décisions quant à l’application des politiques. À tout le moins, dans les situations où il y a trop de renseignements pour les inclure dans un seul jeton (par exemple, des permissions au niveau des ressources) ou lorsque les renseignements changent assez fréquemment pour devenir périmés s’ils sont consultés directement dans le jeton, vos applications et vos API devraient pouvoir aller chercher les bons renseignements.

En revanche, certaines politiques générales peuvent être appliquées de façon centralisée. Par exemple, lorsque vous utilisez le contexte d’un tenant Auth0, il existe des situations dans lesquelles vous pourriez implémenter une Rule afin d’éviter que chaque application et/ou API doive appliquer les mêmes restrictions. Cela comprend notamment :

• bloquer l’accès des utilisateurs provenant d’une adresse IP précise
• implémenter des exigences précises en matière de contexte ou de Adaptive MFA
• restreindre le login aux seuls utilisateurs qui ont vérifié leur adresse courriel
• restreindre l’accès à une audience d’API précise, afin qu’un utilisateur ne puisse pas obtenir de jeton d’accès pour une autre audience d’API ou ne puisse pas obtenir de jeton d’accès pour cette audience dans certaines circonstances. Dans ce cas, si vous créez une audience d’API personnalisée pour chaque organisation, votre Rule doit aussi s’assurer que l’utilisateur en cours d’authentification appartient à l’organisation correspondant à l’audience d’API.

L’accès à Auth0 Management API n’est pas restreint par organisation; l’accès à Auth0 Management API se fait au moyen d’un jeton d’accès attribué à une utilisation dans un contexte machine à machine et ne peut pas être limité par une Auth0 organisation. Par conséquent, n’accordez pas à vos clients un accès direct à votre instance de Auth0 Management API. Si vos clients doivent gérer certains aspects de leur organisation, comme les comptes d’utilisateur (consultez Gestion du profil), vous devriez créer votre propre application et/ou API indépendante à cette fin.