Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Exemple 2 : RBAC de base avec autorisations vérifiées et Cedar
<a name="avp-basic-rbac-examples"></a>

Cet exemple utilise Verified Permissions et Cedar pour illustrer le RBAC de base. Comme mentionné précédemment, la structure de base de Cedar est une entité. Les développeurs définissent leurs propres entités et peuvent éventuellement créer des relations entre les entités. L'exemple suivant inclut trois types d'entités : `Users``Roles`, et`Problems`. `Students`et `Teachers` peuvent être considérées comme des entités du type `Role,` et chacune `User` peut être associée à zéro ou à l'un des`Roles`.

![Exemple d'implémentation RBAC de base avec Amazon Verified Permissions et Cedar pour implémenter un PDP](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-2.png)


Dans Cedar, ces relations sont exprimées en liant le `Role` `Student` au `User` `Bob` en tant que parent. Cette association regroupe logiquement tous les utilisateurs étudiants dans un seul groupe. Pour plus d'informations sur le regroupement dans Cedar, consultez la [documentation de Cedar](https://docs.cedarpolicy.com/overview/terminology.html#term-group).

La politique suivante évalue la décision `ALLOW` d'action `submitProblem,` pour tous les principaux liés au groupe logique `Students` de ce type. `Role`

```
permit (
    principal in ElearningApp::Role::"Students",
    action == ElearningApp::Action::"submitProblem",
    resource
);
```

La politique suivante détermine la décision prise `ALLOW` pour l'action `submitProblem` ou `answerProblem` pour tous les principes liés au groupe logique `Teachers` du type. `Role`

```
permit (
    principal in ElearningApp::Role::"Teachers",
    action in [
        ElearningApp::Action::"submitProblem",
        ElearningApp::Action::"answerProblem"
    ],
    resource
);
```

Afin d'évaluer les demandes avec ces politiques, le moteur d'évaluation doit savoir si le principal référencé dans la demande d'autorisation est membre du groupe approprié. Par conséquent, l'application doit transmettre les informations pertinentes relatives à l'appartenance au groupe au moteur d'évaluation dans le cadre de la demande d'autorisation. Cela se fait par le biais de la `entities` propriété, qui vous permet de fournir au moteur d'évaluation Cedar des données d'attribut et d'appartenance à un groupe pour le principal et la ressource impliqués dans l'appel d'autorisation. Dans le code suivant, l'appartenance à un groupe est indiquée par le fait `User::"Bob"` qu'un parent est appelé`Role::"Students"`.

```
{
  "policyStoreId": "ELEARNING_POLICYSTOREID",
  "principal": {
    "entityType": "ElearningApp::User",
    "entityId": "Bob"
  },
  "action": {
    "actionType": "ElearningApp::Action",
    "actionId": "answerProblem"
  },
  "resource": {
    "entityType": "ElearningApp::Problem",
    "entityId": "SomeProblem"
  },
  "entities": {
    "entityList": [
        {
            "identifier": {
                "entityType": "ElearningApp::User",
                "entityId": "Bob"
            },
            "attributes": {},
            "parents": [
                {
                    "entityType": "ElearningApp::Role",
                    "entityId": "Students"
                } 
            ]
        },
        {
          "identifier": {
            "entityType": "ElearningApp::Problem",
            "entityId": "SomeProblem"
          },
          "attributes": {},
          "parents": []
        }
      ]
  }
}
```

Dans cet exemple, Bob est l'utilisateur connecté qui fait la `answerProblem` demande. Par conséquent, Bob est le principal et l'entité est du type`User`. L'action que Bob essaie d'effectuer est`answerProblem`. Afin d'évaluer si Bob peut effectuer l'`answerProblem`action, vous devez fournir une structure d'entité qui lie l'entité `User` à une valeur de `Bob` et lui attribue son appartenance au groupe en répertoriant une entité parent sous `Role::"Students"` le nom. Étant donné que les entités du groupe d'utilisateurs `Role::"Students"` sont uniquement autorisées à effectuer l'action`submitProblem`, cette demande d'autorisation est évaluée à`DENY`.

En revanche, si le type `User` qui a une valeur égale à `Alice` et qui fait partie du groupe `Role::"Teachers"` essaie d'exécuter l'`answerProblem`action, la demande d'autorisation est évaluée comme suit`ALLOW`, car la politique stipule que les principaux membres du groupe `Role::"Teachers"` sont autorisés à effectuer l'action `answerProblem` sur toutes les ressources. Le code suivant montre ce type de demande d'autorisation qui est évalué à`ALLOW`.

```
{
  "policyStoreId": "ELEARNING_POLICYSTOREID",
  "principal": {
    "entityType": "ElearningApp::User",
    "entityId": "Alice"
  },
  "action": {
    "actionType": "ElearningApp::Action",
    "actionId": "answerProblem"
  },
  "resource": {
    "entityType": "ElearningApp::Problem",
    "entityId": "SomeProblem"
  },
  "entities": {
    "entityList": [
        {
            "identifier": {
                "entityType": "ElearningApp::User",
                "entityId": "Alice"
            },
            "attributes": {},
            "parents": [
                {
                    "entityType": "ElearningApp::Role",
                    "entityId": "Teachers"
                } 
            ]
        },
        {
            "identifier": {
                "entityType": "ElearningApp::Problem",
                "entityId": "SomeProblem"
            },
            "attributes": {},
            "parents": []
        }
      ]
  }
}
```