Exemples de cas d’utilisation : Règles avec autorisation

Les règles vous permettent de modifier ou compléter le résultat de la décision prise par la politique d’autorisation préconfigurée afin que vous puissiez gérer des cas plus compliqués qu’avec le contrôle d'accès basé sur les rôles (RBAC) seul. En fonction de leur ordre d’exécution, les règles 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 peuvent également vous permettre de personnaliser le contenu de vos jetons.

Supposons que vous ayez une application pour laquelle vous souhaitez qu’elle ne soit accessible que pendant les jours ouvrables. Pour cela, vous devez 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 pendant le week-end, l’accès lui sera refusé, même s’il s’authentifie et dispose des privilèges appropriés.

Supposons que vous souhaitiez autoriser l’accès à une application, mais uniquement pour les utilisateurs qui accèdent à l’application depuis le réseau de votre entreprise. Pour cela, vous devez créer 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 en dehors du réseau de l’entreprise, l’accès lui sera refusé même s’il s’authentifie et dispose des privilèges appropriés.

Supposons que vous souhaitiez refuser l’accès à tous les utilisateurs qui appellent une API. Cela signifie que vous devez refuser l’accès en fonction de la valeur de audience de votre API, que vous pouvez trouver dans le champ API de public de votre API dans Dashboard > Applications > API. Pour cela, vous devez créer la règle suivante :

function (user, context, callback) {
  /*
   *  Denies access to user-based flows based on 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 d'audience pour l’API est http:://todoapi2.api. Ce sera donc le public que nous allons refuser. Si quelqu’un essaie d’accéder à l’API avec cette valeur audience, l’accès leur sera refusé et ils recevront une erreur HTTP 401.

Si vous procédez aux actions activer RBAC pour les API ainsi que « Ajouter des autorisations dans le jeton d’accès » (ou activer RBAC via Management API et définissez le Dialecte de jeton sur access_token_authz), vous recevrez des autorisations utilisateur dans vos jetons d’accès. Pour ajouter des rôles d’utilisateur aux jetons, vous devez utiliser 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);
}

Bien que l'Extension d’administration déléguée (DAE) et l’ensemble de fonctionnalités Authorization Core soient des fonctionnalités complètement 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éer des rôles DAE en utilisant l’ensemble de fonctionnalités Authorization Core. Les noms des rôles que vous créez doivent correspondre aux noms des rôles DAE prédéfinis.

2. Attribuez les rôles DAE que vous avez créés aux utilisateurs concernés en utilisant l’ensemble des fonctionnalités Authorization Core.

3. Ajouter des rôles d’utilisateur à l’espace de noms DAE dans le jeton d’ID. Pour cela, créez la règle suivante en veillant à remplacer la valeur de l’espace réservé 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);
   }

   Was this helpful?

   Yes /No
   Auth0 renvoie les informations de profil contenues dans un format de demande structuré tel que défini par la spécification OpenID Connect (OIDC). Cela signifie que les demandes personnalisées ajoutées aux jetons d’ID ou aux jetons d’accès doivent respecter des directives et des restrictions pour éviter d’éventuels conflits.