Establezca una jerarquía de roles dependientes

Pega Platform™ le permite definir una jerarquía de dependencia de los roles de acceso que le permiten personalizar el control de acceso para los casos de uso que requieren permisos específicos y, al mismo tiempo, conservar los permisos heredados de un rol de acceso estándar. El concepto detrás de la dependencia de un rol es que, en lugar de que un cliente “clone” un rol y luego lo personalice, el cliente crea un nuevo rol que se basa en, y depende de, un rol de Pega que se envía con el producto. El nuevo rol del cliente no solo tendrá los privilegios proporcionados por su rol personalizado, sino que también heredará los privilegios proporcionados por el rol dependiente.

El uso de roles dependientes ayuda a estandarizar los permisos en todas las aplicaciones y mejora la capacidad de mantenimiento del modelo de control de acceso.

Un rol de acceso MyApp:User puede, por ejemplo, configurarse como dependiente del rol de acceso a Pega Platform™ PegaRULES:User4, y heredar todas las autorizaciones disponibles en el rol dependiente sin definir registros explícitos de Access of Role Object (Rol de acceso a objeto) (ARO) para MyApp:User. Puede definir esto al hacer clic en Manage dependent roles (Gestionar los roles dependientes).

En el cuadro de diálogo Manage dependent roles, en el campo Dependent roles, escriba o seleccione un rol de usuario.

En este ejemplo, cualquier grupo de acceso que incluya el rol de acceso MyApp:User permanece autorizado para leer y escribir instancias de cualquier tipo de caso a pesar de no tener ningún registro Access Role to Object (Rol de acceso a objeto) (ARO) propio. Esto pasa por lo siguiente:

• La falta de registros ARO en el rol de acceso MyApp:User significa que este rol de acceso no otorga ni niega acceso. No produce ningún resultado de autorización por sí solo.
• Dado que MyApp:User depende de PegaRULES:User4, cualquier verificación de autorización no resuelta se transfiere a PegaRULES:User4 para determinar si ese rol de acceso, a su vez, produce un resultado.
• Dado que PegaRULES:User4 no define un ARO para un tipo de caso específico de la aplicación MyApp , el algoritmo de control de acceso basado en roles (RBAC) avanza en la jerarquía de herencia de la clase de ese tipo de caso para encontrar un ARO relevante para esta verificación. PegaRULES:User4 define un ARO para Work- (Trabajo), (una superclase de cualquier Case Type [Tipo de caso] de MyApp), que es el ARO que coincide más específicamente con una instancia de un Tipo de caso en MyApp.
• Dado que la configuración 5 otorga explícitamente acceso de lectura y escritura al tipo de caso, este resultado de PegaRULES:User4 se propaga como el resultado de la misma verificación de autorización en el rol de acceso MyApp:User.

El usuario tiene la opción de introducir más de un rol dependiente. Si es así, los roles de acceso se unen a una operación OR para que solo uno de los ARO más específicos para cada caso de rol de acceso deba otorgar acceso para operar.

Si un rol de acceso necesita respetar en gran medida los resultados de autorización de un rol de acceso existente, pero anular los resultados en ciertos escenarios, también puede usar los roles dependientes para configurar solo esos ARO en el nuevo rol de acceso. De esta manera, anula los resultados que, de otro modo, se obtienen de sus roles dependientes. Cualquier resultado de autorización no especificado en el rol de nivel superior sigue siendo diferido a sus roles dependientes para un resultado.

Por ejemplo, considere un requerimiento que restrinja la actualización de todos los tipos de casos por parte de los usuarios de MyApp a solo aquellos que no tengan el estado Resolved (Resuelto), al mismo tiempo que preserva todos los demás accesos que normalmente se otorgan a los usuarios de Pega Platform. Con roles dependientes, eso se puede implementar usando un único ARO en MyApp:User, que especifica la restricción requerida (usando la regla de decisión específica de la aplicación Access When):

Al dejar todas las demás configuraciones en ARO sin especificar, otras verificaciones de autorización (por ejemplo, acceso de lectura) se difieren al rol dependiente (en este ejemplo, PegaRULES:User4). El rol dependiente continúa otorgando acceso de lectura, ya que ninguna configuración en el rol de nivel superior lo anula.

Los siguientes son los beneficios de usar jerarquías de rol dependiente:

1. Eliminar la duplicación de ARO para roles de acceso específicos de la aplicación: en el ejemplo anterior, donde MyApp necesitaba una configuración para variar una línea de base que, de otro modo, sería reutilizable —si no se usan roles dependientes—, todas las demás configuraciones en el ARO (y potencialmente en otros ARO) deben duplicarse en el rol de acceso MyApp:User.
2. Capas de roles de acceso: se pueden crear roles de acceso más genéricos para formar la base de autorización para roles de acceso específicos de la aplicación que usan roles de usuario similares. Los roles de acceso específicos de la aplicación pueden luego establecer una dependencia de roles de acceso más genéricos (que, a su vez, pueden depender de los roles de acceso de Pega Platform), agregando gradualmente la configuración de solo ese comportamiento, lo que difiere entre la capa Application (Aplicación) y las capas de las que depende.
3. Múltiples dependencias: los roles de acceso se pueden configurar para tener múltiples roles de acceso dependientes, lo que proporciona múltiples dependencias a las que ceder de modo que se pueda lograr un resultado de autorización basado en un conjunto de roles de acceso dispares. A menudo, algunos usuarios excepcionales realizan simultáneamente las responsabilidades de roles de múltiples usuarios. Crear un rol de acceso para estos usuarios y hacer que dependa de roles de acceso múltiples hermanos desde la misma aplicación puede lograr este resultado.
4. Reutilizar la autorización de Pega Platform o de la aplicación de Pega: a menudo, los roles de acceso que residen en Pega Platform (o en cualquier aplicación de Pega en la que esté trabajando) para los roles de usuario típicos, como usuarios finales, gerentes y administradores de sistemas, generan la mayoría de los resultados de autorización requeridos. La implementación de roles de acceso específicos de la aplicación que dependan de los roles de acceso de Pega Platform correspondientes proporciona una línea base de autorización operativa sin duplicación de ARO.
5. Mantenimiento: al configurar solo los requerimientos de autorización que son exclusivos para sus roles de acceso específicos de la aplicación y transferir el resto a sus roles dependientes es más claro para quienes mantienen su aplicación cómo la autorización específica de su aplicación se desvía de una base más comúnmente entendida. La configuración de RBAC sin roles dependientes genera una mayor cantidad de ARO a nivel de la aplicación, muchos de los cuales suelen ser clones ligeramente modificados de las funciones de acceso proporcionadas por Pega. Las modificaciones ligeras pueden ser difíciles de aislar.
6. Capacidad de actualización: al eliminar los ARO duplicados y, en cambio, someterse a los ARO especificados en roles dependientes, las actualizaciones de Pega Platform o de las aplicaciones de Pega permiten que la autorización de sus aplicaciones refleje los cambios de autorización que se entregan en la actualización de manera inmediata.

Cuando no se utilizan roles dependientes, su rol de acceso específico de la aplicación no tiene enlace con el rol de acceso de Pega nuevo o actualizado, lo que produce los siguientes impactos:

• Los roles de acceso específicos de la aplicación ocultan cualquier cambio en el modelo de autorización de Pega en los roles de acceso actualizados.
• Cualquier característica nueva entregada en cualquier actualización de Pega puede depender de los privilegios de los roles de acceso actualizados que enmascaran los roles de acceso específicos de la aplicación.