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.
# Termes et concepts linguistiques relatifs aux autorisations vérifiées par Amazon et à la politique de Cedar
Vous devez comprendre les concepts suivants pour utiliser Amazon Verified Permissions.
**Topics**
+ [Modèle d'autorisation](#term-authorization-model)
+ [Demande d'autorisation](#term-authorization-request)
+ [Réponse d'autorisation](#term-authorization-response)
+ [Politiques prises en compte](#term-considered-policies)
+ [Données contextuelles](#term-context-data)
+ [Déterminer les politiques](#term-determining-policies)
+ [Données sur les entités](#term-entity-data)
+ [Permissions, autorisations et principes](#term-permissions-authorization-principals)
+ [Application des politiques](#term-policy-enforcement)
+ [Boutique Policy](#term-policy-store)
+ [Alias du magasin Policy](#term-policy-store-alias)
+ [Nom de la politique](#term-policy-name)
+ [Nom du modèle de politique](#term-policy-template-name)
+ [Politiques satisfaites](#term-satisfied-policies)
+ [Différences entre les autorisations vérifiées d'Amazon et le langage de politique de Cedar](terminology-differences-avp-cedar.md)
**Concepts linguistiques relatifs à la politique du**
+ [Autorisation](https://docs.cedarpolicy.com/overview/terminology.html#authorization)
+ [Entité](https://docs.cedarpolicy.com/overview/terminology.html#entity)
+ [Groupes et hiérarchies](https://docs.cedarpolicy.com/overview/terminology.html#term-group)
+ [Espaces de noms](https://docs.cedarpolicy.com/policies/validation.html#namespaces)
+ [Stratégie](https://docs.cedarpolicy.com/overview/terminology.html#policy)
+ [Modèle de politique](https://docs.cedarpolicy.com/overview/terminology.html#policy-template)
+ [Schema](https://docs.cedarpolicy.com/overview/terminology.html#schema) (Schéma)
## Modèle d'autorisation
Le *modèle d'autorisation* décrit l'étendue des [demandes d'autorisation](#term-authorization-request) effectuées par l'application et la base d'évaluation de ces demandes. Il est défini en fonction des différents types de ressources, des actions entreprises sur ces ressources et des types de principes qui prennent ces mesures. Il prend également en compte le contexte dans lequel ces mesures sont prises.
*Le contrôle d'accès basé sur les rôles (RBAC)* est une base d'évaluation dans laquelle les rôles sont définis et associés à un ensemble d'autorisations. Ces rôles peuvent ensuite être attribués à une ou plusieurs identités. L'identité attribuée acquiert les autorisations associées au rôle. Si les autorisations associées au rôle sont modifiées, la modification a automatiquement un impact sur toute identité à laquelle le rôle a été attribué. Cedar peut soutenir les décisions du RBAC en faisant appel à des groupes principaux.
Le *contrôle d'accès basé sur les attributs (ABAC)* est une base d'évaluation dans laquelle les autorisations associées à une identité sont déterminées par les attributs de cette identité. Cedar peut soutenir les décisions de l'ABAC en utilisant des conditions politiques qui font référence aux attributs du principal.
Le langage de politique Cedar permet de combiner RBAC et ABAC dans une seule politique en permettant de définir des autorisations pour un groupe d'utilisateurs soumis à des conditions basées sur des attributs.
## Demande d'autorisation
Une *demande d'autorisation* est une demande d'autorisations vérifiées faite par une application pour évaluer un ensemble de politiques afin de déterminer si un principal peut effectuer une action sur une ressource dans un contexte donné.
## Réponse d'autorisation
La *réponse d'autorisation* est la réponse à la [demande d'autorisation](#term-authorization-request). Il inclut une décision d'autorisation ou de refus, ainsi que des informations supplémentaires, telles que IDs les politiques déterminantes.
## Politiques prises en compte
Les *politiques considérées* sont l'ensemble complet des politiques sélectionnées par Verified Permissions pour inclusion lors de l'évaluation d'une [demande d'autorisation](#term-authorization-request).
## Données contextuelles
Les *données contextuelles* sont des valeurs d'attributs qui fournissent des informations supplémentaires à évaluer.
## Déterminer les politiques
Les *politiques de détermination* sont les politiques qui déterminent la [réponse d'autorisation](#term-authorization-response). Par exemple, si deux [politiques sont satisfaites](#term-satisfied-policies), l'une étant un refus et l'autre une autorisation, la politique de refus sera la politique déterminante. Si plusieurs politiques d'autorisation sont satisfaites et qu'aucune politique d'interdiction n'est satisfaite, alors il existe plusieurs politiques déterminantes. Dans le cas où aucune politique ne correspond et que la réponse est refusée, il n'existe aucune politique déterminante.
## Données sur les entités
Les *données d'entité* sont des données relatives au principal, à l'action et à la ressource. Les données d'entité pertinentes pour l'évaluation des politiques sont l'appartenance à un groupe tout au long de la hiérarchie des entités et les valeurs d'attribut du principal et de la ressource.
## Permissions, autorisations et principes
Verified Permissions gère les autorisations détaillées et *les *autorisations** au sein des applications personnalisées que vous créez.
Un *mandant* est l'utilisateur d'une application, qu'elle soit humaine ou machine, dont l'identité est liée à un identifiant tel qu'un nom d'utilisateur ou un identifiant de machine. Le processus d'authentification détermine si le mandant est réellement l'identité qu'il prétend être.
À cette identité est associé un ensemble d'*autorisations* d'application qui déterminent ce que le principal est autorisé à faire au sein de cette application. L'*autorisation* est le processus qui consiste à évaluer ces autorisations afin de déterminer si un principal est autorisé à effectuer une action particulière dans l'application. Ces autorisations peuvent être exprimées sous forme [de politiques](https://docs.cedarpolicy.com/overview/terminology.html#policy).
## Application des politiques
L'*application des politiques* est le processus qui consiste à appliquer la décision d'évaluation au sein de l'application en dehors des autorisations vérifiées. Si l'évaluation des autorisations vérifiées aboutit à un refus, l'application empêchera le principal d'accéder à la ressource.
## Boutique Policy
Un *magasin de politiques* est un conteneur pour les politiques et les modèles. Chaque magasin contient un schéma qui est utilisé pour valider les politiques ajoutées au magasin. Par défaut, chaque application possède son propre magasin de politiques, mais plusieurs applications peuvent partager un seul magasin de politiques. Lorsqu'une application fait une demande d'autorisation, elle identifie le magasin de politiques utilisé pour évaluer cette demande. Les magasins de politiques permettent d'isoler un ensemble de politiques et peuvent donc être utilisés dans une application multi-locataires pour contenir les schémas et les politiques de chaque locataire. Une seule application peut disposer de magasins de politiques distincts pour chaque locataire.
Lors de l'évaluation [d'une demande d'autorisation](#term-authorization-request), Verified Permissions ne prend en compte que le sous-ensemble des politiques du magasin de politiques qui sont pertinentes pour la demande. La pertinence est déterminée en fonction de la *portée* de la politique. Le champ d'application identifie le principal et la ressource spécifiques auxquels la politique s'applique, ainsi que les actions que le principal peut effectuer sur la ressource. La définition du périmètre permet d'améliorer les performances en réduisant l'ensemble des politiques envisagées.
## Alias du magasin Policy
Un *alias de magasin de politiques* est un nom convivial pour un magasin de politiques. Vous pouvez utiliser un alias de magasin de politiques pour identifier un magasin de politiques dans toute opération d'autorisations vérifiées qui accepte un `policyStoreId` paramètre. Les alias du Policy Store sont des AWS ressources indépendantes dotées de leurs propres ARNs ressources. Chaque alias est associé à un magasin de politiques à la fois, et plusieurs alias peuvent être associés au même magasin de politiques. Pour de plus amples informations, veuillez consulter [Alias de la boutique Amazon Verified Permissions Policy](policy-store-aliases.md).
## Nom de la politique
Un *nom de stratégie* est un nom convivial facultatif pour une stratégie. Les noms des politiques doivent être uniques pour toutes les politiques du magasin de politiques et être préfixés par`name/`. Vous pouvez utiliser un nom de stratégie à la place de l'ID de stratégie dans les opérations du plan de contrôle qui acceptent un `policyId` paramètre. Les noms peuvent être définis lors de la création ou de la mise à jour d'une politique. Uniquement `GetPolicy` et `ListPolicies` renvoyez le nom dans la sortie.
## Nom du modèle de politique
Un *nom de modèle de stratégie* est un nom convivial facultatif pour un modèle de stratégie. Les noms des modèles de stratégie doivent être uniques pour tous les modèles de politiques du magasin de politiques et être préfixés par`name/`. Vous pouvez utiliser un nom de modèle de stratégie à la place de l'ID du modèle de stratégie dans les opérations du plan de contrôle qui acceptent un `policyTemplateId` paramètre. Les noms peuvent être définis lors de la création ou de la mise à jour d'un modèle de politique. Uniquement `GetPolicyTemplate` et `ListPolicyTemplates` renvoyez le nom dans la sortie.
## Politiques satisfaites
Les *politiques satisfaisantes* sont celles qui correspondent aux paramètres de la [demande d'autorisation](#term-authorization-request).
# Différences entre les autorisations vérifiées d'Amazon et le langage de politique de Cedar
Amazon Verified Permissions utilise le moteur de langage de politique Cedar pour effectuer ses tâches d'autorisation. Cependant, il existe certaines différences entre l'implémentation native de Cedar et l'implémentation de Cedar trouvée dans les autorisations vérifiées. Cette rubrique met en évidence ces différences.
## Définition de l'espace de noms
L'implémentation des autorisations vérifiées de Cedar présente les différences suivantes par rapport à l'implémentation native de Cedar :
+ Les autorisations vérifiées ne prennent en charge qu'un seul [espace de noms dans un schéma](https://docs.cedarpolicy.com/schema/schema.html#namespace) défini dans un magasin de politiques.
+ Les autorisations vérifiées ne vous permettent pas de créer un [espace de noms](https://docs.cedarpolicy.com/schema/schema.html#namespace) qui est une chaîne vide ou qui inclut les valeurs suivantes : `aws``amazon`, ou`cedar`.
## Support des modèles de politiques
Verified Permissions et Cedar autorisent les espaces réservés uniquement aux `principal` et`resource`. Cependant, les autorisations vérifiées nécessitent également que ni les `principal` et ne `resource` soient pas illimitées.
La politique suivante est valide dans Cedar mais elle est rejetée par Verified Permissions car elle `principal` n'est pas contrainte.
```
permit(principal, action == Action::"view", resource == ?resource);
```
Les deux exemples suivants sont valides à la fois dans Cedar et dans Verified Permissions, car `principal` les deux `resource` sont soumis à des contraintes.
```
permit(principal == User::"alice", action == Action::"view", resource == ?resource);
```
```
permit(principal == ?principal, action == Action::"a", resource in ?resource);
```
## Support de schéma
Les autorisations vérifiées nécessitent que tous les noms de clé JSON du schéma soient des chaînes non vides. Cedar autorise les chaînes vides dans certains cas, par exemple pour les propriétés ou les espaces de noms.
## Définition des groupes d'action
Les méthodes d'autorisation de Cedar nécessitent une liste des entités à prendre en compte lors de l'évaluation d'une demande d'autorisation par rapport aux politiques.
Vous pouvez définir les actions et les groupes d'actions utilisés par votre application dans le schéma. Toutefois, Cedar n'inclut pas le schéma dans le cadre d'une demande d'évaluation. Au lieu de cela, Cedar utilise le schéma uniquement pour valider les politiques et les modèles de politiques que vous soumettez. Comme Cedar ne fait pas référence au schéma lors des demandes d'évaluation, même si vous avez défini des groupes d'actions dans le schéma, vous devez également inclure la liste de tous les groupes d'actions dans la liste des entités que vous devez transmettre aux opérations de l'API d'autorisation.
Verified Permissions le fait pour vous. Tous les groupes d'actions que vous définissez dans votre schéma sont automatiquement ajoutés à la liste des entités à laquelle vous passez en tant que paramètre des `IsAuthorizedWithToken` opérations `IsAuthorized` or.
## Formatage des entités
Le formatage JSON des entités dans Verified Permissions à l'aide du `entityList` paramètre diffère de celui de Cedar pour les raisons suivantes :
+ Dans Verified Permissions, toutes les paires clé-valeur d'un objet JSON doivent être encapsulées dans un objet JSON portant le nom de. `Record`
+ Une liste JSON dans Verified Permissions doit être encapsulée dans une paire clé-valeur JSON où le nom de la clé est `Set` et la valeur est la liste JSON originale de Cedar.
+ Pour`String`,`Long`, et les noms `Boolean` de type, chaque paire clé-valeur de Cedar est remplacée par un objet JSON dans Verified Permissions. Le nom de l'objet est le nom de clé d'origine. À l'intérieur de l'objet JSON, il existe une paire clé-valeur dont le nom de clé est le nom de type de la valeur scalaire (`String`,`Long`, ou`Boolean`) et la valeur est la valeur de l'entité Cedar.
+ Le formatage syntaxique des entités Cedar et des entités Verified Permissions diffère des manières suivantes :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/verifiedpermissions/latest/userguide/terminology-differences-avp-cedar.html)
**Example - Listes**
Les exemples suivants montrent comment une liste d'entités est exprimée dans Cedar et Verified Permissions, respectivement.
```
[
{
"number": 1
},
{
"sentence": "Here is an example sentence"
},
{
"Question": false
}
]
```
```
{
"Set": [
{
"Record": {
"number": {
"Long": 1
}
}
},
{
"Record": {
"sentence": {
"String": "Here is an example sentence"
}
}
},
{
"Record": {
"question": {
"Boolean": false
}
}
}
]
}
```
**Example - Évaluation des politiques**
Les exemples suivants montrent comment les entités sont formatées pour évaluer une politique dans une demande d'autorisation dans Cedar et Verified Permissions, respectivement.
```
[
{
"uid": {
"type": "PhotoApp::User",
"id": "alice"
},
"attrs": {
"age": 25,
"name": "alice",
"userId": "123456789012"
},
"parents": [
{
"type": "PhotoApp::UserGroup",
"id": "alice_friends"
},
{
"type": "PhotoApp::UserGroup",
"id": "AVTeam"
}
]
},
{
"uid": {
"type": "PhotoApp::Photo",
"id": "vacationPhoto.jpg"
},
"attrs": {
"private": false,
"account": {
"__entity": {
"type": "PhotoApp::Account",
"id": "ahmad"
}
}
},
"parents": []
},
{
"uid": {
"type": "PhotoApp::UserGroup",
"id": "alice_friends"
},
"attrs": {},
"parents": []
},
{
"uid": {
"type": "PhotoApp::UserGroup",
"id": "AVTeam"
},
"attrs": {},
"parents": []
}
]
```
```
[
{
"Identifier": {
"EntityType": "PhotoApp::User",
"EntityId": "alice"
},
"Attributes": {
"age": {
"Long": 25
},
"name": {
"String": "alice"
},
"userId": {
"String": "123456789012"
}
},
"Parents": [
{
"EntityType": "PhotoApp::UserGroup",
"EntityId": "alice_friends"
},
{
"EntityType": "PhotoApp::UserGroup",
"EntityId": "AVTeam"
}
]
},
{
"Identifier": {
"EntityType": "PhotoApp::Photo",
"EntityId": "vacationPhoto.jpg"
},
"Attributes": {
"private": {
"Boolean": false
},
"account": {
"EntityIdentifier": {
"EntityType": "PhotoApp::Account",
"EntityId": "ahmad"
}
}
},
"Parents": []
},
{
"Identifier": {
"EntityType": "PhotoApp::UserGroup",
"EntityId": "alice_friends"
},
"Parents": []
},
{
"Identifier": {
"EntityType": "PhotoApp::UserGroup",
"EntityId": "AVTeam"
},
"Parents": []
}
]
```
## Limites de longueur et de taille
Verified Permissions prend en charge le stockage sous forme de magasins de politiques pour stocker vos schémas, politiques et modèles de politiques. Ce stockage oblige les autorisations vérifiées à imposer des limites de longueur et de taille qui ne sont pas pertinentes pour Cedar.
| Objet | Limite d'autorisations vérifiées (en octets) | Limite de cèdre |
| --- | --- | --- |
| Taille de la politique¹ | 10 000 | Aucune |
| Description de la politique en ligne | 150 | Non applicable au cèdre |
| Taille du modèle de politique | 10 000 | Aucune |
| Taille du schéma | 100 000 | Aucune |
| Type d’entité | 200 | Aucune |
| ID de stratégie | 64 | Aucune |
| ID du modèle de politique | 64 | Aucune |
| ID de l'entité | 200 | Aucune |
| ID du magasin Policy | 64 | Non applicable au cèdre |
¹ Il existe une limite de politiques par magasin de politiques dans les autorisations vérifiées en fonction de la taille combinée des principes, des actions et des ressources des politiques créées dans le magasin de politiques. La taille totale de toutes les politiques relatives à une seule ressource ne peut pas dépasser 200 000 octets. Pour les politiques liées à un modèle, la taille du modèle de stratégie n'est comptée qu'une seule fois, plus la taille de chaque ensemble de paramètres utilisé pour instancier chaque politique liée au modèle.