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 1: ABAC básico con permisos verificados y Cedar En este escenario de ejemplo, Amazon Verified Permissions se utiliza para determinar qué usuarios pueden acceder a la información de un microservicio de nómina ficticio. Esta sección incluye fragmentos de código de Cedar para demostrar cómo se puede utilizar Cedar para tomar decisiones de control de acceso. Estos ejemplos no pretenden ofrecer una exploración completa de las capacidades que ofrecen Cedar y Verified Permissions. Para obtener una descripción más completa de Cedar, consulte la [documentación de Cedar](https://docs.cedarpolicy.com/). En el siguiente diagrama, nos gustaría aplicar dos reglas comerciales generales asociadas al `viewSalary` `GET` método: *los empleados pueden ver su propio salario* y *los empleados pueden ver el salario de cualquier persona que dependa de ellos.* Puedes hacer cumplir estas reglas empresariales mediante las políticas de permisos verificados. ![Ejemplo de una implementación básica de ABAC 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-1.png) *Los empleados pueden ver su propio salario.* En Cedar, la construcción básica es una *entidad*, que representa un principal, una acción o un recurso. Para realizar una solicitud de autorización e iniciar una evaluación con una política de permisos verificados, debe proporcionar una entidad *principal,* una *acción*, un *recurso* y una *lista de entidades.* + El principal (`principal`) es el usuario o rol que ha iniciado sesión. + La acción (`action`) es la operación que evalúa la solicitud. + El recurso (`resource`) es el componente al que accede la acción. + La lista de entidades (`entityList`) contiene todas las entidades necesarias para evaluar la solicitud. Para cumplir con la norma empresarial, *los empleados pueden ver su propio salario*, puedes proporcionar una política de permisos verificados como la siguiente. ``` permit ( principal, action == Action::"viewSalary", resource ) when { principal == resource.owner }; ``` Esta política evalúa `ALLOW` si el atributo `Action` is `viewSalary` y el recurso de la solicitud tienen un propietario de atributo igual al principal. Por ejemplo, si Bob es el usuario registrado que solicitó el informe salarial y también es el propietario del informe salarial, la política se evalúa como. `ALLOW` La siguiente solicitud de autorización se envía a Verified Permissions para que la evalúe el modelo de política. En este ejemplo, Bob es el usuario que ha iniciado sesión y que realiza la `viewSalary` solicitud. Por lo tanto, Bob es el principal del tipo de entidad`Employee`. La acción que Bob intenta realizar es de ese tipo `viewSalary,` y el recurso que se `viewSalary` mostrará es `Salary-Bob` de ese tipo`Salary`. Para evaluar si Bob puede ver el `Salary-Bob` recurso, es necesario proporcionar una estructura de entidad que vincule el tipo `Employee` con un valor `Bob` (el principal) con el atributo propietario del recurso que contiene el tipo`Salary`. Esta estructura se proporciona en un`entityList`, donde los atributos asociados `Salary` incluyen un propietario, que especifica un propietario `entityIdentifier` que contiene el tipo `Employee` y el valor`Bob`. Verified Permissions compara lo `principal` proporcionado en la solicitud de autorización con el `owner` atributo asociado al `Salary` recurso para tomar una decisión. ``` { "policyStoreId": "PAYROLLAPP_POLICYSTOREID", "principal": { "entityType": "PayrollApp::Employee", "entityId": "Bob" }, "action": { "actionType": "PayrollApp::Action", "actionId": "viewSalary" }, "resource": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "entities": { "entityList": [ { "identifier": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "attributes": { "owner": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" } } } }, { "identifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" }, "attributes": {} } ] } } ``` La solicitud de autorización a Verified Permissions devuelve lo siguiente como resultado, donde el atributo `decision` es `ALLOW` o`DENY`. ``` { "determiningPolicies": [ { "determiningPolicyId": "PAYROLLAPP_POLICYSTOREID" } ], "decision": "ALLOW", "errors": [] } ``` En este caso, dado que Bob estaba intentando ver su propio salario, la solicitud de autorización enviada a Verified Permissions equivale a`ALLOW`. Sin embargo, nuestro objetivo era utilizar los permisos verificados para hacer cumplir dos normas empresariales. La regla empresarial que establece lo siguiente también debería ser cierta: *Los empleados pueden ver el salario de cualquier persona que dependa de ellos.* Para cumplir con esta regla empresarial, puede proporcionar otra política. La siguiente política evalúa `ALLOW` si la acción es igual al principal `viewSalary` y si el recurso de la solicitud tiene un atributo `owner.manager` igual al principal. Por ejemplo, si Alice es la usuaria que inició sesión y solicitó el informe salarial y Alice es la administradora del propietario del informe, la política se evaluará como tal. `ALLOW` ``` permit ( principal, action == Action::"viewSalary", resource ) when { principal == resource.owner.manager }; ``` La siguiente solicitud de autorización se envía a Verified Permissions para que la evalúe el modelo de política. En este ejemplo, Alice es el usuario que ha iniciado sesión y que realiza la `viewSalary` solicitud. Por lo tanto, Alice es la principal y la entidad es de ese tipo`Employee`. La acción que Alice intenta realizar es`viewSalary`, y el recurso que `viewSalary` se mostrará es del tipo `Salary` con un valor de`Salary-Bob`. Para evaluar si Alice puede ver el `Salary-Bob` recurso, debe proporcionar una estructura de entidad que vincule el tipo `Employee` con un valor de `Alice` con el `manager` atributo, que luego debe asociarse al `owner` atributo del tipo `Salary` con un valor de`Salary-Bob`. Esta estructura se proporciona en una`entityList`, donde los atributos asociados `Salary` incluyen un propietario, que especifica una `entityIdentifier` que contiene el tipo `Employee` y el valor`Bob`. Verified Permissions comprueba primero el `owner` atributo, que evalúa el tipo `Employee` y el valor`Bob`. A continuación, Verified Permissions evalúa el `manager` atributo asociado `Employee` y lo compara con el principal proporcionado para tomar una decisión de autorización. En este caso, la decisión se `ALLOW` debe a que los `resource.owner.manager` atributos `principal ` y son equivalentes. ``` { "policyStoreId": "PAYROLLAPP_POLICYSTOREID", "principal": { "entityType": "PayrollApp::Employee", "entityId": "Alice" }, "action": { "actionType": "PayrollApp::Action", "actionId": "viewSalary" }, "resource": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "entities": { "entityList": [ { "identifier": { "entityType": "PayrollApp::Employee", "entityId": "Alice" }, "attributes": { "manager": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "None" } } }, "parents": [] }, { "identifier": { "entityType": "PayrollApp::Salary", "entityId": "Salary-Bob" }, "attributes": { "owner": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" } } }, "parents": [] }, { "identifier": { "entityType": "PayrollApp::Employee", "entityId": "Bob" }, "attributes": { "manager": { "entityIdentifier": { "entityType": "PayrollApp::Employee", "entityId": "Alice" } } }, "parents": [] } ] } } ``` Hasta ahora, en este ejemplo, hemos proporcionado las dos reglas de negocio asociadas al `viewSalary` método: *los empleados pueden ver su propio salario* y *los empleados pueden ver el salario de cualquier persona que dependa de ellos. Los* permisos verificados son políticas para cumplir las condiciones de cada regla de negocio de forma independiente. También puede utilizar una única política de permisos verificados para cumplir las condiciones de ambas reglas empresariales: *Los empleados pueden ver su propio salario y el de cualquier persona que dependa de ellos.* Al utilizar la solicitud de autorización anterior, la siguiente política evalúa `ALLOW` si la acción es `viewSalary` y el recurso de la solicitud tiene un atributo `owner.manager` igual a o un atributo `owner` igual a. `principal` `principal` ``` permit ( principal, action == PayrollApp::Action::"viewSalary", resource ) when { principal == resource.owner.manager || principal == resource.owner }; ``` Por ejemplo, si Alice es el usuario que ha iniciado sesión y solicita el informe salarial y si Alice es la gestora del propietario o la propietaria del informe, la política se evalúa como. `ALLOW` Para obtener más información sobre el uso de operadores lógicos con las políticas de Cedar, consulte la [documentación de Cedar](https://docs.cedarpolicy.com/policies/syntax-operators.html).