The UiPath Identity Server stores local accounts and the roles assigned to them, but also validates any directory accounts used in Orchestrator.
An account that was created and can be managed from Orchestrator, through the Management portal, is considered to be local to the UiPath ecosystem.
For local accounts, all account attributes like name and email address are stored in Identity Server.
User accounts that originate from a directory outside of the UiPath ecosystem (for example, from Azure Active Directory) are directory users. These accounts can access Orchestrator and can receive roles if you integrate with the directory.
For directory users, only role assignments and Orchestrator-specific settings are managed within the UiPath ecosystem, in Identity Server and Orchestrator. The external directory admin manages account-specific attributes (name, email, directory group membership).
There are two ways for a directory user to gain access to Orchestrator:
- An administrator assigns roles to their directory account in Orchestrator - we refer to this as an individually-added account.
- An administrator adds the directory account to a group and the user logs in with their directory account
- An Orchestrator administrator adds a directory group to a local group, and then a directory administrator adds the user account to the directory group - we refer to this as an auto-provisioned account.
Regardless of their type, directory account always inherit roles from the groups to which they belong, if they exist in Orchestrator.
Local groups are entities originating in Identity Server which represent a collection of user and robot accounts. You can assign roles and licenses to groups as opposed to assigning them to individual users. Anything assigned to the group is automatically assigned to all group members.
An entity created by referencing a group from a linked directory in your Orchestrator instance. All members of the group are potential users of Orchestrator. All roles assigned to a group are inherited by the users that belong to that group, auto-provisioned or individually-added.
- A user who belongs to multiple groups inherits roles from all of them.
- A user who belongs to multiple groups, and has also been granted roles explicitly, has the union of all the roles inherited and explicitly assigned.
Using directory groups enables automatic access with the group permissions, based on users being added or removed from the directory group (when switching departments, for example) with no need to manage user permissions individually.
|Directory Groups||Inherited Rights||Explicit Rights|
|Added group X with X set of access rights and group Y with Y set of access rights.||John Smith belongs to both Group X and Y. He logs in to Orchestrator. His user is auto-provisioned with the following rights: X, Y.||In addition to the X and Y sets, John is also granted the Z set explicitly. John now has the following rights: X, Y, Z.|
Deleting groups X and Y leaves John with Z.
- You don't need an explicit user entry to log in to Orchestrator, if you belong to a group that has been added to Orchestrator (step 1 - Behavior section).
- Inherited access rights are dependent on the associated Directory Group. If the directory is deleted, so are inherited access-rights.
- Explicitly-set access rights are independent of the Directory Group. They persist between sessions, regardless of the group's state.
Robot accounts are helpful for when you need to run back-office unattended processes that should not be the responsibility of any particular user. These are our RPA-specific equivalent of service accounts. Similar to the accounts that Windows services run as application identities in the OAuth model, they are a non-user identity to be used to run unattended processes.
Working with robot accounts
Robot accounts behave like user accounts in terms of permissions. In UiPath Orchestrator, you can add robot accounts and configure permissions for them in the same way as for any other account.
The only differences compared to user accounts are:
- robot accounts are not allowed any interactive-related process configuration
- no email address is required to create a robot account.
You can find and work with robot accounts in broadly the same way as you work with user accounts:
- Organization administrators can create and manage robot accounts from the Admin > Accounts & Groups page - except not from the Users tab, but from the dedicated Robot accounts tab.
Robot accounts can also be included in groups and managed as part of the group.
- When assigning roles in Orchestrator, searching for accounts shows users, groups, and also robot accounts for selection.
Robot entity (deprecated)
This only applies to classic folders.
For classic folders, when you manually deploy a robot to Orchestrator, a robot entity is automatically created, viewable on the Robots tab.
Robot users have the Robot role assigned to them by default.
A service account is a non-human account used to provide a security context for running workloads which don't involve the existence of a human account, such as server-to-server authentications. In these cases, Orchestrator assumes the identity of the service account.
Only one service account is created per Orchestrator instance — it is not visible in the user interface, and can only be identified in database tables.
There is no authentication information attached to this type of account, and, as such, it cannot log in interactively via browsers or cookies.
We recommend not to disable or delete the service account, as this will have a direct impact on running workloads.
Updated about a month ago