UiPath Process Mining

The UiPath Process Mining Guide

Set up Single Sign-on through SAML


This page describes how to set up single sign-on based on SAML.

Identity provider

To enable single sign-on based on SAML, both UiPath Process Mining and an Identity Provider, such as ADFS, must be properly configured so that they can communicate with each other. See also Configuring ADFS.

Refer to the identity provider's product documentation, and make sure to configure the authentication using the response elements as described below.


  • nameID: A persistent identifier for the user (urn:oasis:names:tc:SAML:2.0:nameid-format:persistent).

Attribute Statements ("claims")

  • The user's full name.
  • The user's email address.
  • Either a single group identifier, or an array of group identifiers.



Process Mining only supports Service Provider Initiated (SP-initiated) SSO. This means that
the user navigates to the Process Mining login page, from which the user will be redirected to the Identity Provider to login.

If SAML is enabled and correctly configured, a button is displayed at the bottom of the Login page. See the illustration below.

If the external identity provider uses a multi-factor authentication protocol, the user needs to comply with the corresponding rules as well in order to successfully log in.

Configuring UiPath Process Mining for Single Sign-On

  1. Go to the Settings tab of the Superadmin page of your UiPath Process Mining installation to configure the Server Settings. See illustration below.
  1. Add the required SAML settings in the ExternalAuthenticationProviders setting of the Server Settings. Below is a description of the JSON keys of the saml object.
entrypointSpecify the URL to the remote Identity Provider.Yes
issuerEnables you to specify the issuer string to supply to the Identity Provider. The default value is set to the Process Mining URL.No
authnContextEnables you to specify the authentication method to request from Identity Provider. By default no authentication context is requested.No
certEnables you to specify the signing certificate to validate the Identity Provider's responses, as a single line PEM-encoded X.509 format with newlines replaced by ‘\n’.No
privateKeyEnables you to specify the key to sign requests sent to the remote Identity Provider, as a single line PEM-encoded X.509 format with with newlines replaced by ‘\n’.No
signatureAlgorithmEnables you to specify the signature algorithm used when signing requests. Possible values are:
• sha1;
• sha256;
• sha512.
identifierFormatName identifier format to request from Identity Provider. Defaults to "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent".No
validateInResponseToWhen set to "true", validates "InResponseTo" from incoming SAML responses. Defaults to "true".No
loggingLevelEnables you to specify whether you want to add information regarding the login process to the log. Possible values:
• info;
• warn;
• error.
Note: It is recommended to enable this only when you experience problems with logging in.

Below is an example of the Server Settings with the ExternalAuthenticationProviders setting with the saml object for a basic ADFS configuration.

, "ExternalAuthenticationProviders": {
     "saml": {
         "entryPoint": ""
       , "authnContext": ""
       , "identifierFormat": null

Below is an example of the Server Settings with the ExternalAuthenticationProviders setting with the saml object for an ADFS configuration with two-way certificate checking.

, "ExternalAuthenticationProviders": {
      "saml": {
         "entryPoint": ""
       , "cert": "-----BEGIN CERTIFICATE-----\nMIIC4jCC...JfdvPQ==\n-----END CERTIFICATE-----"
       , "privateKey": "-----BEGIN PRIVATE KEY-----\nMIIJQwIB...tMyOgQw=\n-----END PRIVATE KEY-----"
       , "signatureAlgorithm": "sha256"
       , "authnContext": ""
       , "identifierFormat": null
  1. Click on SAVE to save the new settings.

  2. Press F5 to refresh the Superadmin page. This loads the new settings and enables SAML groups to be created based on these settings.




Make sure Single Sign-on works correctly before enabling autologin. Enabling autologin when SSO is not set up correctly can make it impossible for users affected by the autologin setting to log in.

With the AutoLogin Server Setting, the user will be automatically logged in using the current active SSO method.
By default, AutoLogin is set to none. If you want to enable auto-login for end-users and/or Superadmin users, you can specify this in the AutoLogin in the Superadmin Settings tab. See The Settings Tab.



When logging in via localhost, auto-login will always be disabled for Superadmin users.

Example logs
It would be useful to enable users to do more debugging of their own using the logs. In particular, once they have the communication between the IdP and the platform working, they should be able to get a login working by looking at the logs.

For example a log line like this should enable a customer to fix their login problem without our support:
[2021-08-03T16:45:25.291Z] STDERR: Log: failed Superadmin login for 'Jim Jones' ([email protected]) from ''. Member-of: ["Admins"]. Valid groups: ["CN=Admins,OU=Company,OU=Applications,OU=Groups,DC=abc,DC=DEF,DC=CompanyName,DC=Com"].

Here we show the set of groups that we received from the IdP for the user ‘Jim Jones’, i.e. Jim is a member of one group, “Admins”. In our platform there is one group configured, the one with the long Distinguished Name. The user is denied access because none of the groups in the member-of set match any of the configured groups. From this the user should be able to realise that either they should configure their IdP to sent the full distinguished name, or they should configure the group in our platform to only reference the common name.


When the user login fails after setting up the communication between the Identity Provider and Process Mining, you are advised to check the log files in the <INSTALLDIR>/logs folder.


Below is an example logline from a denied access.
[2021-08-03T16:45:25.291Z] STDERR: Log: failed Superadmin login for 'Jim Jones' ([email protected]) from ''. Member-of: ["Admins"]. Valid groups: ["CN=Admins,OU=Company,OU=Applications,OU=Groups,DC=abc,DC=DEF,DC=CompanyName,DC=Com"].

The Valid groups list contains the set of groups received from the Identity Provider for the user ‘Jim Jones’. ‘Jim Jones’ is a member of one group, “Admins”. In Process Mining only the group with the long Distinguished Name is configured. ‘Jim Jones’ is denied access because “Admins” is not listed in the Valid groups.

You should either configure the Identity Provider to send the full distinguished name, or configure the “Admins” group in Process Mining to only reference the common name.

Next steps

To use authentication using SAML, you must create one or more AD groups to allow members to log in. For Superadmin users, or app developers you can create AD groups on the Superadmin users tab. See Adding Superadmin AD Groups.

For end-user authentication, AD groups can be created on the End user administration page. See Adding End-user AD Groups.

Updated about a month ago

Set up Single Sign-on through SAML

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.