> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Exemples de cas d’utilisation : Règles avec autorisation
> Apprenez à utiliser les règles avec le contrôle d’accès basé sur les rôles (Role-Based Access Control/RBAC). Pour utilisation avec notre ensemble de fonctionnalités Authorization Core.
La date de fin de vie (EOL) des Règles et des Appels sera le **18 novembre 2026**. Ils ne sont plus disponibles pour les nouveaux locataires créés à partir du **16 octobre 2023**. Les locataires actuels ayant des hooks actifs conserveront l’accès aux produit Hooks jusqu’à la fin de leur durée de vie.
Nous vous conseillons vivement d’utiliser les Actions pour étendre Auth0. Avec les Actions, vous avez accès à des informations de type enrichies, à une documentation intégrée et à des packages `npm` publics, et vous pouvez connecter des intégrations externes qui optimisent votre expérience d’extensibilité globale. Pour en savoir plus sur ce que les Actions proposent, consultez [Comprendre comment fonctionnent Auth0 Actions](/docs/fr-ca/customize/actions/actions-overview).
Pour vous aider dans votre migration, nous proposons des guides qui vous aideront à [migrer des Règles vers les Actions](/docs/fr-ca/customize/actions/migrate/migrate-from-rules-to-actions) et à [migrer des Hooks vers les Actions](/docs/fr-ca/customize/actions/migrate/migrate-from-hooks-to-actions). Nous avons également une page dédiée à la [Migration vers les Actions](https://auth0.com/extensibility/movetoactions) qui met en évidence les comparaisons de fonctionnalités, [une démo des Actions](https://www.youtube.com/watch?v=UesFSY1klrI) et d’autres ressources pour vous aider dans votre parcours de migration.
Pour en savoir plus sur l’obsolescence des Règles et des Appels, consultez notre article de blog : [Preparing for Rules and Hooks End of Life (Préparation à la fin de vie des règles et des crochets)](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/).
Les [règles](/docs/fr-ca/customize/rules) vous permettent de modifier ou compléter le résultat de la décision prise par la [politique d’autorisation](/docs/fr-ca/manage-users/access-control/authorization-policies) 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)](/docs/fr-ca/manage-users/access-control/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.
## Autoriser l’accès uniquement les jours ouvrables pour une application spécifique
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](/docs/fr-ca/customize/rules/create-rules) :
```javascript 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 pendant le week-end, l’accès lui sera refusé, même s’il s’authentifie et dispose des privilèges appropriés.
## Autoriser l’accès uniquement aux utilisateurs qui se trouvent à l’intérieur du réseau de l’entreprise
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 :
```javascript 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 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.
## Interdire l’accès à toute personne appelant une API
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](https://manage.auth0.com/#/apis). Pour cela, vous devez créer la règle suivante :
```javascript lines theme={null}
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`.
## Ajouter des rôles d’utilisateur aux jetons
Si vous procédez aux actions [activer RBAC pour les API](/docs/fr-ca/get-started/apis/enable-role-based-access-control-for-apis) 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 :
```javascript 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);
}
```
## Gérer les rôles d’extension de l’administration déléguée à l’aide de l’ensemble des fonctionnalités d’Authorization Core
Bien que l'[Extension d’administration déléguée (DAE)](/docs/fr-ca/customize/extensions/delegated-administration-extension) 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](/docs/fr-ca/manage-users/access-control/configure-core-rbac/roles/create-roles) 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](/docs/fr-ca/customize/extensions/delegated-admin#assign-roles-to-users).
2. [Attribuez les rôles DAE que vous avez créés aux utilisateurs concernés](/docs/fr-ca/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-users) 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](/docs/fr-ca/customize/rules/create-rules) en veillant à remplacer la valeur de l’espace réservé `CLIENT_ID` par l’ID client de votre application :
```javascript 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);
}
```
Auth0 renvoie les informations de profil contenues dans un format de demande structuré tel que défini par la [spécification OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). 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](/docs/fr-ca/secure/tokens/json-web-tokens/create-custom-claims) pour éviter d’éventuels conflits.