Fournisseur d’identité unique : autorisation

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

Lorsqu’il est question d’autorisation, vous devez généralement déterminer ce qu’une personne est autorisée à faire et comment communiquer cette information à vos applications et/ou API. Selon vos applications, l’un ou l’autre de ces aspects, ou les deux, peuvent entrer en jeu. Dans nos scénarios d’architecture, nous fournissons des recommandations générales sur l’autorisation B2B, que nous vous recommandons de consulter en complément des conseils fournis ici.

• Les ID Tokens servent souvent à transmettre aux applications des informations d’autorisation sur l’utilisateur au moyen de claims personnalisées, qui peuvent être ajoutées à l’aide de l’extensibilité Rules. Les claims ajoutées peuvent vous permettre de présenter une interface utilisateur dans laquelle les utilisateurs ne peuvent pas tenter d’effectuer une action qu’ils ne sont pas autorisés à faire. Les informations d’autorisation contenues dans un ID Token permettent aussi au backend d’une application d’empêcher les utilisateurs de contourner les contrôles du frontend dans les applications Web traditionnelles.

Bonne pratique

Vous pouvez tirer parti du contrôle d’accès basé sur les rôles (RBAC) d’Auth0 au moyen de la fonctionnalité Auth0 Authorization Core pour définir des autorisations d’accès, qui peuvent être automatiquement appliquées aux jetons d’accès. Pour en savoir plus, consultez Activer le contrôle d’accès basé sur les rôles pour les API.

La fonctionnalité RBAC d’Auth0 peut aussi fournir des informations que vous pouvez ajouter comme claims personnalisées aux jetons d’identité (et aux jetons d’accès, si vous préférez les appliquer manuellement). Auth0 Organizations peut tirer parti des capacités RBAC d’Auth0 au moyen d’un ou de plusieurs rôles attribués aux membres. Pour en savoir plus, consultez Ajouter des rôles aux membres d’une organisation.

• 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 jeton d’autorisation porteur, 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 contrôle d’accès basé sur les rôles (RBAC) d’Auth0 pour appliquer un ou plusieurs rôles attribués aux membres, ou en ajoutant des claims personnalisées au moyen de l’extensibilité Rules. Vous pouvez aussi tirer parti des capacités RBAC d’Auth0 pour ajuster automatiquement la claim scope d’un jeton d’accès. Les API peuvent ensuite utiliser cette information pour appliquer le niveau de contrôle d’accès approprié, ce qui permet à votre API d’appliquer des règles de stratégie sans devoir effectuer une recherche supplémentaire pour obtenir des informations sur l’utilisateur.
• Dans certains cas, vous pourriez vouloir mettre en œuvre des stratégies au niveau de l’application dans le locataire Auth0; cela vous permet d’appliquer des stratégies à tout un ensemble d’applications et de services de ressources (API) sans avoir à modifier chacun d’eux individuellement. En général, cela se fait au moyen de l’extensibilité Rules.

Bonne pratique

Auth0 Organizations permet aux Auth0 Rules d’accéder à des informations centrées sur l’organisation 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 aussi accès à toutes les métadonnées provisionnées pour une définition d’Organisation dans Auth0. Pour en savoir plus, consultez Développement personnalisé pour les organisations.

​

Claims du jeton d’identité

En général, il est possible d’ajouter des claims aux jetons d’identité, comme indiqué dans notre guide de bonnes pratiques sur les ID Token Claims. Lorsque vous utilisez la fonctionnalité Organisations d’Auth0, une claim org_id est automatiquement ajoutée à tout jeton d’identité (pour voir un exemple, consultez Work with Tokens and Organizations) émis pour des utilisateurs membres d’une organisation. Ce paramètre est validé par les SDK d’Auth0. Vous pouvez aussi ajouter des informations supplémentaires associées à 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 locataire pour prendre en charge les noms d’organisation dans l’Authentication API, la claim org_name est automatiquement ajoutée aux jetons d’identité. Pour en savoir plus, consultez Utiliser les noms d’organisation dans l’Authentication API.

​

Assertion SAML

Bien que la fonctionnalité Organisation d’Auth0 ne prenne pas en charge les applications compatibles avec SAML, une assertion SAML générée par un fournisseur d’identité (IdP) en amont peut être configurée afin de renseigner des claims standard ou personnalisées dans un jeton d’identité utilisé en aval. Par exemple, vous pourriez définir la section mappings 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, une valeur sera attribuée à chaque champ dans l’objet user d’une Rule; cette valeur correspondra soit à des claims standard dans un jeton d’identité, soit à des claims personnalisées. Pour en savoir plus sur la personnalisation des mappages SAML, consultez Connect Your App to SAML Identity Providers: Set up mappings.

