Automation Cloud
latest
false
Banner background image
Automation Cloud Admin Guide
Last updated 2024年3月15日

Configuring the SAML integration

This feature is only available if you are on the Enterprise licensing plan.

You can connect Automation Cloud 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.

Overview of the configuration process

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:

  1. Clean up inactive user accounts
  2. Configure the SAML integration
  3. Transition existing users to sign in with SAML SSO
  4. Configure permissions and robots for new users
  5. Discontinue use of directory accounts (optional)

Known limitations

Cannot search accounts from your identity provider

With the SAML integration, you cannot search all users and groups from your identity provider. Only provisioned directory users are available for searching.

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 management page.

Cannot view API access information

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.

Prerequisites

To set up the SAML integration, you need:

  • An Automation Cloud organization with the Enterprise licensing plan.
  • Administrator permissions in both Automation Cloud 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:

Switching from the Azure Active Directory integration

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.

Step 1. Clean up inactive user accounts

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 any roles that the local account had 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:

  1. Log in to Automation Cloud as an organization administrator.
  2. Go to Admin, select your organization, and then select Accounts & Groups.

    The Accounts & Groups page for the organization opens on the Users tab.

  3. Click the column header for the Last active column to reorder users so that the ones with the oldest date for last login are shown at the top:


    The Last active column show the date when the user last logged in to Automation Cloud. If you see Pending in this column, as in the above example, that means the user never logged in. You can use this information to help you identify your inactive users.

  4. Click the Delete icon at the end of the row to remove the local account for that user.


  5. In the confirmation dialog, click Delete to confirm deleting the account from Automation Cloud.

    The user account is removed from the page.

  6. Continue to delete all inactive user accounts in your organization.

Step 2. Configure the SAML integration

Now you must configure both Automation Cloud and your identity provider (IdP) for the integration.

Step 2.1. Obtain SAML service provider details

  1. Log in to Automation Cloud as an organization administrator.
  2. Go to Admin, select your organization, and then select Security.

    The Security Settings page for the organization opens on the Authentication Settings tab.

  3. Select Users can sign in with SAML SSO and then click Configure.

    An information dialog opens.

  4. In the dialog, click Continue.

    The next page provides an overview of the integration.

  5. In the bottom right corner, click Next to proceed to configuration.

    In the General details step, under Data to be configured in IdP, we provide the information you need to to configure your identity provider to connect to Automation Cloud.



  6. Copy and save the values for Metadata URL,Entity ID, and Assertion Consumer Service URL values. You will need these in the next step.

Keep this browser tab open for later.

Step 2.2. Configure your identity provider

Automation Cloud 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 PingOnes, which you can use as reference to configure the integration.

For other identity providers, we recommend that you follow their integration documentation.

A. Sample configuration for Okta

Note: The instructions in this section are for a sample configuration. For more information about any IdP settings not covered here, please use the Okta documentation.
  1. In a different browser tab, log in to the Okta Admin Console.
  2. Go to Applications > Applications, click Create App Integration, and select SAML 2.0 as the sign-on method.
  3. In the General Settings page, specify a name for the app you are integrating with, namely Automation Cloud.
  4. On the Configure SAML page, fill in the General section as follows:
    1. Single sign-on URL: Enter the Assertion Consumer Service URL value you got from Automation Cloud.
    2. Select the Use this for Recipient URL and Destination URL checkbox.
    3. Audience URI: Enter the Entity ID value you got from Automation Cloud.
    4. Name ID Format: Select EmailAddress
    5. Application Username: Select Email
  5. For Attribute Statements, add the following:
    1. Name: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
    2. Leave the Name Format as Unspecified.
    3. Set Value to user.email, or the user attribute that contains the user's unique email address
    4. Optionally add other attribute mappings. Automation Cloud also supports the First Name, Last Name, Job Title, and Department user attributes. This information is then propagated to Automation Cloud, where it can be made available to other services, such as Automation Hub.
  6. On the Feedback page, select the option you prefer.
  7. Click Finish.
  8. 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.
  9. On the Application page for Automation Cloud, select the newly created application.
  10. On the Assignments tab, select Assign > Assign to People, and then select the users that you want to allow to use SAML authentication for Automation Cloud.

    The newly added users are displayed on the People tab.

