> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> 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.

# Exemples de cas d’utilisation : Rules avec Authorization

<Warning>
  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](/fr-CA/docs/customize/actions/actions-overview).

  Pour vous aider dans votre migration, nous proposons des guides pour [migrer de Rules vers Actions](/fr-CA/docs/customize/actions/migrate/migrate-from-rules-to-actions) et [migrer de Hooks vers Actions](/fr-CA/docs/customize/actions/migrate/migrate-from-hooks-to-actions). Nous avons également une page dédiée, [Passer à Actions](https://auth0.com/extensibility/movetoactions), qui présente des comparaisons de fonctionnalités, [une démo d’Actions](https://www.youtube.com/watch?v=UesFSY1klrI) 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](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/).
</Warning>

Avec les [Rules](/fr-CA/docs/customize/rules), vous pouvez modifier ou compléter le résultat de la décision prise par la [stratégie d’autorisation](/fr-CA/docs/manage-users/access-control/authorization-policies) 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)](/fr-CA/docs/manage-users/access-control/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 <Tooltip tip="Jeton d’accès : justificatif d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisé pour accéder à une API." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Access+Token">Jeton d’accès</Tooltip>. Elles peuvent aussi vous permettre de personnaliser le contenu de vos jetons.

<div id="allow-access-only-on-weekdays-for-a-specific-application">
  ## Autoriser l’accès à une application précise uniquement les jours de semaine
</div>

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](/fr-CA/docs/customize/rules/create-rules):

```js lines theme={null}
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.

<div id="allow-access-only-to-users-who-are-inside-the-corporate-network">
  ## Autoriser l’accès uniquement aux utilisateurs se trouvant sur le réseau d’entreprise
</div>

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 :

```js lines theme={null}
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.

<div id="deny-access-to-anyone-calling-an-api">
  ## Refuser l’accès à toute personne qui appelle une API
</div>

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 <Tooltip tip="Audience : identifiant unique de l’audience d’un jeton émis. Nommée aud dans un jeton, sa valeur contient l’ID d’une application (ID client) pour un ID Token ou d’une API (identifiant d’API) pour un Jeton d’accès." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Audience">Audience</Tooltip>** de votre API dans [Dashboard > Applications > APIs](https://manage.auth0.com/#/apis). Pour ce faire, créez la règle suivante :

```js lines theme={null}
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`.

<div id="add-user-roles-to-tokens">
  ## Ajouter des rôles d’utilisateur aux jetons
</div>

Si vous [activez le RBAC pour les API](/fr-CA/docs/get-started/apis/enable-role-based-access-control-for-apis) ainsi que "Add Permissions in the Access Token" (ou activez le RBAC via la <Tooltip tip="Management API : une API qui permet aux clients d’effectuer des tâches administratives." cta="Voir le glossaire" href="/fr-CA/docs/glossary?term=Management+API">Management API</Tooltip> 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 :

```js lines theme={null}
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);
}
```

<div id="manage-delegated-administration-extension-roles-using-the-authorization-core-feature-set">
  ## Gérer les rôles de la Delegated Administration Extension à l’aide de l’ensemble de fonctionnalités Authorization Core
</div>

Bien que la [Delegated Administration Extension (DAE)](/fr-CA/docs/customize/extensions/delegated-administration-extension) 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](/fr-CA/docs/manage-users/access-control/configure-core-rbac/roles/create-roles) à 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](/fr-CA/docs/customize/extensions/delegated-administration-extension#assign-roles-to-users).
2. [Attribuez les rôles DAE que vous avez créés aux utilisateurs appropriés](/fr-CA/docs/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-users) à 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](/fr-CA/docs/customize/rules/create-rules), en veillant à remplacer la valeur fictive `CLIENT_ID` par l’ID client de votre application :

```js lines theme={null}
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);
}
```

<Warning>
  Auth0 renvoie les informations de profil sous forme de revendications structurées, conformément à la [spécification OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). 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](/fr-CA/docs/secure/tokens/json-web-tokens/create-custom-claims) afin d’éviter d’éventuelles collisions.
</Warning>