Exemples de cas d’utilisation : Rules avec Authorization

Découvrez comment utiliser Rules avec le contrôle d’accès basé sur les rôles (RBAC). À utiliser avec notre ensemble de fonctionnalités Authorization Core.

La date de fin de vie (EOL) de Rules et Hooks est fixée au 18 novembre 2026, et ils ne sont plus offerts aux nouveaux locataires créés à compter du 16 octobre 2023. Les locataires existants ayant des Hooks actifs conserveront l’accès au produit Hooks jusqu’à sa fin de vie.

Nous vous recommandons fortement d’utiliser Actions pour étendre Auth0. Avec Actions, vous avez accès à des informations de type riches, à une documentation intégrée et à des packages npm publics, et vous pouvez connecter des intégrations externes qui améliorent votre expérience globale d’extensibilité. Pour en savoir plus sur ce qu’offrent Actions, consultez Comprendre le fonctionnement des Actions d’Auth0.

Pour vous aider dans votre migration, nous proposons des guides pour migrer de Rules vers Actions et migrer de Hooks vers Actions. Nous avons également une page dédiée, Passer à Actions, qui présente des comparaisons de fonctionnalités, une démo d’Actions et d’autres ressources pour vous accompagner dans votre parcours de migration.

Pour en savoir plus sur la dépréciation de Rules et Hooks, consultez notre billet de blogue : Preparing for Rules and Hooks End of Life.

Avec les Rules, vous pouvez modifier ou compléter le résultat de la décision prise par la stratégie d’autorisation préconfigurée afin de gérer des cas plus complexes que ce qu’il est possible de faire avec le seul contrôle d’accès basé sur les rôles (RBAC). Selon l’ordre dans lequel elles s’exécutent, les Rules peuvent modifier le résultat de la décision d’autorisation avant que les autorisations soient ajoutées au Jeton d’accès. Elles peuvent aussi vous permettre de personnaliser le contenu de vos jetons.

​

Autoriser l’accès à une application précise uniquement les jours de semaine

Supposons que vous ayez une application dont vous voulez limiter l’accès aux jours de semaine. Pour ce faire, vous pouvez créer la règle suivante:

function (user, context, callback) {

  if (context.clientName === 'APP_NAME') {
    const d = Date.getDay();

    if (d === 0 || d === 6) {
      return callback(new UnauthorizedError('This app is only available during the week.'));
    }
  }

  callback(null, user, context);
}

Si un utilisateur tente d’accéder à l’application durant la fin de semaine, l’accès lui sera refusé, même s’il s’authentifie et dispose des privilèges requis.

​

Autoriser l’accès uniquement aux utilisateurs se trouvant sur le réseau d’entreprise

Supposons que vous souhaitiez autoriser l’accès à une application, mais seulement pour les utilisateurs qui y accèdent depuis votre réseau d’entreprise. Pour ce faire, créez la règle suivante :

function (user, context, callback) {
  const ipaddr = require('ipaddr.js@1.9.0');
  const corp_network = "192.168.1.134/26";
  const current_ip = ipaddr.parse(context.request.ip);

  if (!current_ip.match(ipaddr.parseCIDR(corp_network))) {
    return callback(new UnauthorizedError('This app is only available from inside the corporate network.'));
  };

  callback(null, user, context);
}

Si l’utilisateur se trouve à l’extérieur du réseau de l’entreprise, l’accès lui sera refusé même s’il s’authentifie avec succès et dispose des privilèges appropriés.

​

Refuser l’accès à toute personne qui appelle une API

Supposons que vous vouliez refuser l’accès à tous les utilisateurs qui appellent une API. Cela signifie que vous devez refuser l’accès selon la valeur audience de votre API, que vous trouverez dans le champ Audience de l’API Audience de votre API dans Dashboard > Applications > APIs. Pour ce faire, créez la règle suivante :

function (user, context, callback) {
  /*
   *  Refuse l'accès aux flux basés sur l'utilisateur en fonction de l'audience
   */
  var audience = '';
  audience = audience
              || (context.request && context.request.query && context.request.query.audience)
              || (context.request && context.request.body && context.request.body.audience);
  if (audience === 'http://todoapi2.api' || !audience) {
    return callback(new UnauthorizedError('end_users_not_allowed'));
  }
  return callback(null, user, context);
}

Dans ce cas, la valeur audience de l’API est http:://todoapi2.api; c’est donc cette audience que nous rejetterons. Si quelqu’un tente d’accéder à l’API avec cette valeur audience, l’accès lui sera refusé et il recevra une réponse HTTP 401.

​

Ajouter des rôles d’utilisateur aux jetons

Si vous activez le RBAC pour les API ainsi que “Add Permissions in the Access Token” (ou activez le RBAC via la Management API et définissez le Dialecte du jeton sur access_token_authz), les autorisations de l’utilisateur seront incluses dans vos jetons d’accès. Pour ajouter des rôles d’utilisateur aux jetons, utilisez l’objet context.authorization lorsque vous créez la règle suivante :

function (user, context, callback) {
  const namespace = 'http://demozero.net';
  const assignedRoles = (context.authorization || {}).roles;

  let idTokenClaims = context.idToken || {};
  let accessTokenClaims = context.accessToken || {};

  idTokenClaims[`${namespace}/roles`] = assignedRoles;
  accessTokenClaims[`${namespace}/roles`] = assignedRoles;

  context.idToken = idTokenClaims;
  context.accessToken = accessTokenClaims;

  callback(null, user, context);
}

​

Gérer les rôles de la Delegated Administration Extension à l’aide de l’ensemble de fonctionnalités Authorization Core

Bien que la Delegated Administration Extension (DAE) et l’ensemble de fonctionnalités Authorization Core soient deux fonctionnalités entièrement distinctes, vous pouvez utiliser l’ensemble de fonctionnalités Authorization Core pour créer et gérer des rôles pour la DAE si vous utilisez une règle.

1. Créez des rôles DAE à l’aide de l’ensemble de fonctionnalités Authorization Core. Les noms des rôles que vous créez doivent correspondre à ceux des rôles DAE prédéfinis.
2. Attribuez les rôles DAE que vous avez créés aux utilisateurs appropriés à l’aide de l’ensemble de fonctionnalités Authorization Core.
3. Ajoutez les rôles de l’utilisateur à l’espace de noms DAE dans l’ID Token. Pour ce faire, créez la règle suivante, en veillant à remplacer la valeur fictive CLIENT_ID par l’ID client de votre application :

function (user, context, callback) {
    if (context.clientID === 'CLIENT_ID') {
        const namespace = 'https://example.com/auth0-delegated-admin';
        context.idToken[namespace] = {
            roles: (context.authorization || {}).roles
        };
    }
    callback(null, user, context);
}

Auth0 renvoie les informations de profil sous forme de revendications structurées, conformément à la spécification OpenID Connect (OIDC). Cela signifie que les revendications personnalisées ajoutées aux jetons d’identité ou aux jetons d’accès doivent respecter les directives et les restrictions afin d’éviter d’éventuelles collisions.