​

Claims du jeton d’accès

En plus de toute autre claim que vous ajoutez à votre jeton d’accès pour prendre des décisions de contrôle d’accès (consultez nos recommandations générales de bonnes pratiques 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é Organisations d’Auth0, la claim org_id est automatiquement ajoutée à tout jeton d’accès (pour voir un exemple, consultez Utiliser les jetons et les organisations) émis pour les utilisateurs membres d’une organisation. Vous pouvez également ajouter des renseignements supplémentaires associés à une organisation Auth0 en ajoutant une claim personnalisée au jeton d’accès :

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

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

Vous pouvez également créer une audience d’API distincte pour chaque organisation, ce qui créerait une définition d’API distincte dans Auth0. Bien que ce mécanisme puisse réduire le besoin d’utiliser une extensibilité Rule personnalisée, la complexité qu’il introduit peut être difficile à gérer. Voici une comparaison simple :

Approche	Avantages	Inconvénients
Audience API unique	Prise en charge prête à l’emploi de l’accès machine à machine pour une seule organisation. Audience est une claim standard dans un jeton d’accès. Le traitement du jeton d’actualisation ne nécessite aucune logique d’organisation supplémentaire.	Vous devez automatiser la création d’une API pour chaque organisation. Il peut être nécessaire de créer des rôles distincts si vous utilisez RBAC. Vous devez automatiser l’attribution des rôles aux adhésions. L’implémentation de l’API doit prendre en charge plusieurs audiences.
Claim personnalisée	Simplifie la configuration du locataire Auth0.	Du code personnalisé est nécessaire dans une Rule pour ajouter l’organisation au jeton d’accès.

​

Rôles

La fonctionnalité Organisations d’Auth0 prend également en charge le contrôle d’accès basé sur les rôles (RBAC) au moyen de la fonctionnalité Authorization Core associée à un locataire Auth0. Le RBAC est appliqué au niveau de l’appartenance à une organisation Auth0.

Vous pouvez activer le RBAC d’Auth0 Authorization Core pour une API, ce qui modifiera automatiquement la claim scope par défaut dans les jetons d’accès et ajoutera par défaut une claim permission (pour un exemple, consultez Utiliser des jetons et des organisations). Vous pouvez également ajouter des informations sur les rôles aux jetons d’identité sous forme de claims personnalisées en accédant à l’objet authorization disponible dans l’objet context de Rules. Pour en savoir plus, consultez Exemples de cas d’utilisation de Rules avec Authorization : ajouter des rôles d’utilisateur aux jetons.

​

Contrôle d’accès

L’application des stratégies au niveau des ressources relève des applications et/ou des API de votre système. Si vous tentez d’appliquer des stratégies dans un serveur d’autorisation centralisé, comme votre locataire Auth0, vous vous retrouverez rapidement avec un système de contrôle complexe, difficile à maintenir et à comprendre. Votre serveur d’autorisation centralisé peut plutôt veiller à ce que les renseignements pertinents 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 d’application des stratégies. À tout le moins, dans les cas où il y a trop d’information pour l’inclure dans un seul jeton (par exemple, des permissions au niveau des ressources) ou lorsque l’information change assez souvent pour devenir périmée si elle est consultée directement dans le jeton, vos applications et vos API devraient pouvoir récupérer l’information appropriée.

Certaines stratégies générales, en revanche, peuvent être appliquées de façon centralisée. Par exemple, dans le contexte d’un locataire Auth0, il existe certaines situations dans lesquelles vous pourriez mettre en œuvre une Rule qui évite à chaque application et/ou API d’avoir à appliquer les mêmes restrictions. Il s’agit notamment des cas suivants :

• bloquer l’accès aux utilisateurs provenant d’une adresse IP particulière
• mettre en œuvre des exigences particulières liées à l’authentification contextuelle ou à la MFA adaptative
• restreindre la connexion aux seuls utilisateurs qui ont vérifié leur adresse de courriel
• restreindre l’accès à une audience d’API donnée, 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 également veiller à ce que l’utilisateur qui s’authentifie appartienne à l’organisation correspondant à l’audience d’API visée.

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