- Primeros pasos
- Mejores prácticas
- Tenant
- Contexto de carpetas
- Automatizaciones
- Procesos
- Trabajos
- Desencadenadores
- Registros
- Supervisión
- Colas
- Activos
- Depósitos de almacenamiento
- Test Suite - Orchestrator
- Administración de host
- Servidor de identidad
- Autenticación
- Administración de la organización
- Otras configuraciones
- Integraciones
- Robots clásicos
- Solución de problemas
Tipos de cuenta
UiPath Identity Server almacena las cuentas locales y sus roles asignados, pero también valida cualquier cuenta de directorio utilizada en Orchestrator.
Una cuenta que fue creada y que se puede gestionar desde el Identity Server a través del Portal de gestión, se considera local en el ecosistema UiPath. Para las cuentas locales, todos los atributos de la cuenta, como el nombre y la dirección de correo electrónico, se almacenan en Identity Server.
Las cuentas de usuario que se originan en un directorio fuera del ecosistema UiPath (por ejemplo, desde Azure Active Directory) son usuarios de directorio. Estas cuentas pueden acceder a Orchestrator y pueden recibir roles si se integra con el directorio.
En el caso de los usuarios del directorio, solo se gestionan las asignaciones de funciones y los ajustes específicos de Orchestrator dentro del ecosistema UiPath, en Identity Server y Orchestrator, mientras que el administrador del directorio externo gestiona los atributos específicos de la cuenta (nombre, correo electrónico o pertenencia a un grupo del directorio).
Hay dos maneras de conceder a un usuario del directorio acceso a Orchestrator:
- Al asignar roles en Orchestrator al usuario del directorio - nos referimos a él como un usuario añadido individualmente.
- Al iniciar sesión con una cuenta que pertenece a un grupo de directorio que se añadió previamente a Orchestrator - nos referimos a esto como un usuario autoaprovisionado. Consulta Sobre usuarios para obtener más información.
Independientemente de su tipo, los usuarios del directorio siempre heredan los roles de los grupos a los que pertenecen, si existen en Orchestrator.
Los grupos locales son entidades que se originan en Identity Server y que representan una colección de cuentas de usuarios y robots. Se pueden asignar roles y licencias a grupos en lugar de asignarlos a usuarios individuales. Todo lo que se asigna al grupo se asigna automáticamente a todos los miembros del grupo.
Una entidad creada mediante la referencia a un grupo de un directorio vinculado en tu instancia de Orchestrator. Todos los miembros del grupo son usuarios potenciales de Orchestrator. Todos los roles asignados a un grupo son heredados por los usuarios que pertenecen a ese grupo, autoaprovisionados o agregados individualmente.
- Un usuario que pertenece a varios grupos hereda los roles de todos ellos.
- Un usuario que pertenece a varios grupos, y al que también se le han concedido roles explícitamente, tiene la unión de todos los roles heredados y asignados explícitamente.
El uso de grupos de directorio permite el acceso automático con los permisos del grupo, en función de los usuarios que se añadan o eliminen del grupo de directorio (por ejemplo, al cambiar departamento) y sin necesidad de gestionar los permisos de usuario de forma individual.
Ejemplo
|
Grupos del directorio |
Derechos heredados |
Derechos explícitos |
|---|---|---|
|
Se ha añadido el grupo X con un conjunto de derechos de acceso X y el grupo Y con un conjunto de derechos de acceso Y. |
John Smith pertenece tanto al grupo X como al Y. Se conecta a Orchestrator. Su usuario está autoaprovisionado con los siguientes derechos: X, Y. |
Además de los conjuntos X e Y, a Juan también se le concede explícitamente el conjunto Z. Juan tiene ahora los siguientes derechos: X, Y, Z. La eliminación de los grupos X e Y deja a Juan con Z. |
- No necesitas una entrada de usuario concreto para iniciar sesión en Orchestrator si perteneces a un grupo añadido a Orchestrator.
- Los derechos de acceso heredados dependen del Grupo de directorio asociado. Si se borra el directorio, también se eliminan los derechos de acceso heredados.
- Los derechos de acceso establecidos explícitamente son independientes del Grupo de Directorio. Persisten entre sesiones, independientemente del estado del grupo.
Las cuentas de los robots son útiles para cuando se necesita ejecutar procesos desatendidos de administración que no deben ser responsabilidad de ningún usuario en particular. Se trata de nuestro equivalente de cuentas de servicio específicas de RPA. Al igual que las cuentas que los servicios de Windows ejecutan como identidades de aplicación en el modelo OAuth, son una identidad de no usuario que se utiliza para ejecutar procesos desatendidos.
Trabajar con cuentas de los robots
Las cuentas de los robots se comportan como las cuentas de los usuarios en cuanto a permisos. En UiPath Orchestrator, se pueden añadir cuentas de robot y configurar los permisos para ellas del mismo modo que para cualquier otra cuenta.
Las únicas diferencias con respecto a las cuentas de usuario son:
- las cuentas de los robots no pueden configurar ningún proceso relacionado con la interactividad
- no se requiere una dirección de correo electrónico para crear una cuenta de robot.
Puedes encontrar y trabajar con las cuentas de los robots prácticamente de la misma manera que trabajas con las cuentas de los usuarios:
-
Los Administradores pueden crear y gestionar cuentas de robot desde la página Administrador > Cuentas y grupos, salvo desde la pestaña Usuarios, pero sí desde la pestaña Cuentas de Robot.
Las cuentas de los robots también pueden incluirse en grupos y administrarse como parte del grupo.
- Al asignar roles en Orchestrator, la búsqueda de cuentas muestra usuarios, grupos y también cuentas de robots para su selección.
En el caso de las carpetas clásicas, cuando implementes manualmente un robot en Orchestrator, se creará automáticamente una entidad de robot que se podrá ver en la pestaña Robots.
Los usuarios de UiPath Robot tienen asignado el rol de Robot de forma predeterminada.
Una cuenta de servicio es una cuenta no humana que se utiliza para proporcionar un contexto de seguridad para ejecutar cargas de trabajo que no implican la existencia de una cuenta humana, como las autenticaciones de servidor a servidor. En estos casos, Orchestrator asume la identidad de la cuenta de servicio.
Solo se crea una cuenta de servicio por instancia de Orchestrator; no es visible en la interfaz de usuario y solo se puede identificar en las tablas de la base de datos.
No hay información de autenticación adjunta a este tipo de cuenta y, como tal, no puede iniciar sesión de forma interactiva a través de navegadores o cookies.
Recomendamos no deshabilitar o eliminar la cuenta de servicio, ya que esto tendrá un impacto directo en las cargas de trabajo en ejecución.
