- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Setup Samples
- Storing Robot Credentials in CyberArk
- Setting up Attended Robots
- Setting up Unattended Robots
- Storing Unattended Robot Passwords in Azure Key Vault (read-only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read-only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- SmartCard Authentication
- Audit
- Resource Catalog Service
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Other Configurations
- Integrations
- Classic Robots
- Host administration
- Organization administration
- Troubleshooting
Configuring the SAML integration
You can connect Orchestrator to any identity provider (IdP) that uses the SAML 2.0 standard. This page describes the overall process by showing a few sample SAML integration configurations.
The SAML Integration is designed such that it can be implemented gradually, with no disruption to existing users.
The main phases of the process, described in more detail on this page, are:
- Clean up inactive user accounts
- Configure the SAML integration
- Transition existing users to sign in with SAML SSO
- Configure permissions and robots for new users
- Discontinue use of local accounts (optional)
With the SAML integration, you cannot search all users and groups from your identity provider. Only provisioned directory users are available for searching.
The SAML SSO Configuration page displays an incorrect Assertion Customer Service URL.
https://{your-domain}/91483651-d8d6-4673-bd3f-54b0f7dc513a/identity_/Saml2/Acs
would become https://{your-domain}/identity_/Saml2/Acs
This workaround has two caveats:
-
IDP initiated login flows will not work as expected.
-
This issue has been fixed in 2023.4. Upon upgrading to 2023.4+ you will need to change the Assertion Customer Service URL to include the partition ID.
To set up the SAML integration, you need:
- An Orchestrator organization with an Enterprise or Enterprise Trial license.
-
Administrator permissions in both Orchestrator 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.
Note:If you are currently using the Azure Active Directory integration for authentication, we recommend remaining on the AAD integration because it is more feature-rich.
If you do decide to switch from the AAD 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.
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 Orchestrator 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 any roles that the local account had so that the transition is seamless.
Because of this, with inactive local accounts present in Orchestrator, 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 Orchestrator and your identity provider (IdP) for the integration.
Orchestrator 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 the following providers:
-
Okta
-
PingOne.
You can use the configuration instructions below to set up integrations with these providers.
For other identity providers, we recommend that you follow their integration documentation.
A. Sample configuration for Okta
- In a different browser tab, log in to the Okta Admin Console.
- Go to Applications > Applications, click Create App Integration, and select SAML 2.0 as the sign-on method.
- In the General Settings page, specify a name for the app you are integrating with, namely Orchestrator.
-
On the Configure SAML page, fill in the General section as follows:
- Single sign-on URL: Enter the Assertion Consumer Service URL value you got from Orchestrator.
- Select the Use this for Recipient URL and Destination URL checkbox.
- Audience URI: Enter the Entity ID value you got from Orchestrator.
- Name ID Format: Select EmailAddress
- Application Username: Select Email
-
For Attribute Statements, add the following:
-
Name:
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
- Leave the Name Format as Unspecified.
-
Set Value to
user.email
, or the user attribute that contains the user's unique email address. - Optionally add other attribute mappings. Orchestrator also supports the First Name, Last Name, Job Title, and Department user attributes. This information is then propagated to Orchestrator, where it can be made available to other services, such as Automation Hub.
-
Name:
- On the Feedback page, select the option you prefer.
- Click Finish.
- On the Sign On tab, in the Settings section, under View Setup Instructions, copy the Identity Provider metadata URL value and save it for later.
- On the Application page for Orchestrator, select the newly created application.
- On the Assignments tab, select Assign > Assign to People, and then select the users that you want to allow to use SAML authentication for Orchestrator.
B. Sample configuration for PingOne
To enable Orchestrator as a service provider that recognizes your identity provider, complete the steps below:
To validate the SAML SSO integration is working properly:
- Open up an incognito browser window.
- Navigate to your Orchestrator 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?
After permissions have been configured, we recommend that you ask all your existing users to sign out of their UiPath account and sign in using SAML SSO.
To sign in to Studio and Assistant using SAML SSO, users must configure Assistant as follows:
This is only required for new users who have not used Orchestrator before and therefore did not have a local account set up for them in Orchestrator when the integration was enabled.
You can add new users to Orchestrator 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 Orchestrator 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.
User login failed. (#216)
, it may be due to missing email address mapping in the configuration of the SAML identity provider.
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
and the value must have a valid email address.
- Overview of the configuration process
- Known Limitations
- Cannot search accounts from your identity provider
- Incorrect ACS URL in the SAML configuration UI
- 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 Orchestrator
- Step 2.4. Check that the integration is running
- Step 3. Transition Your Users to SAML SSO
- Step 4. Configure permissions and robots
- Step 5. Discontinue use of local user accounts (optional)
- Considerations for discontinuing use of local accounts
- Troubleshooting