Crear roles y grupos de acceso para una aplicación

Un rol de acceso identifica un puesto laboral o una responsabilidad definidos para una aplicación. Por ejemplo, un rol de acceso puede definir las características de LoanOfficer o CallCenterSupervisor. El sistema concede capacidades específicas a los usuarios, como la modificación de instancias de ciertas clases, en función de los roles de acceso adquiridos del grupo de acceso en uso.

Antes de crear roles de acceso para su aplicación, evalúe las necesidades de control de acceso basado en roles para la aplicación a fin de determinar cuántos roles de acceso individuales se necesitan. También determine cuál debería ser el nombre de cada rol de acceso a fin de describir la autorización para cada concesión. Un rol de acceso define qué acciones tiene permitido hacer en la aplicación quien posee el rol.

Por ejemplo, un rol de acceso puede representar las acciones que tiene permitido hacer un gerente, un operador de conformidad, un empleado administrativo o un auditor. Un usuario dado puede tener varios roles de acceso a la vez. El conjunto de roles de acceso que tiene un usuario a la vez funciona como un grupo de capacidades y representa el conjunto de acciones que el usuario tiene permitido realizar. Por ejemplo, los operadores de conformidad pueden tener acceso a abrir registros de pedidos de cliente, mientras que los gerentes pueden tener acceso a abrir y modificar dichos registros.

Considere que un Lead System Architect (LSA) tiene las siguientes tres opciones de diseño de rol de acceso para cumplir con las necesidades de control de acceso de los operadores y gestores de conformidad en el ejemplo de aplicación de Pedidos:

Opción 1:

Opción 2:

Opción 3:

La decisión de qué opción debe tomar un LSA respecto al diseño debe considerar si las necesidades de control de acceso del gerente coinciden casi siempre con las del operador de conformidad (o son un subconjunto de ellas).

Opción 1 permite que las necesidades de control de acceso de cada Persona (rol de usuario) evolucionen independientemente de la otra, con la sobrecarga de mantenimiento de que algunos ajustes de control de acceso se duplican en cada rol de acceso.

Opción 2 requiere que las necesidades de control de acceso del gerente siempre sean un conjunto superior del operador de conformidad, ya que una concesión del rol de acceso FulfillmentOperator (sin una configuración avanzada de RBAC) es suficiente para conceder acceso al grupo de acceso de gerentes, incluso si el rol de acceso del gerente deniega el acceso.

Opción 3 permite que las necesidades de control de acceso del gerente se basen principalmente en el rol de acceso FulfillmentOperator, al mismo tiempo que permite rol de acceso al gerente a los ajustes específicos de gerente y a los ajustes de sobreescritura especificados en el rol de acceso dependiente FulfillmentOperator.

Solución: la opción 3 en general presenta un diseño de autorización deseado con menos acceso de rol a objeto (ARO) y la menor posibilidad de duplicación. Esta opción promueve una solución que se puede comprender y mantener y tener la flexibilidad de adaptarse si se agregan Journeys adicionales que invalidan algunas de las decisiones de autorización que se permitieron en lanzamientos anteriores.

Las aplicaciones creadas desde el asistente New Application (Aplicación nueva) tienen tres roles de acceso de base:

• :User
• :Manager
• :Administrator

Con la introducción de roles dependientes, la práctica recomendada es crear roles de acceso específicos de la aplicación que especifiquen los roles de acceso de base como dependientes.

La convención de nomenclatura que se usa para los roles de acceso es :, donde RoleName es singular.

Use la landing page de Roles for Access (Dev Studio > Configure > Org & Security > Tools > Security > Role Names) para crear roles específicos de la aplicación nuevos.

Use un Acceso de rol a objeto para conceder permisos a objetos (instancias) de una clase dada y privilegios de nombre a un rol. Los permisos de acceso y los privilegios de nombre se pueden conceder hasta un nivel de producción especificado entre 1 y 5 (1 es experimento, 2 es desarrollo, 3 es control de calidad, 4 es almacenamiento y 5 es producción) o según las reglas de decisión de acceso.

Al planificar el conjunto de ARO para especificar un nombre de rol de acceso, considere lo siguiente:

• ¿El rol de acceso al que aplican hereda la autorización del rol dependiente? Si es el caso, los ARO necesarios para los roles de acceso pueden limitarse a los que modifican los resultados de autorización que de otra manera se obtendrían de sus roles dependientes.
• ¿El rol de acceso utiliza la herencia de privilegio? Si no es el caso, es posible que se deba volver a especificar algunos privilegios de los ARO de superclase en ARO de superclase en el mismo rol de acceso.
• Si se deja en blanco la configuración en un ARO, Pega se remite a los ARO de superclase y roles dependientes para determinar la autorización para esa configuración. Este es un enfoque legítimo orientado al objeto para configurar la autorización, pero necesita diseño.
• ¿El rol de acceso se usa en grupos de acceso que realizan pruebas de cortocircuito en dichos roles una vez que el acceso se concedió o denegó explícitamente? Si es el caso, considere la diferencia entre configurar un valor de ajuste (ya sea una regla de decisión de acceso o un número de nivel de producción, los cuales pueden denegar acceso explícitamente) y dejar el valor de la configuración en blanco (lo que implica delegar el resultado de autorización a un ARO de superclase o a roles posteriores en el grupo de acceso).

Use una regla de Access Deny (Denegación de acceso) para denegar autorización de forma explícita antes de evaluar si los ARO correspondientes para la misma clase y rol de acceso pueden conceder acceso a la misma acción.

Definir roles de acceso que solo contienen reglas de denegación de acceso, secuenciar esos roles de acceso antes en la lista de un grupo de acceso y activar la opción Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access simplifica la restricción de la autorización que, de otra manera, se concedería al grupo de acceso mediante los roles de acceso enumerados en el grupo de acceso. Los roles que solo contienen reglas de denegación de acceso se pueden describir como Roles de acceso Access-Deny-Only (solo de denegación de acceso).

La resolución de reglas no se aplica a las reglas de denegación de acceso. Su sistema puede tener como máximo una regla de denegación de acceso para cada clase de aplicación y combinación de nombre del rol. No se aplica la herencia de clase. Cree una regla de denegación de acceso para cada clase involucrada.

El caso de uso típico es en el que el requerimiento de una Persona (rol de usuario) indica qué autorización está muy cerca de una Persona existente (rol de usuario), pero es un subconjunto de ella. Por ejemplo, dada una aplicación de pedidos con una Persona de gerente existente (con un rol de acceso Ordering:Manager), surge la necesidad de tener una Persona de gerente asociado (rol de usuario), entre las cuales la única diferencia de autorización es el valor de los pedidos que están autorizadas a abrir. Un enfoque de implementación para esto usando reglas de denegación de acceso puede ser el siguiente:

1. Crear un rol de acceso de solo denegación de acceso denominado Ordering:AssociateManagerDeny
2. Crear una regla de decisión de acceso en la clase de pedido que compara el valor de pedido con el umbral que requiere la regla de negocio
3. Crear una regla de denegación de acceso para el nuevo rol de acceso en la clase de pedido, aplicando la nueva regla de decisión de acceso como la configuración de instancia de lectura

4. Crear el grupo de acceso Ordering:AssociateManagers, agregando los siguientes roles de acceso:

   1. Ordering:AssociateManagerDeny: denegación del acceso de pedido abierto según la regla de negocio
   2. Ordering:Manager: otorga la misma autorización que tienen los gerentes existentes

5. Seleccione la configuración Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access en el grupo de acceso Ordering:AssociateManagers.

Un grupo de acceso está asociado con un usuario mediante el registro del Id. de operador. El grupo de acceso determina los roles de acceso que tienen los usuarios en el grupo de acceso, la suma de los cuales son las acciones que tienen autorización para hacer esos usuarios. La convención de nomenclatura que se usa para los grupos de acceso es nombre de la aplicación, dos puntos, grupo de usuarios.

La convención de nomenclatura que se usa para los grupos de acceso es :, donde GroupsName está en plural, por ejemplo, Clientes.

Tener un rol de acceso dedicado a una capacidad particular puede ser útil cuando varias personas (roles de usuario) cumplen una responsabilidad similar aparte de sus responsabilidades principales. Por ejemplo, los roles de usuario en una aplicación de Recursos Humanos son empleado, responsable de Recursos Humanos, gerente de Recurso Humanos y ejecutivo. Ambos gerentes y ejecutivos de Recursos Humanos pueden actualizar reglas delegadas. En este caso, cree un rol de acceso adicional llamado :DelegatedRulesAdmin. Este rol de acceso puede sumarse a los grupos de acceso para que los gerentes y ejecutivos de Recursos Humanos puedan actualizar reglas delegadas aparte de sus responsabilidades primarias.