B. Sample configuration for PingOne

Note: The instructions in this section are for a sample configuration. For more information about any IdP settings not covered here, please use the PingOne documentation.
  1. In a different browser tab, log in to the Ping One Admin Console.
  2. Go to Connections > Applications, and click the plus icon +.
  3. Click Web App, and for SAML click Configure.
  4. On the Create App Profile page, specify a name for your Automation Cloud app.
  5. On the Configure SAML Connection page, select Manually Enter and provide the following details:

    • ACS URLs: Enter the Assertion Consumer Service URL value you got from Automation Cloud.
    • Entity ID: Enter the Entity ID value you got from Automation Cloud.
    • SLO binding:HTTP Redirect
    • Assertion Validity Duration: Enter the number of seconds for the validity period.
  6. Click Save and Continue.
  7. On the Map Attributes page, add the email address:
    1. Select + Add Attribute.
    2. For Application Attribute, enter http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.
    3. Set Outgoing Value to Email Address, or the user attribute that contains the user's unique email address.
    4. Select the Required checkbox.
    5. Optionally add other attribute mappings. Automation Cloud also supports the First Name, Last Name, Job Title, and Department user attributes. The attributes are case sensitive. This information is then propagated to Automation Cloud, where it can be made available to other services, such as Automation Hub.
  8. Click Save and Close.
  9. Click the toggle for the Automation Cloud app to enable the application for user access.
  10. On the Configuration tab, copy and save the IdP Metadata URL value for later use.

Step 2.3. Configure Automation Cloud

To enable Automation Cloud as a service provider that recognizes your identity provider, follow the below steps:

  1. Return to the SAML configuration tab in Automation Cloud.
  2. In the General details step:
    1. Under Data from IdP, fill in the Metadata URL field with the metadata URL obtained during configuration.
    2. Click Fetch data. When complete, the Sign-on URL,Identity Provider Entity ID, and Signing certificate fields are populated with the IdP information.
    3. Click Next in the bottom right corner to move to the next step.
  3. In the Provisioning settings step:
    1. Fill in the Allowed Domains section with the domains from which you want to allow users to sign in. Enter all of the domains that are supported by the configured identity provider. Separate multiple domains using commas.
    2. Select the checkbox to indicate that you understand that accounts with matching email addresses will be linked.
    3. Under Attribute Mapping, fill in the Display Name field with the attribute from your IdP that you want to show in Automation Cloud as the name for users. You can use the First Name and Last Name attributes here.
    4. Optionally fill in the remaining fields with attributes from your IdP.
    5. If you want to also configure advanced details, click Next in the bottom right corner to advance to the final step.

      Otherwise, click Test and Save to finish configuring the integration and skip the remaining steps in this section.

  4. On the Advanced settings page, configure the options as needed:
    • Allow unsolicited authentication response: Enable if you want to be able to navigate to Automation Cloud from the IdP dashboard.
    • SAML binding type: Select how the SAML configuration should communicate, via the HTTP user agent. Select HTTP redirect to use URL parameters, or HTTP post to use an HTML form with base64-encoded content.
  5. Click Test and Save to finish configuring the integration.

Step 2.4. Check that the integration is running

To validate the SAML SSO integration is working properly:

  1. Open up an incognito browser window.
  2. Navigate to your Automation Cloud URL.
  3. Check the following:
    1. Are you prompted to sign in with your SAML identity provider?
    2. Are you able to successfully sign in?
    3. If you are signing in with an email address that matches an existing user account, do you have the appropriate permissions?

Step 2.5. Configure provisioning rules (optional)

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 group associated with the rule.

Phase 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.

So if you set up a group with a particular type of user in mind (for example, your employees who create the automations, or your employees who test the automations), you can onboard a new employee of that type to Automation Cloud by simply setting up their account in the IdP in the same way as other similar accounts.

