Exemples de cas d’utilisation : Rules avec Authorization

Découvrez comment utiliser les 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 tenants créés à compter du 16 octobre 2023. Les tenants existants avec des Hooks actifs conserveront l’accès à Hooks jusqu’à la fin de vie.

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

Pour vous aider dans votre migration, nous proposons des guides qui vous aideront à passer de Rules à Actions et à passer de Hooks à Actions. Nous avons également une page dédiée, Move to Actions, qui présente des comparaisons de fonctionnalités, une démo d’Actions et d’autres ressources pour vous accompagner tout au long de votre migration.

Pour en savoir plus sur la dépréciation de Rules et Hooks, consultez notre article 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 politique d’autorisation préconfigurée afin de gérer des cas plus complexes que ce qu’il est possible de faire avec le contrôle d’accès basé sur les rôles (RBAC) à lui seul. 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 ne soient ajoutées au jeton d’accès. Elles vous permettent aussi 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 à laquelle vous voulez limiter l’accès aux jours de semaine. Pour ce faire, créez 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 pendant la fin de semaine, l’accès lui sera refusé, même s’il s’authentifie et qu’il possède les privilèges appropriés.

​

Autoriser l’accès uniquement aux utilisateurs se trouvant à l’intérieur du réseau d’entreprise

Supposons que vous souhaitiez autoriser l’accès à une application, mais uniquement aux utilisateurs qui y accèdent depuis l’intérieur de votre réseau d’entreprise. Pour ce faire, vous créeriez 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 d’entreprise, l’accès lui sera refusé même s’il réussit à s’authentifier et qu’il dispose des privilèges appropriés.

​

Rejeter l’accès à quiconque appelle une API

Supposons que vous souhaitiez rejeter l’accès à tous les utilisateurs qui appellent une API. Cela signifie que vous devez rejeter l’accès en fonction de 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, vous créeriez la règle suivante :

function (user, context, callback) {
  /*
   *  Refuse l'accès aux flux basés sur les utilisateurs selon 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 refuserons. 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 les rôles d’un utilisateur aux jetons

Si vous activez RBAC pour les API et l’option “Ajouter les autorisations dans le jeton d’accès” (ou si vous activez RBAC au moyen de l’Management API et définissez le Dialecte du jeton sur access_token_authz), vous recevrez les autorisations de l’utilisateur dans vos jetons d’accès. Pour ajouter les rôles d’un 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 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 des utilisateurs à l’espace de noms DAE dans l’ID Token. Pour ce faire, créez la règle suivante, en n’oubliant pas de remplacer la valeur de l’espace réservé CLIENT_ID par le Client ID 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 retourne les informations du profil dans un format structuré de claims, tel que défini par la spécification OpenID Connect (OIDC). Cela signifie que les custom claims ajoutés aux ID tokens ou aux access tokens doivent respecter les directives et les restrictions afin d’éviter d’éventuelles collisions.