- Getting started
- Data security and compliance
- Organizations
- Authentication and security
- Licensing
- Tenants and services
- Accounts and roles
- AI Trust Layer
- External applications
- Notifications
- Logging
- Troubleshooting
- Migrating to Automation Cloud™
Configuring the SAML integration
This feature is available with the Enterprise licensing plan.
By using SAML configuration in Automation Cloud we enhance both security and efficiency in authentication. Our system uses SAML to enable Single Sign-On (SSO) via secure access tokens, allowing the UiPath platform to connect with any Identity Provider (IdP) that uses the SAML 2.0 standard.
Additionally, our SAML configuration includes Single Logout (SLO) capabilities, which enable simultaneous logouts across all your applications unified under your IdP.
The SAML Integration is designed such that it can be implemented gradually, with no disruption to existing users.
Switching from the native Azure Active Directory integration to SAML integration
If you are using AAD for authentication, we recommend using our native AAD integration because it is more feature-rich.
If you do decide to switch to SAML integration, you must manually replace role assignation done through directory groups with direct role assignation to the directory accounts so that you do not have to completely recreate your access schema.
-
Encrypted SAML assertions from your identity provider are not supported.
-
You cannot search users and groups from your identity provider. Only provisioned directory users are available for searching.
-
You cannot see directory users at the organization level. Only local users appear at the organization level. Just-in-time provisioning adds directory users, so they do not show up on the Accounts & Groups page in Automation Cloud.
-
Viewing API access information, which allows you to authorize API requests using a user key, is not available for directory users that sign in through the SAML integration.
To set up the SAML integration, you need:
- An Automation Cloud organization with the Enterprise licensing plan.
-
Administrator permissions in both the Automation Cloud organization and your third-party identity provider. If you don't have administrator permissions in your identity provider, you can work with an administrator to complete the setup process.
-
UiPath® Studio and UiPath Assistant version 2020.10.3 or later, so that you can set them up to use the recommended deployment.
If your organization recycles email addresses, it is important to remove all inactive user accounts before you configure the SAML Integration.
When you enable the integration, local accounts present in Automation Cloud can be linked with the directory account in the external identity provider that uses the same email address. This account linking occurs when the directory account user with the email address signs in for the first time. The identity from your identity provider inherits all roles from the local account, so that the transition is seamless. Because of this, with inactive local accounts present in Automation Cloud, there is a risk that local accounts and directory accounts are mismatched, which can lead to unintended elevation of permissions.
To remove inactive user accounts:
Now, you must configure both Automation Cloud and your identity provider (IdP) for the integration.
You can connect to any third-party identity provider (IdP) that uses the SAML 2.0 standard. While configuration may vary depending on your chosen IdP, we have validated the configuration for using either Okta or PingOne, which you can use as reference to configure the integration.
For other identity providers, we recommend that you follow their integration documentation.
To enable Automation Cloud as a service provider that recognizes your identity provider, follow the below steps:
To validate the SAML SSO integration is working properly:
- Open up an incognito browser window.
- Navigate to your Automation Cloud organization URL.
- Check the following:
- Are you prompted to sign in with your SAML identity provider?
- Are you able to successfully sign in?
- If you are signing in with an email address that matches an existing user account, do you have the appropriate permissions?
If you use claims in your IdP, you can leverage them as conditions in a provisioning rule so that users are automatically provisioned with the right licenses and roles when they sign in to Automation Cloud. Provisioning rules are evaluated when a user signs in. If the user account meets the conditions for a rule, it is automatically added to the local UiPath group associated with the rule. For example, an administrator can configure a rule to provision users directly into the Automation Users group using these settings: Claim=group, Relationship=is, Value=Automation User.
2.5.1 Set up provisioning groups
In Automation Cloud, adding an account to a group means the account inherits the licenses, roles, and robot configuration defined for the group, if any.
By grouping similar account types (e.g., developers or testers), you can streamline user onboarding process to Automation Cloud. Just make sure that in the IdP you set up similar accounts in the same way.
This way, you set up the group once, and then replicate the setup by adding accounts to the group when needed. If the setup for a particular group of accounts needs to change, you only need to update the group once and the changes apply for all accounts in the group.
To set up a group for a provisioning rule:
-
Create a new local group in Automation Cloud.
If you want, you can use one of your existing groups instead of creating a new one.
-
(Optional and requires user license management enabled) If accounts in this group need user licenses, set up license allocation rules for the group.
If you are using an existing group, check license allocation for the group to make sure the right licenses are being allocated. If not, either change allocations, or consider creating a new group.
-
Assign tenant roles and optionally complete robot setup for the group. For instructions, see Assigning roles to a group .
If you are using an existing group, check the roles currently assigned to the group to make sure they are adequate for the type of account you will add to the group. If not, either edit the roles assigned to this group, or consider creating a new group.
-
Add the group to folders and assign folder roles, as needed. For instructions, see Managing folder access.
Now you can use this group in a provisioning rule.
2.5.2. Create a provisioning rule for a group
Ensure the claim associated with the SAML provisioning rule is sent to the SAML payload by configuring it in the SAML application.
After the SAML integration is configured and after you have set up a group:
-
Go to Admin, select your organization, and then select Security.
The Security Settings page for the organization opens on the Authentication Settings tab.
-
Under the SAML SSO option, click View Provisioning Rules. The SAML SSO Provisioning Rules page opens, where your existing rules are listed.
-
In the top right corner of the page, click Add rule.
The Add new rule page opens.
- Under Basic details, fill in the Rule Name field and optionally fill in the Description field.
-
Under Conditions, click Add rule.
A row of fields for a new condition is added. Together, they define the criteria that an account must meet at sign in to be added to a group (chosen later).
- In the Claim field, type the name of the claim, as it appears in the IdP. The field is case-sensitive.
-
From the Relationship list, select how the claim relates to the value. The following options are available:
Relationship
Condition requirement
Example
is
exact match, case sensitive
Department is RPA
requires that the value for theDepartment
claim beRPA
.The condition is not met if the value isRPADev
, for example.This relationship works for multi-valued claims.
For example, ifadministrator
anddeveloper
values are sent under theGroup
claim, thenGroup is administrator
would be a valid relationship.is not
anything except specified value, case sensitive
ForDepartment is not ctr
, any account is added to the group unlessDepartment
has the valuectr
.The condition is met if the department isCtr
orelectr
.contains
includes, does not require an exact match, case sensitive
Department contains RPA
requires that the value for theDepartment
claim includeRPA
.The condition is met if the value isRPADev
,xRPAx
, orNewRPA
, for example.not contains
excludes, does not require an exact match, case sensitive
ForDepartment not contains ctr
, any account is added to the group unless theDepartment
value includesctr
.Accounts for which the department isctr
orelectr
, for example, are not added to the group.is case insensitive
exact match, not case sensitive
Department is case insensitive RPA
requires that the value for theDepartment
claim berpa
, in any capitalization.The condition is met if the value isrpa
, for example. The condition is not met if the value iscrpa
.contains case insensitive
includes, does not require an exact match, not case sensitive
Department contains case insensitive RPA
requires that the value for theDepartment
claim includeRPA
, in any capitalization.The condition is met if the value isrpa
,cRPA
, orrpA
, for example. - In the Value field, type the value that is needed to meet the condition.
-
If you want to add another condition, click Add rule to add a new condition row.
When you add multiple conditions, all conditions must be met for the provisioning rule to apply. For example, if you define the rulesDepartment is RPA
andTitle is Engineer
, only users that are both in the RPA department and have the title Engineer are added to the specified groups. An account for which the department is RPA, but the title is QA is not added to the groups. -
Under Assign to groups, in the Add Groups box, start typing the name of a group and then select a group from the list of results. Repeat to add more groups, if needed.
When the conditions are met, accounts are automatically added to these groups when they login.
- Click Save in the bottom right corner to add the rule.
With a rule in place, whenever a user logs in and their account meets the conditions specified for a rule, their account is added to the provisioning groups attached to the rule, and their account is set up to work in Automation Cloud.
Sample SAML payload fragment
<Attribute
Name="groups">
<AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">ProcessAutomation-Developer</AttributeValue>
<Attribute
Name="groups">
<AttributeValue
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="xs:string">ProcessAutomation-Developer</AttributeValue>
-
Your IdP must be configured to pass in these claims in the ACS payload.
-
Ensure the attribute names configured in the IdP match the attribute mapping settings in the organization administrator portal.
{
"displayname": "John Doe",
"fname": "John",
"lname": "Doe",
"jobtitle": "Hardware Engineer",
"dpt": "Engineering",
"city": "Phoenix"
}
{
"displayname": "John Doe",
"fname": "John",
"lname": "Doe",
"jobtitle": "Hardware Engineer",
"dpt": "Engineering",
"city": "Phoenix"
}
When a user in this organization logs in via the SAML directory integration, their user object is updated to reflect this setting.
{
"Display Name": "John Doe",
"First Name": "John",
"Last Name": "Doe",
"Job Title": "Hardware Engineer",
"Department": "Engineering",
"City": "Phoenix"
}
{
"Display Name": "John Doe",
"First Name": "John",
"Last Name": "Doe",
"Job Title": "Hardware Engineer",
"Department": "Engineering",
"City": "Phoenix"
}
Make sure you provide your organization-specific URL for the Automation Cloud organization to all your users.
After switching to SAML integration, the Azure AD integration is disabled. Azure AD group assignments no longer apply, so Automation Cloud group membership and the permissions inherited from Azure AD are no longer respected.
To sign in to Automation Cloud with SAML SSO, users can:
- navigate to your organization-specific URL. The URL must include the organization ID and end in a forward slash, such as
https://cloud.uipath.com/orgID
. - navigate to https://cloud.uipath.com, select Continue with SSO on the Login page, then provide their organization-specific URL.
To sign in to UiPath Studio and UiPath Assistant using SAML SSO, users must configure Assistant as follows:
This is only required for new users who have not used Automation Cloud before and therefore did not have a local account set up for them in Automation Cloud when the integration was enabled.
You can add new users to Automation Cloud groups by their email address (as used in the external IdP). Once a user has been assigned to a group or they have signed in, they will be available through search for role assignment across all UiPath services.
After all users have transitioned to SAML SSO and new users are set up, we recommend that you remove all local user accounts that are not administrator accounts. This ensures that users can no longer sign in with their local account credentials and they have to sign in with SAML SSO.
You can identify local user accounts based on their icons.
A local account can be useful:
-
To manage SAML integration issues (e.g., updating an expired certificate) or if changing authentication settings - an account with the organization administrator role is recommended.
-
For processes depending on API access tokens for request authorizations since the API Access functionality (on Admin > Tenants page) is inaccessible with a SAML SSO account. Alternatively, switch to using OAuth for authorization, which eliminates the need for the API access information.
- Known limitations
- Prerequisites
- Step 1. Clean up inactive user accounts
- Step 2. Configure the SAML integration
- Step 2.1. Obtain SAML service provider details
- Step 2.2. Configure your identity provider
- Step 2.3. Configure Automation Cloud
- Step 2.4. Check that the integration is running
- Step 2.5. Configure provisioning rules (optional)
- SAML attribute mapping
- Step 3. Transition your users to SAML SSO
- Step 4. Configure permissions and robots
- Step 5. Discontinue use of local accounts (optional)