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 3 : contrôle d'accès multi-locataires avec RBAC
<a name="avp-mt-abac-examples"></a>

Pour développer l'exemple RBAC précédent, vous pouvez étendre vos exigences pour inclure la mutualisation du SaaS, qui est une exigence courante pour les fournisseurs de SaaS. Dans les solutions multi-locataires, l'accès aux ressources est toujours fourni au nom d'un locataire donné. En d'autres termes, les utilisateurs du locataire A ne peuvent pas voir les données du locataire B, même si ces données sont logiquement ou physiquement colocalisées dans un système. L'exemple suivant montre comment vous pouvez implémenter l'isolation des locataires en utilisant plusieurs [magasins de politiques d'autorisations vérifiées](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html), et comment vous pouvez utiliser des rôles d'utilisateur pour définir des autorisations au sein du locataire. 

L'utilisation du modèle de conception Per Tenant Policy Store est une bonne pratique pour maintenir l'isolement des locataires tout en mettant en œuvre un contrôle d'accès avec des autorisations vérifiées. Dans ce scénario, les demandes des utilisateurs du locataire A et du locataire B sont vérifiées par rapport à des magasins de politiques distincts, `DATAMICROSERVICE_POLICYSTORE_A` et`DATAMICROSERVICE_POLICYSTORE_B`, respectivement. Pour plus d'informations sur les considérations relatives à la conception des autorisations vérifiées pour les applications SaaS multi-locataires, consultez la section [Considérations relatives à la conception multi-locataires des autorisations vérifiées](avp-design-considerations.md).

![Exemple de contrôle d'accès multi-locataires avec RBAC, Amazon Verified Permissions et Cedar](http://docs.aws.amazon.com/fr_fr/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-3.png)


La politique suivante se trouve dans le magasin `DATAMICROSERVICE_POLICYSTORE_A` de politiques. Il vérifie que le principal fera partie du groupe `allAccessRole` de type`Role`. Dans ce cas, le principal sera autorisé à effectuer les `updateData` actions `viewData` et sur toutes les ressources associées au locataire A.

```
permit (
    principal in MultitenantApp::Role::"allAccessRole",
    action in [
        MultitenantApp::Action::"viewData",
        MultitenantApp::Action::"updateData"
    ],
    resource
);
```

Les politiques suivantes se trouvent dans le magasin `DATAMICROSERVICE_POLICYSTORE_B` de politiques. La première politique vérifie que le principal fait partie du `updateDataRole` groupe de types`Role`. En supposant que tel soit le cas, il autorise les principaux à effectuer l'`updateData`action sur les ressources associées au locataire B.

```
permit (
    principal in MultitenantApp::Role::"updateDataRole",
    action == MultitenantApp::Action::"updateData",
    resource
);
```

Cette deuxième politique stipule que les principaux qui font partie du `viewDataRole` groupe de types `Role` doivent être autorisés à effectuer l'`viewData`action sur les ressources associées au locataire B.

```
permit (
    principal in MultitenantApp::Role::"viewDataRole",
    action == MultitenantApp::Action::"viewData",
    resource
);
```

La demande d'autorisation faite par le locataire A doit être envoyée au magasin de `DATAMICROSERVICE_POLICYSTORE_A` politiques et vérifiée par les politiques appartenant à ce magasin. Dans ce cas, cela est vérifié par la première politique décrite précédemment dans le cadre de cet exemple. Dans cette demande d'autorisation, le principal de type `User` avec une valeur `Alice` de demande d'effectuer l'`viewData`action. Le principal appartient au groupe `allAccessRole` de types`Role`. Alice essaie d'exécuter l'`viewData`action sur la `SampleData` ressource. Alice ayant un `allAccessRole` rôle à jouer, cette évaluation aboutit à une `ALLOW` décision.

```
{
  "policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
  "principal": {
      "entityType": "MultitenantApp::User",
      "entityId": "Alice"
  },
  "action": {
      "actionType": "MultitenantApp::Action",
      "actionId": "viewData"
  },
  "resource": {
      "entityType": "MultitenantApp::Data",
      "entityId": "SampleData"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
            "entityType": "MultitenantApp::User",
            "entityId": "Alice"
        },
        "attributes": {},
        "parents": [
            {
                "entityType": "MultitenantApp::Role",
                "entityId": "allAccessRole"
            }
        ]
      },
      {
        "identifier": {
            "entityType": "MultitenantApp::Data",
            "entityId": "SampleData"
        },
        "attributes": {},
        "parents": []
      }
    ]
  }
}
```

Si, au contraire, vous consultez une demande faite par le locataire B`User Bob`, vous verrez quelque chose comme la demande d'autorisation suivante. La demande est envoyée au magasin de `DATAMICROSERVICE_POLICYSTORE_B` politiques car elle provient du locataire B. Dans cette demande, le principal `Bob` souhaite effectuer l'action `updateData` sur la ressource`SampleData`. Cependant, ne `Bob` fait pas partie d'un groupe ayant accès à l'action `updateData` sur cette ressource. La demande aboutit donc à une `DENY` décision.

```
{
  "policyStoreId": "DATAMICROSERVICE_POLICYSTORE_B",
  "principal": {
      "entityType": "MultitenantApp::User",
      "entityId": "Bob"
  },
  "action": {
      "actionType": "MultitenantApp::Action",
      "actionId": "updateData"
  },
  "resource": {
      "entityType": "MultitenantApp::Data",
      "entityId": "SampleData"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
            "entityType": "MultitenantApp::User",
            "entityId": "Bob"
        },
        "attributes": {},
        "parents": [
            {
                "entityType": "MultitenantApp::Role",
                "entityId": "viewDataRole"
            }
        ]
      },
      {
        "identifier": {
            "entityType": "MultitenantApp::Data",
            "entityId": "SampleData"
        },
        "attributes": {},
        "parents": []
      }
    ]
  }
}
```

Dans ce troisième exemple, `User Alice ` essaie d'exécuter l'`viewData`action sur la ressource`SampleData`. Cette demande est dirigée vers le magasin de `DATAMICROSERVICE_POLICYSTORE_A` politiques car le principal `Alice` appartient à la locataire A. `Alice` fait partie du groupe `allAccessRole` de ce type`Role`, ce qui lui permet d'effectuer l'`viewData`action sur les ressources. En tant que telle, la demande aboutit à une `ALLOW` décision.

```
{
  "policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
  "principal": {
      "entityType": "MultitenantApp::User",
      "entityId": "Alice"
  },
  "action": {
      "actionType": "MultitenantApp::Action",
      "actionId": "viewData"
  },
  "resource": {
      "entityType": "MultitenantApp::Data",
      "entityId": "SampleData"
  },
  "entities": {
    "entityList": [
      {
        "identifier": {
            "entityType": "MultitenantApp::User",
            "entityId": "Alice"
        },
        "attributes": {},
        "parents": [
            {
                "entityType": "MultitenantApp::Role",
                "entityId": "allAccessRole"
            }
        ]
      },
      {
        "identifier": {
            "entityType": "MultitenantApp::Data",
            "entityId": "SampleData"
        },
        "attributes": {},
        "parents": []
      }
    ]
  }
}
```