Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Esempio 3: controllo degli accessi multi-tenant con RBAC
<a name="avp-mt-abac-examples"></a>

Per approfondire il precedente esempio RBAC, è possibile espandere i requisiti per includere la multi-tenancy SaaS, che è un requisito comune per i provider SaaS. Nelle soluzioni multi-tenant, l'accesso alle risorse viene sempre fornito per conto di un determinato tenant. Cioè, gli utenti del Tenant A non possono visualizzare i dati del Tenant B, anche se tali dati sono collocati logicamente o fisicamente in un sistema. L'esempio seguente illustra come implementare l'isolamento dei tenant utilizzando più [archivi di policy per le autorizzazioni verificate](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html) e come utilizzare i ruoli utente per definire le autorizzazioni all'interno del tenant. 

L'utilizzo del modello di progettazione Per Tenant Policy Store è una best practice per mantenere l'isolamento dei tenant durante l'implementazione del controllo degli accessi con autorizzazioni verificate. In questo scenario, le richieste degli utenti Tenant A e Tenant B vengono verificate in archivi di policy separati e, rispettivamente. `DATAMICROSERVICE_POLICYSTORE_A` `DATAMICROSERVICE_POLICYSTORE_B` Per ulteriori informazioni sulle considerazioni sulla progettazione delle autorizzazioni verificate per applicazioni SaaS multi-tenant, consulta la sezione Considerazioni sulla progettazione multi-tenant [delle autorizzazioni verificate](avp-design-considerations.md).

![Esempio di controllo degli accessi multi-tenant con RBAC, Amazon Verified Permissions e Cedar](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-3.png)


La seguente policy si trova nel Policy Store. `DATAMICROSERVICE_POLICYSTORE_A` Verifica che il principale faccia parte del gruppo `allAccessRole` di tipi. `Role` In questo caso, il committente sarà autorizzato a eseguire le `updateData` azioni `viewData` e su tutte le risorse associate al Tenant A.

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

Le seguenti politiche si trovano nell'archivio delle `DATAMICROSERVICE_POLICYSTORE_B` politiche. La prima policy verifica che il principale faccia parte del `updateDataRole` gruppo di tipi. `Role` Supponendo che sia così, autorizza i mandanti a eseguire l'`updateData`azione sulle risorse associate al Tenant B.

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

Questa seconda politica impone che i committenti che fanno parte del `viewDataRole` gruppo di tipo `Role` siano autorizzati a eseguire l'`viewData`azione sulle risorse associate al Tenant B.

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

La richiesta di autorizzazione effettuata dal Tenant A deve essere inviata al `DATAMICROSERVICE_POLICYSTORE_A` policy store e verificata in base alle politiche che appartengono a tale archivio. In questo caso, viene verificata in base alla prima politica discussa in precedenza come parte di questo esempio. In questa richiesta di autorizzazione, il principale di tipo `User` con valore di `Alice` richiede di eseguire l'`viewData`azione. Il principale appartiene al gruppo `allAccessRole` di tipi`Role`. Alice sta cercando di eseguire l'`viewData`azione sulla `SampleData` risorsa. Poiché Alice ha il `allAccessRole` ruolo, questa valutazione porta a una `ALLOW` decisione.

```
{
  "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": []
      }
    ]
  }
}
```

Se, invece, visualizzi una richiesta fatta dal Tenant B da`User Bob`, vedrai qualcosa come la seguente richiesta di autorizzazione. La richiesta viene inviata al `DATAMICROSERVICE_POLICYSTORE_B` policy store perché proviene dal Tenant B. In questa richiesta, il principale `Bob` desidera eseguire l'azione `updateData` sulla risorsa. `SampleData` Tuttavia, non `Bob` fa parte di un gruppo che ha accesso all'azione `updateData` su quella risorsa. Pertanto, la richiesta dà luogo a una `DENY` decisione.

```
{
  "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": []
      }
    ]
  }
}
```

In questo terzo esempio, `User Alice ` tenta di eseguire l'`viewData`azione sulla risorsa`SampleData`. Questa richiesta viene indirizzata al `DATAMICROSERVICE_POLICYSTORE_A` policy store perché il responsabile `Alice` appartiene al Tenant A. `Alice` fa parte del gruppo `allAccessRole` del tipo`Role`, che le consente di eseguire l'`viewData`azione sulle risorse. Pertanto, la richiesta dà luogo a una `ALLOW` decisione.

```
{
  "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": []
      }
    ]
  }
}
```