Ejemplo de roles

Para entender mejor el concepto de roles, usuarios y prioridades, a continuación se muestra un escenario de ejemplo.

A continuación se muestra una tabla de usuarios y sus asignaciones de grupo. Algunos usuarios no son miembros de ningún grupo, otros son miembros de un único grupo y otros son miembros de varios grupos. En este ejemplo, estos usuarios provienen de un dominio SAML. Cuando los miembros del dominio SAML se conectan a Redtrust, Redtrust hace que esos usuarios y cualquier posible pertenencia a un grupo incluida en la aserción SAML estén disponibles para su asignación a roles.

tip

Los usuarios solo necesitan un rol para acceder a la consola de administración. Los usuarios finales pueden acceder a los agentes y utilizar los certificados definidos en las políticas sin necesidad de tener un rol asignado.

Usuario	Pertenencia a un grupo
Usuario A	Ninguno
Usuario B	Grupo 1
Usuario C	Grupo 1
Usuario D	Grupo 1 y Grupo 2
Usuario E	Grupo 2

En este ejemplo, Redtrust ha sido configurado con los siguientes roles.

• Administrador

• Visor de eventos

• Administrador de certificados

• Administrador de desarrollo

Ahora que hay usuarios disponibles y los roles han sido creados, se puede ver la asignación de esos usuarios a los roles y con algunas prioridades de ejemplo. Este escenario se ha hecho complejo a propósito para ilustrar las interacciones entre la asignación de roles a usuarios/grupos y el nivel de prioridad. En el mundo real, la asignación de roles es sencilla en muchas aplicaciones. Considera el siguiente escenario:

Rol	Prioridad	Asignación de usuario/grupo
Administrador	1	Usuario A, Usuario B
Visor de eventos	0	Grupo 1
Administrador de certificados	1	Grupo 2
Gestor de desarrollo	1	Grupo 2

Explicación de qué funciones se asignaron a partir del escenario anterior y por qué.

Usuario	Función asignada	¿Por qué?
Usuario A	Administrador	El usuario A no tenía ninguna otra asignación. Se le asignó directamente el rol de administrador, por lo que esa es su asignación de rol válida.
Usuario B	Administrador	Si bien el usuario B era miembro del Grupo 1, como se le asignó directamente el rol de administrador, esa es su asignación de rol válida. Nótese, que esto es cierto incluso aunque el rol de visor de eventos tuviera una prioridad más alta (0 es la asignación de prioridad potencial más alta).
Usuario C	Visor de eventos	Como el usuario C era miembro del Grupo 1 y no tenía otras asignaciones potenciales, su rol es visor de eventos.
Usuario D	Visor de eventos	Puesto que el usuario D era miembro de los grupos 1 y 2, pero la función de visor de sucesos tiene mayor prioridad, se asignó al usuario D la función de visor de sucesos. Para asignar el usuario D a la función administrador de certificados, cambie la prioridad de la función visor de eventos a 2 o superior.
Usuario E	N/A	Puesto que las funciones administrador de certificados y administrador de desarrollo tienen las mismas prioridades, esta asignación de funciones no se aplicará de forma coherente. Para asignar al usuario E la función administrador de desarrollo, asigne la función directamente al usuario en lugar de al grupo.