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 1 : ABAC de base avec autorisations vérifiées et Cedar Dans cet exemple de scénario, Amazon Verified Permissions est utilisé pour déterminer quels utilisateurs sont autorisés à accéder aux informations d'un microservice de paie fictif. Cette section inclut des extraits de code Cedar pour montrer comment utiliser Cedar pour prendre des décisions en matière de contrôle d'accès. Ces exemples ne sont pas destinés à fournir une exploration complète des fonctionnalités fournies par Cedar et Verified Permissions. Pour une présentation plus complète de Cedar, consultez la [documentation de Cedar](https://docs.cedarpolicy.com/). Dans le schéma suivant, nous aimerions appliquer deux règles commerciales générales associées à la `viewSalary` `GET` méthode : les *employés peuvent consulter leur propre salaire* et les *employés peuvent consulter le salaire de toute personne relevant d'eux.* Vous pouvez appliquer ces règles commerciales en utilisant les politiques d'autorisations vérifiées. ![Exemple d'implémentation ABAC 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-1.png) *Les employés peuvent consulter leur propre salaire.* Dans Cedar, la construction de base est une *entité* qui représente un principe, une action ou une ressource. Pour effectuer une demande d'autorisation et démarrer une évaluation avec une politique d'autorisations vérifiées, vous devez fournir un *principal,* une *action*, une *ressource* et une *liste d'entités.* + Le principal (`principal`) est l'utilisateur ou le rôle connecté. + L'action (`action`) est l'opération évaluée par la demande. + La ressource (`resource`) est le composant auquel l'action accède. + La liste des entités (`entityList`) contient toutes les entités requises pour évaluer la demande. Pour satisfaire à la règle commerciale, *les employés peuvent consulter leur propre salaire*, vous pouvez fournir une politique d'autorisations vérifiées telle que la suivante. ``` permit ( principal, action == Action::"viewSalary", resource ) when { principal == resource.owner }; ``` Cette politique évalue `ALLOW` si le propriétaire de l'attribut `Action` est égal au principal `viewSalary` et si la ressource contenue dans la demande est le même. Par exemple, si Bob est l'utilisateur connecté qui a demandé le rapport salarial et qu'il est également le propriétaire du rapport salarial, la politique est évaluée à`ALLOW`. La demande d'autorisation suivante est soumise à Verified Permissions pour être évaluée par l'exemple de politique. Dans cet exemple, Bob est l'utilisateur connecté qui fait la `viewSalary` demande. Bob est donc le principal du type d'entité`Employee`. L'action que Bob essaie d'effectuer est `viewSalary,` et la ressource qui s'`viewSalary`affichera est `Salary-Bob` de type`Salary`. Afin d'évaluer si Bob peut visualiser la `Salary-Bob` ressource, vous devez fournir une structure d'entité qui lie le type `Employee` avec une valeur de `Bob` (le principal) à l'attribut propriétaire de la ressource qui possède le type`Salary`. Vous fournissez cette structure dans un`entityList`, où les attributs associés à `Salary` incluent un propriétaire, qui spécifie et `entityIdentifier` qui contient le type `Employee` et la valeur`Bob`. Verified Permissions compare les informations `principal` fournies dans la demande d'autorisation à `owner` l'attribut associé à la `Salary` ressource pour prendre une décision. ``` { "policyStoreId": "PAYROLLAPP_POLICYSTOREID", "principal": { "entityType": "PayrollApp::Employee", "entityId": "Bob" }, "action": { "actionType": "PayrollApp::Action", "actionId": "viewSalary" }, "resource": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "entities": { "entityList": [ { "identifier": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "attributes": { "owner": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" } } } }, { "identifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" }, "attributes": {} } ] } } ``` La demande d'autorisation adressée à Verified Permissions renvoie le résultat suivant, où l'attribut `decision` est `ALLOW` ou`DENY`. ``` { "determiningPolicies": [ { "determiningPolicyId": "PAYROLLAPP_POLICYSTOREID" } ], "decision": "ALLOW", "errors": [] } ``` Dans ce cas, comme Bob essayait de consulter son propre salaire, la demande d'autorisation envoyée à Verified Permissions est évaluée à`ALLOW`. Cependant, notre objectif était d'utiliser les autorisations vérifiées pour appliquer deux règles commerciales. La règle métier qui stipule ce qui suit doit également être vraie : *Les employés peuvent consulter le salaire de toute personne relevant d'eux.* Pour satisfaire à cette règle commerciale, vous pouvez définir une autre politique. La politique suivante détermine `ALLOW` si l'action est effectuée `viewSalary` et si la ressource contenue dans la demande possède un attribut `owner.manager` égal au principal. Par exemple, si Alice est l'utilisateur connecté qui a demandé le rapport salarial et qu'Alice est la responsable du propriétaire du rapport, la politique est évaluée à`ALLOW`. ``` permit ( principal, action == Action::"viewSalary", resource ) when { principal == resource.owner.manager }; ``` La demande d'autorisation suivante est soumise à Verified Permissions pour être évaluée par l'exemple de politique. Dans cet exemple, Alice est l'utilisateur connecté qui fait la `viewSalary` demande. Alice est donc la principale et l'entité est du type`Employee`. L'action qu'Alice essaie d'effectuer est`viewSalary`, et la ressource qui s'`viewSalary`affichera est du type `Salary` avec une valeur de`Salary-Bob`. Pour évaluer si Alice peut consulter la `Salary-Bob` ressource, vous devez fournir une structure d'entité qui lie le type `Employee` avec une valeur de `Alice` à l'`manager`attribut, qui doit ensuite être associé à l'`owner`attribut du type `Salary` avec une valeur de`Salary-Bob`. Vous fournissez cette structure dans un`entityList`, où les attributs associés à `Salary` incluent un propriétaire, qui spécifie et `entityIdentifier` qui contient le type `Employee` et la valeur`Bob`. Les autorisations vérifiées vérifient d'abord l'`owner`attribut, qui est évalué en fonction du type `Employee` et de la valeur`Bob`. Ensuite, Verified Permissions évalue l'`manager`attribut associé `Employee` et le compare au principal fourni pour prendre une décision d'autorisation. Dans ce cas, la décision est prise `ALLOW` parce que les `resource.owner.manager` attributs `principal ` et sont équivalents. ``` { "policyStoreId": "PAYROLLAPP_POLICYSTOREID", "principal": { "entityType": "PayrollApp::Employee", "entityId": "Alice" }, "action": { "actionType": "PayrollApp::Action", "actionId": "viewSalary" }, "resource": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "entities": { "entityList": [ { "identifier": { "entityType": "PayrollApp::Employee", "entityId": "Alice" }, "attributes": { "manager": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "None" } } }, "parents": [] }, { "identifier": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "attributes": { "owner": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" } } }, "parents": [] }, { "identifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" }, "attributes": { "manager": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "Alice" } } }, "parents": [] } ] } } ``` Jusqu'à présent, dans cet exemple, nous avons fourni les deux règles commerciales associées à la `viewSalary` méthode : les *employés peuvent consulter leur propre salaire* et les *employés peuvent consulter le salaire de toute personne relevant d'eux, aux* autorisations vérifiées sous forme de politiques visant à satisfaire aux conditions de chaque règle commerciale de manière indépendante. Vous pouvez également utiliser une seule politique d'autorisations vérifiées pour satisfaire aux conditions des deux règles commerciales : *Les employés peuvent consulter leur propre salaire et celui de toute personne relevant d'eux.* Lorsque vous utilisez la demande d'autorisation précédente, la politique suivante `ALLOW` détermine si l'action est `viewSalary` et si la ressource contenue dans la demande possède un attribut `owner.manager` égal à ou un attribut `owner` égal à. `principal` `principal` ``` permit ( principal, action == PayrollApp::Action::"viewSalary", resource ) when { principal == resource.owner.manager || principal == resource.owner }; ``` Par exemple, si Alice est l'utilisateur connecté qui demande le rapport salarial, et si Alice est soit la responsable du propriétaire, soit la propriétaire du rapport, alors la politique est évaluée à`ALLOW`. Pour plus d'informations sur l'utilisation d'opérateurs logiques avec les politiques Cedar, consultez la [documentation de Cedar](https://docs.cedarpolicy.com/policies/syntax-operators.html).