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.

# Exemples de politiques d'identité dans Amazon SES
<a name="identity-authorization-policy-examples"></a>

L'autorisation de l'identité vous permet de spécifier les conditions précises dans lesquelles vous autorisez ou refusez les actions de l'API pour une identité.

**Topics**
+ [Spécifier le principal](#identity-authorization-policy-example-delegate-user)
+ [Restriction de l'action](#sending-authorization-policy-example-restricting-action)
+ [Utilisation de plusieurs instructions](#identity-authorization-policy-example-multiple-statements)

## Spécifier le principal
<a name="identity-authorization-policy-example-delegate-user"></a>

Le *principal*, qui est l'entité à laquelle vous accordez l'autorisation Compte AWS, peut être un utilisateur Gestion des identités et des accès AWS (IAM) ou un AWS service appartenant au même compte.

*L'exemple suivant montre une politique simple qui permet à l' AWS ID *123456789012* de contrôler l'identité vérifiée *exemple.com*, qui appartient également à 123456789012. Compte AWS * 

------
#### [ JSON ]

****  

```
{
  "Id":"SampleAuthorizationPolicy",
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Sid":"AuthorizeMarketer",
      "Effect":"Allow",
      "Resource":"arn:aws:ses:us-east-1:123456789012:identity/example.com",
      "Principal":{
        "AWS":[
          "123456789012"
        ]
      },
      "Action":[
        "ses:DeleteEmailIdentity",
        "ses:PutEmailIdentityDkimSigningAttributes"
      ]
    }
  ]
}
```

------

L'exemple de stratégie suivant accorde des autorisations à deux utilisateurs pour contrôler l'identité vérifiée *example.com*. Les utilisateurs sont spécifiés par leur Amazon Resource Name (ARN).

------
#### [ JSON ]

****  

```
{
  "Id":"ExampleAuthorizationPolicy",
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Sid":"AuthorizeIAMUser",
      "Effect":"Allow",
      "Resource":"arn:aws:ses:us-east-1:123456789012:identity/example.com",
      "Principal":{
        "AWS":[
          "arn:aws:iam::123456789012:user/John",
          "arn:aws:iam::123456789012:user/Jane"
        ]
      },
      "Action":[
        "ses:DeleteEmailIdentity",
        "ses:PutEmailIdentityDkimSigningAttributes"
      ]
    }
  ]
}
```

------

## Restriction de l'action
<a name="sending-authorization-policy-example-restricting-action"></a>

Il existe plusieurs actions qui peuvent être spécifiées dans une stratégie d'autorisation d'identité en fonction du niveau de contrôle que vous souhaitez autoriser :

```
 1. "BatchGetMetricData",
 2. "ListRecommendations",
 3. "CreateDeliverabilityTestReport",
 4. "CreateEmailIdentityPolicy",
 5. "DeleteEmailIdentity",
 6. "DeleteEmailIdentityPolicy",
 7. "GetDomainStatisticsReport",
 8. "GetEmailIdentity",
 9. "GetEmailIdentityPolicies",
10. "PutEmailIdentityConfigurationSetAttributes",
11. "PutEmailIdentityDkimAttributes",
12. "PutEmailIdentityDkimSigningAttributes",
13. "PutEmailIdentityFeedbackAttributes",
14. "PutEmailIdentityMailFromAttributes",
15. "TagResource",
16. "UntagResource",
17. "UpdateEmailIdentityPolicy"
```

Les stratégies d'autorisation d'identité vous permettent également de restreindre le principal à une seule de ces actions.

------
#### [ JSON ]

****  

```
{
    "Id": "ExamplePolicy",
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ControlAction",
            "Effect": "Allow",
            "Resource": "arn:aws:ses:us-east-1:123456789012:identity/example.com",
            "Principal": {
                "AWS": [
                    "123456789012"
                ]
            },
            "Action": [
                "ses:PutEmailIdentityMailFromAttributes"
            ]
        }
    ]
}
```

------

## Utilisation de plusieurs instructions
<a name="identity-authorization-policy-example-multiple-statements"></a>

Votre stratégie d'autorisation d'identité peut inclure plusieurs instructions. L'exemple de stratégie suivant comporte deux instructions. La première déclaration interdit à deux utilisateurs d'accéder à `getemailidentity` à partir de *sender@example.com* au sein du même compte `123456789012`. La deuxième déclaration refuse l'accès à `UpdateEmailIdentityPolicy` au principal, *Jack*, dans le même compte `123456789012`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement":[
    {
      "Sid":"DenyGet",
      "Effect":"Deny",
      "Resource":"arn:aws:ses:us-east-1:123456789012:identity/sender@example.com",
      "Principal":{
        "AWS":[
          "arn:aws:iam::123456789012:user/John", 
          "arn:aws:iam::123456789012:user/Jane"
        ]
      },
      "Action":[
        "ses:GetEmailIdentity"
      ]
    },
    {
      "Sid":"DenyUpdate",
      "Effect":"Deny",
      "Resource":"arn:aws:ses:us-east-1:123456789012:identity/sender@example.com",
      "Principal":{
        "AWS":"arn:aws:iam::123456789012:user/Jack"
      },
      "Action":[
        "ses:UpdateEmailIdentityPolicy"
      ]
    }
  ]
}
```

------