This way, you set up the group once, and then replicate the setup by adding accounts to the group when needed. Also, if the setup for a particular group of users 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:

  1. 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.

  2. (Optional and requires user license management ) If users 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.

  3. 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 users you will add to the group. If not, either edit the roles assigned to this group, or consider creating a new group.

  4. 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.

Phase 2. Create a provisioning rule for a group

Note:

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:

  1. Go to Admin, select your organization, and then select Security.

    The Security Settings page for the organization opens on the Authentication Settings tab.

  2. Under the SAML SSO option, click View Provisioning Rules:

    The SAML SSO Provisioning Rules page opens, where your existing rules are listed.

  3. In the top right corner of the page, click Add rule.

    The Add new rule page opens.

  4. Under Basic details, fill in the Rule Name field and optionally fill in the Description field.
  5. 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).



  6. In the Claim field, type the name of the claim, as it appears in the IdP. The

    field is case-sensitive.

  7. 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 the Department claim be RPA.
    The condition is not met if the value is RPADev, for example.

    This relationship works for multi-valued claims.

    For example, if administrator and developer values are sent under the Group claim, then Group is administrator would be a valid relationship.

    is not

    anything except specified value, case sensitive

    For Department is not ctr, any account is added to the group unless Department has the value ctr.
    The condition is met if the department is Ctr or electr.

    contains

    includes, does not require an exact match, case sensitive

    Department contains RPA requires that the value for the Department claim include RPA.
    The condition is met if the value is RPADev, xRPAx, or NewRPA, for example.

    not contains

    excludes, does not require an exact match, case sensitive

    For Department not contains ctr, any account is added to the group unless the Department value includes ctr.
    Accounts for which the department is ctr or electr, 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 the Department claim be rpa, in any capitalization.
    The condition is met if the value is rpa, for example. The condition is not met if the value is crpa.

    contains case insensitive

    includes, does not require an exact match, not case sensitive

    Department contains case insensitive RPA requires that the value for the Department claim include RPA, in any capitalization.
    The condition is met if the value is rpa, cRPA, or rpA, for example.
  8. In the Value field, type the value that is needed to meet the condition.
  9. 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 rules Department is RPA and Title 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.
  10. 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.

  11. Click Save in the bottom right corner to add the rule.

With a rule in place, whenever a user logs in to Automation Cloud 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>

SAML Attribute mapping

When configuring the SAML directory integration, org admins have the ability to define which attributes from their IdP should be mapped to the system user attributes. Afterwards, when a user logs in via the SAML directory integration, the system will read the claims that are passed into the ACS payload and map the value to their correspondent system attributes.

For example, if this is the user structure in your IdP, an org administrator can set up the following attribute mapping settings to have this information populated in the system user object.

{  
    "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" 
}
docs image

When a user in this organization logs in via the SAML directory integration, their user object will be 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" 
}
Note:
  • 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 org administrator portal.

Step 3. Transition your users to SAML SSO

Make sure you provide your organization-specific URL for Automation Cloud to all your users and follow the instructions below. Only organization administrators can see the organization URL in Organization Settings.

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.
Note:
After switching to the 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 UiPath Studio and UiPath Assistant using SAML SSO, users must configure Assistant as follows:

  1. In Assistant, open Preferences and select the Orchestrator Connection tab.
  2. Click Sign Out.
  3. For the connection type, select Service URL.
  4. In the Service URL field, add the organization-specific URL.
    The URL must include the organization ID and end in a forward slash, such as https://cloud.uipath.com/orgID/. Otherwise, the connection fails saying that the user does not belong to any organization.
  5. Sign back in with SAML SSO.

Step 4. Configure permissions and robots

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 Automation Cloud services.

Step 5. Discontinue use of local accounts (optional)

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 the user icons.

Considerations for discontinuing use of local accounts

Managing Authentication Settings in Automation Cloud

In case of problems with the SAML integration (such as updating an expired certificate), or if you want to switch to a different authentication setting, a local user account with the organization administrator role is recommended.

API Access

If you have processes in place that rely on the information obtained by clicking API Access (Admin > Tenants page) to make API calls to a service, you need a UiPath account because the button is not available when logged in with a SAML SSO account. Alternatively, you can switch to using OAuth for authorization, in which case the information from API Access is no longer required.

