×

Please give details of the problem

Skip to content

User Authentication

All users accessing DigitalSuite and the applications running on it need to be authenticated.

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 the SAML identity provider system to test applications, as long as the Login/Password method is used for the Test mode.

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: 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 to all users 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.

Trigging 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. In this case, an account is automatically created for the user.