Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Ejemplo 3: Control de acceso multiusuario con RBAC
<a name="avp-mt-abac-examples"></a>

Para profundizar en el ejemplo anterior de RBAC, puede ampliar sus requisitos para incluir la multitenencia de SaaS, que es un requisito común para los proveedores de SaaS. En las soluciones multiarrendatario, el acceso a los recursos siempre se proporciona en nombre de un arrendatario determinado. Es decir, los usuarios del arrendatario A no pueden ver los datos del arrendatario B, incluso si esos datos están colocados lógica o físicamente en un sistema. El siguiente ejemplo ilustra cómo puede implementar el aislamiento de inquilinos mediante varios [almacenes de políticas de permisos verificados](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html) y cómo puede emplear las funciones de usuario para definir los permisos dentro del inquilino. 

Utilizar el patrón de diseño del almacén de políticas por inquilino es una práctica recomendada para mantener el aislamiento de los inquilinos y, al mismo tiempo, implementar el control de acceso con permisos verificados. En este escenario, las solicitudes de los usuarios del inquilino A y del inquilino B se verifican comparándolas con almacenes de políticas independientes `DATAMICROSERVICE_POLICYSTORE_A` y`DATAMICROSERVICE_POLICYSTORE_B`, respectivamente. Para obtener más información sobre las consideraciones de diseño de permisos verificados para aplicaciones SaaS de varios inquilinos, consulte [la sección Consideraciones de diseño de permisos verificados para múltiples inquilinos](avp-design-considerations.md).

![Ejemplo de control de acceso de múltiples inquilinos con RBAC, Amazon Verified Permissions y Cedar](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-3.png)


La siguiente política se encuentra en el almacén de políticas. `DATAMICROSERVICE_POLICYSTORE_A` Verifica que el principal formará parte del grupo `allAccessRole` de tipo`Role`. En este caso, el director podrá realizar `updateData` las acciones `viewData` y acciones en todos los recursos que estén asociados al inquilino A.

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

Las siguientes políticas se encuentran en el almacén `DATAMICROSERVICE_POLICYSTORE_B` de políticas. La primera política comprueba que el principal forma parte del `updateDataRole` grupo de tipos`Role`. Suponiendo que ese sea el caso, da permiso a los directores para realizar la `updateData` acción con los recursos que están asociados al inquilino B.

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

Esta segunda política exige que los directores que formen parte del `viewDataRole` grupo de este tipo `Role` puedan realizar la `viewData` acción con los recursos asociados al arrendatario B.

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

La solicitud de autorización realizada por el arrendatario A debe enviarse al almacén `DATAMICROSERVICE_POLICYSTORE_A` de políticas y verificarse mediante las políticas que pertenecen a ese almacén. En este caso, se verifica mediante la primera política analizada anteriormente como parte de este ejemplo. En esta solicitud de autorización, el principal de tipo `User` con un valor de `Alice` solicita realizar la `viewData` acción. El principal pertenece al grupo `allAccessRole` de tipos`Role`. Alice está intentando realizar la `viewData` acción en el `SampleData` recurso. Como Alice tiene la `allAccessRole` función, esta evaluación da como resultado una `ALLOW` decisión.

```
{
  "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, por el contrario, consulta una solicitud realizada por el inquilino B`User Bob`, verá algo parecido a la siguiente solicitud de autorización. La solicitud se envía al almacén de `DATAMICROSERVICE_POLICYSTORE_B` políticas porque proviene del arrendatario B. En esta solicitud, el director `Bob` desea realizar la acción `updateData` en el recurso`SampleData`. Sin embargo, `Bob` no forma parte de un grupo que tenga acceso a la acción `updateData` de ese recurso. Por lo tanto, la solicitud da lugar a una `DENY` decisión.

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

En este tercer ejemplo, `User Alice ` intenta realizar la `viewData` acción en el recurso`SampleData`. Esta solicitud se dirige al almacén de `DATAMICROSERVICE_POLICYSTORE_A` políticas porque la principal `Alice` pertenece al arrendatario A. `Alice` forma parte de este tipo `allAccessRole` de grupo`Role`, lo que le permite realizar la `viewData` acción con los recursos. Como tal, la solicitud da lugar a una `ALLOW` decisión.

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