×

Please give details of the problem

Skip to content

User Authentication

Users intending to work with DigitalSuite and the applications running on it need to be authenticated. The only exception to this is the access to public resources, which is possible for everybody without verification.

DigitalSuite supports different methods of user authentication, which can be configured at the customer accounts:

Each execution mode of DigitalSuite can use a different authentication method. This means, for example, that there is no need to have real users in Google or a SAML identity provider system to test applications, as long as the Login/Password method is used for the Test mode.

In addition to these configurable authentication methods, DigitalSuite provides the possibility to log in with an Apple ID from a mobile device running RunMyApp for iOS.

A password policy allows customers to limit the number of login attempts. Users who fail to log in within the maximum number of attempts are locked out of their accounts. An administrator needs to unlock the accounts before the users can log in again.

Login/Password

With this authentication method, users log in with their email address and password stored in DigitalSuite.

Instead of the standard login page of DigitalSuite, a custom login page can be configured. This may be a public web interface developed in DigitalSuite, or a public HTML file that has been uploaded to DigitalSuite, for example, in the context of a project.

The Login/Password authentication method is always available, even if a different method is selected for an execution mode.

Google OAuth2

With this authentication method, users connect to DigitalSuite using their Google account. The authentication is performed by Google. It can be triggered in one of the following ways:

  • Choosing Sign in with Google on the DigitalSuite standard login page.
  • Login from the standard or a custom login page with the corresponding authentication policy configured.
  • Direct login from a DigitalSuite web interface.
  • Access to a DigitalSuite resource by adding from=google&domain= to the URL.
  • Access to the RunMyProcess application on the Google Workspace Marketplace.

Users who are not yet logged in to Google need to specify their Google credentials. Otherwise, they can continue working with their existing Google login.

In the customer account in DigitalSuite, a user with the same email address as the Google account must exist. Alternatively, auto-provisioning can be enabled in Live execution mode: If a user logging in with Google credentials does not yet exist in DigitalSuite, a corresponding DigitalSuite account is created:

  • The user name and email address are retrieved from Google.
  • The user's profile is set to User.
  • English is set as the language for the development environments and applications.
  • Access is granted for applications which are accessible for all users (everybody) of the account.

SSO with SAML 2.0

With this authentication method, users connect to DigitalSuite using the credentials of a SAML 2.0 compliant identity provider. Single sign-on is supported. This means that users who try to connect to DigitalSuite and are not yet logged in to the SAML identity provider's federated environment need to specify their credentials to this provider. Otherwise, they can continue working with their existing login.

The configuration of the SSO with SAML 2.0 authentication method includes the following:

  • The URL of the SAML 2.0 compliant identity provider redirect page. Users are directed to this page when they request a protected resource from DigitalSuite without having an active session. If they are not yet connected to the federated environment, they are redirected to the SSO login page.

  • The URL used for redirecting users when they log out of DigitalSuite. This may imply to log out from all the applications available in the federated environment.

  • The attribute in the identity provider system which is used to share user identities with DigitalSuite. This attribute has to contain the email address of the DigitalSuite user account, like: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress.

  • An ID that uniquely identifies the customer account in DigitalSuite as a service provider to the identity provider. Cloud-based identity providers usually agree on a unique service name with their customers for this purpose.

  • The certificate issued by the identity provider in PEM format.

  • Optionally, a public key for the signing of requests.

  • Optionally, the URL for account management redirects.

  • Optionally, auto-provisioning of users in Live execution mode. For unknown users who access DigitalSuite, an account is automatically created with the following settings: name and email address obtained from the identity provider, User profile, English is as the language for development environments and applications. Access is granted for applications which are accessible for all users (everybody) of the account.

Triggering Composite APIs by SAML Events

With the SSO with SAML 2.0 authentication method, specific events can be configured to trigger the execution of a given composite API in DigitalSuite. The composite API accepts the user data provided by SAML as input and can make use of this data for the customer's purposes.

The following events can be configured as composite API triggers:

  • User authentication: The composite API triggers when a user with an existing DigitalSuite account is authenticated with SAML.
  • User creation: The composite API triggers when a user is authenticated with SAML who does not yet have a DigitalSuite account. This is possible only for the Live execution mode with the auto-provisioning option enabled.

Sign SAML requests with your own certificate

Once you enable SSO with SAML 2.0 for your RunMyProcess account, you can optionally sign SAML AuthNRequest and LogoutRequet with your own certificate as follows.

  1. Create your own key pair.
  2. Add the private key to your RunMyProcess account to sign SAML requests.
  3. Add the public key to Identity Provider to validate SAML requests signed by Service Provider (RunMyProcess).

For the step 1, you can use openssl to generate a key pair for example.

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem \
-sha256 -days 365 -nodes -subj "/C=Country/ST=State/L=Locality/O=Organization/OU=OrganizationUnite/CN=CommonName"

For the step 2, you can use the below APIs to add, update and remove your private key in RunMyProcess. Please note you need to replace ${LIVE_DOMAIN}, ${YOUR_CUSTOMER_ID}, ${OPERATION}, ${MODE} and the private key in the below example.

API to add or update the private key

  • HTTP request method and path
PUT https://${LIVE_DOMAIN}/config/${YOUR_CUSTOMER_ID}/certificate
  • HTTP request payload
<?xml version="1.0" encoding="UTF-8"?>
<feed xml:base="https://${LIVE_DOMAIN}/" xmlns:xml="http://www.w3.org/XML/1998/namespace" 
xmlns="http://www.w3.org/2005/Atom" xmlns:p="http://www.runmyprocess.com/library/">
<title>Certificate</title>
<generator uri="http://www.runmyprocess.com">(c) RunMyProcess</generator>
<author>
  <uri>config/${YOUR_CUSTOMER_ID}/certificate</uri>
</author>
<entry>
  <title>My AuthN Certificate</title>
  <category term="hash" label="SHA256" />
  <category term="encryption" label="RSA" />
  <category term="operation" label="${OPERATION}" />
  <category term="format" label="PEM" />
  <category term="mode" label="${MODE}" />
  <content>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
  </content>
</entry>
</feed>

API to remove the private key

  • HTTP request method and path
DELETE https://${LIVE_DOMAIN}/config/${YOUR_CUSTOMER_ID}/certificate/${OPERATION}?P_mode=${MODE}

Variable description

  • LIVE_DOMAIN: Live domain of the RunMyProcess platform (e.g. live.runmyprocess.com).
  • YOUR_CUSTOMER_ID: Your RunMyProcess account ID (e.g. 112501524864919680).
  • OPERATION: SAML operation where you want to add, update or remove the private key. You can specify SAML_AUTH (AuthNRequest) or SAML_LOGOUT (LogoutRequest).
  • MODE: RunMyProcess execution mode where you want to add, update or remove the private key. You can specify TEST, ACCEPTANCE or LIVE.

Apple ID

On mobile devices running RunMyApp for iOS, users can connect to DigitalSuite with their Apple ID. The authentication is performed by Apple through their standard procedures.

As a prerequisite, a user with the same email address as the Apple account must exist in DigitalSuite within the relevant customer account.