Troubleshooting

If you are getting the error User login failed. (#216), it may be due to missing email address mapping in the configuration of the SAML identity provider.
The SAML claim must be named http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress and the value must have a valid email address.

Setting up SAML SSO with Azure AD

You can use the Azure portal to enable SSO for an Enterprise application that you added to your Azure AD tenant.

After you configure SSO, your users can sign in by using their Azure AD credentials.

Important:

If your users are in Azure AD but cannot use the Azure AD integration instructions to configure AAD to your UiPath organization, configuring AAD as a SAML-based IdP may be an option.

This is due to restrictions around giving permissions to read user details and group memberships of all UiPath application users.

Enabling SAML SSO for an application

  1. Log into the Azure portal using one of the roles listed in the prerequisites.

  2. Go to Azure AD, then select Enterprise applications.

    The All applications page opens that lists the applications in your Azure AD tenant.

    Search for and then select the application that you want to use. For example, UiPath.

    Note:

    To create an application for SSO, follow the steps in this section.

  3. From the left sidebar in the Manage section, select Single sign-on to open the SSO editing page.

  4. Select SAML to open the SSO configuration page.

    After the application has been configured, users can sign into it using their Azure AD tenant credentials.

  5. Under the Basic SAML Configuration section, click Edit.

  6. Fill out the Entity ID and Assertion Consumer Service (ACS) URL fields based on the values provided in the SAML configuration settings in the UiPath portal.

    docs image
    docs image
  7. Click Save.

    Note:

    UiPath requires either the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress or the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn claims to be sent by the SAML identity provider.

    If both claims are sent in the ACS payload, then UiPath will prioritize the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress claim.

    By default, the application in Azure AD is configured to send the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress claim, with the user's email address as the value for the claim.

    If you are switching from or planning to switch to Azure AD directory integration, please note:

    • The value passed in the prioritized claim is used by UiPath as a unique identifier and is used to link any existing local users (using the local user's email address) to this directory user in Azure AD.

    • For a smooth switch between Azure AD and SAML directory integration, it is recommended you pass in both of these claims with the appropriate user values.

      Here is an example configuration:

      docs image
  8. Copy the App Federation Metadata Url.

  9. Navigate to the UiPath Administration portal and go to the SAML Configuration page.

  10. Paste the App Federation Metadata Url in the Metadata URL field.

  11. Click Fetch data to have the system request user-related info from the identity provider.

Setting up claims for automatic provisioning to UiPath

  1. Log into the Azure portal using one of the roles listed in the prerequisites.

  2. Go to Azure AD, then select Enterprise applications.

    The All applications page opens that lists the applications in your Azure AD tenant.

    Search for and then select the application that you want to use. For example, UiPath.

    Note:

    To create an application for SSO, follow the steps in this section.

  3. From the left sidebar in the Manage section, select Single sign-on to open the SSO editing page.

  4. Click Edit in the Attributes & Claims section of the SSO editing page.

    docs image
  5. Click Add a group claim to configure the groups that you want to send to UiPath.

    Note:

    To set advanced configurations, choose from the Advanced Settings dropdown.

  6. Click Save.

  7. To finish the configuration, follow the Step 2.5 Configure Provisioning Rules (optional) steps from our public documentation.

Note:

If a customer prefers to use UPN, you can navigate to the Attributes & Claims section and change the value for the emailaddress attribute.

Create application for SSO

  1. Log into the Azure portal using one of the roles listed in the prerequisites.
  2. Go to Azure AD, then select Enterprise applications.The All applications page opens that lists the applications in your Azure AD tenant.
  3. click New Application > Create your own application.
  4. Give your application a name. For example, UiPath.
  5. Select Integrate any other application that you don't find in the gallery (Non-gallery).
  6. Click Create.

Was this page helpful?

Get The Help You Need
Learning RPA - Automation Courses
UiPath Community Forum
Uipath Logo White
Trust and Security
© 2005-2024 UiPath. All rights reserved.