External User Directories
External user directories can be set up for user management in Therefore™. The user management functions include authentication, authorization, user account management, and group management.
Configuration
Right-clicking on External User Directories opens a dialog in which the administrator can add, edit, or remove external user directories. Clicking the drop-down arrow next to 'Add' allows for selection of one of the supported providers. Selecting a provider opens a dialog to configure the external user directory.
Authentication against the provider
Once all settings have been entered, the administrator has to authenticate against the external login provider in a browser window, and allow Therefore™ to access the external user directory. Once the connection has been established, the new domain is accessible in the Users and Groups options where the users can be granted appropriate role-based access permissions on Therefore™ objects.
Installed Client Configuration
When users from an external user directory are connecting to Therefore™ using an installed client application the Server Connection settings in the Therefore™ Solution Designer have to be configured. Select the external login provider under Authentication Provider and click 'Update from Server' to populate the settings.
User / Group Synchronization
In order for User / Group synchronization to work, the feature 'Replication' has to be installed from the Therefore™ setup and the Therefore™ Replication service has to be set to the startup type 'Automatic'. If these prerequisites are configured users and groups can be synchronized from the 'User / Group Synchronization' node under Integrations > Replication / Synchronization.
Settings
Common setting for all providers:
Use the browser for login
Use the default system browser instead of the internal Chromium Browser to open the user sign-in page of the external login provider.
Additional Domains
If the external user directory contains users from external domains these domains can be added here.
For example: A Microsoft Entra ID directory contains users with the primary domain moyaware.onmicrosoft.com but also users with the domain moyaware.com. In this case, enter moyaware.com as an additional domain.
Azure Active Directory
Therefore™ Client ID
The ID of a Microsoft Entra ID application used for Therefore™ Client login.
Logon domain
If SSO is configured for Microsoft Entra ID the domain is entered here. For example:ontherefore.com
Use a custom application to access Microsoft Entra ID
This checkbox needs to be checked if authentication is set up using an application in Microsoft Entra ID.
Azure tenant name
The name of the Entra ID tenant the login applications are configured on. Values are entered in the following format: <company>.onmicrosoft.com
Application client ID
The ID of the Microsoft Entra ID application used for Therefore™ server login.
Application secret
The value of a client secret of the Microsoft Entra ID application used for Therefore™ server login.
Okta
Domain
The Okta used in the configuration, for example:
therefore.okta.com
API Access Key
The value of the API token created in the Okta portal.
Therefore™ Client ID
The client ID of the login application created in Okta.
Authorization Server ID
Authorization Server ID in an Okta specific setting since multiple different authorization servers with different settings are allowed. If an administrator has defined different authorization servers then Therefore™ needs to be informed which Authorization Server to use. Enter the authorization server's ID into this field to do so.
OneLogin
Domain
The OneLogin domain used in the configuration, for example:
therefore.onelogin.com
Therefore™ Client ID
The Client ID of the OIDC application that was configured in the OneLogin administration portal.
API Settings
Domain
The API URL varies by region, for example:api.us.onelogin.com
api.eu.onelogin.com
Client ID / Client Secret
These are the Client ID / Client Secret from the API Credentials configured in the OneLogin administration portal.
ADFS (OIDC)
Domain / Directory name
The AD FS domain used in the configuration, for example:
adfs.ontherefore.com
Auto-Detect
Click this button to enter the OIDC discovery URL and auto-populate most of the other settings.
OIDC discovery URL
The URL follows the pattern specified below:https://domain/.well-known/openid-configuration
Client Connection Settings
Authorization endpoint
Endpoint with the following URL pattern:https://domain/adfs/oauth2/authorize/
Therefore™ Client ID
The client ID of the native application configured on the AD FS server. This setting has to be entered manually.
Scopes
The application scopes set for the application group on the AD FS server.
Additional parameters
If additional login parameters have been specified they can be entered here.
Server Settings
Issuer
A URL with the following pattern:https://domain/adfs
JWKS endpoint
A URL with the following pattern:https://domain/adfs/discovery/keys
Username claim
The claim type expressed as a Uniform Resource Identifier.
Groups claim
If group membership is specified as a rule in AD FS, the groups claim can be entered here.
Generic OIDC
This option can be used to configure any provider that offers the OpenID / OIDC protocol to integrate with Therefore™. Configuration varies by provider. The settings in this dialog are the same as the ones in the AD FS (OIDC) settings.