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 2: RBAC básico con permisos verificados y Cedar
<a name="avp-basic-rbac-examples"></a>

En este ejemplo, se utilizan permisos verificados y Cedar para demostrar el RBAC básico. Como se mencionó anteriormente, la construcción básica de Cedar es una entidad. Los desarrolladores definen sus propias entidades y, si lo desean, pueden crear relaciones entre entidades. El siguiente ejemplo incluye tres tipos de entidades: `Users``Roles`, y`Problems`. `Students`y `Teachers` pueden considerarse entidades de este tipo `Role,` y cada una de ellas `User` puede estar asociada a cero o a cualquiera de las`Roles`.

![Ejemplo de implementación básica de RBAC con Amazon Verified Permissions y Cedar para implementar un PDP](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-2.png)


En Cedar, estas relaciones se expresan vinculando el `Role` `Student` a `User` `Bob` como su matriz. Esta asociación agrupa de forma lógica a todos los usuarios estudiantes en un grupo. Para obtener más información sobre la agrupación en Cedar, consulte la documentación de [Cedar](https://docs.cedarpolicy.com/overview/terminology.html#term-group).

La siguiente política evalúa la decisión de la acción `ALLOW` `submitProblem,` para todos los principales que están vinculados al grupo lógico `Students` de este tipo. `Role`

```
permit (
    principal in ElearningApp::Role::"Students",
    action == ElearningApp::Action::"submitProblem",
    resource
);
```

La siguiente política evalúa la decisión `ALLOW` de la acción `submitProblem` o `answerProblem` de todos los principios que están vinculados al grupo `Teachers` lógico de este tipo. `Role`

```
permit (
    principal in ElearningApp::Role::"Teachers",
    action in [
        ElearningApp::Action::"submitProblem",
        ElearningApp::Action::"answerProblem"
    ],
    resource
);
```

Para evaluar las solicitudes con estas políticas, el motor de evaluación necesita saber si el director al que se hace referencia en la solicitud de autorización es miembro del grupo apropiado. Por lo tanto, la solicitud debe transmitir la información relevante sobre la pertenencia al grupo al motor de evaluación como parte de la solicitud de autorización. Esto se hace a través de la `entities` propiedad, que le permite proporcionar al motor de evaluación de Cedar los datos sobre los atributos y la pertenencia al grupo del director y el recurso involucrados en la solicitud de autorización. En el siguiente código, la pertenencia a un grupo se indica definiendo `User::"Bob"` como la llamada a un padre`Role::"Students"`.

```
{
  "policyStoreId": "ELEARNING_POLICYSTOREID",
  "principal": {
    "entityType": "ElearningApp::User",
    "entityId": "Bob"
  },
  "action": {
    "actionType": "ElearningApp::Action",
    "actionId": "answerProblem"
  },
  "resource": {
    "entityType": "ElearningApp::Problem",
    "entityId": "SomeProblem"
  },
  "entities": {
    "entityList": [
        {
            "identifier": {
                "entityType": "ElearningApp::User",
                "entityId": "Bob"
            },
            "attributes": {},
            "parents": [
                {
                    "entityType": "ElearningApp::Role",
                    "entityId": "Students"
                } 
            ]
        },
        {
          "identifier": {
            "entityType": "ElearningApp::Problem",
            "entityId": "SomeProblem"
          },
          "attributes": {},
          "parents": []
        }
      ]
  }
}
```

En este ejemplo, Bob es el usuario registrado que realiza la `answerProblem` solicitud. Por lo tanto, Bob es el principal y la entidad es de ese tipo`User`. La acción que Bob intenta realizar es`answerProblem`. Para evaluar si Bob puede realizar la `answerProblem` acción, es necesario proporcionar una estructura de entidad que vincule a la entidad `User` con un valor de `Bob` y asigne su pertenencia a un grupo mediante la inclusión de una entidad principal como`Role::"Students"`. Como las entidades del grupo `Role::"Students"` de usuarios solo pueden realizar la acción`submitProblem`, esta solicitud de autorización se evalúa como. `DENY`

Por otro lado, si el tipo `User` que tiene un valor de `Alice` y forma parte del grupo `Role::"Teachers"` intenta realizar la `answerProblem` acción, la solicitud de autorización se evalúa como tal`ALLOW`, ya que la política establece que los directores del grupo pueden realizar la acción `answerProblem` en todos `Role::"Teachers"` los recursos. El código siguiente muestra este tipo de solicitud de autorización que se evalúa como. `ALLOW`

```
{
  "policyStoreId": "ELEARNING_POLICYSTOREID",
  "principal": {
    "entityType": "ElearningApp::User",
    "entityId": "Alice"
  },
  "action": {
    "actionType": "ElearningApp::Action",
    "actionId": "answerProblem"
  },
  "resource": {
    "entityType": "ElearningApp::Problem",
    "entityId": "SomeProblem"
  },
  "entities": {
    "entityList": [
        {
            "identifier": {
                "entityType": "ElearningApp::User",
                "entityId": "Alice"
            },
            "attributes": {},
            "parents": [
                {
                    "entityType": "ElearningApp::Role",
                    "entityId": "Teachers"
                } 
            ]
        },
        {
            "identifier": {
                "entityType": "ElearningApp::Problem",
                "entityId": "SomeProblem"
            },
            "attributes": {},
            "parents": []
        }
      ]
  }
}
```