Skip to main content
Version: 16.0

Authentication Mechanisms of the ADOIT Web Client

This section provides an overview of the authentication mechanisms that the ADOIT web client supports. These authentication mechanisms can be used separately or in combination.

Additionally, this section provides basic information on how ADOIT can be configured to synchronise user data with an external user management system.

Some Terms You Should Know

Here is a short explanation of some terms with which you should become familiar. For more detailed information on these topics, see Technical Concepts.

TermAcronymDefinition
Identity ManagementIDMIn the IDM scenario, an IDM system is an authority that can authenticate users and has knowledge on the users’ group memberships and other organizational details.
Lightweight Directory Access ProtocolLDAPStandardised protocol for accessing information in directory services.
Security Assertion Markup LanguageSAMLSAML is an XML-based framework for exchanging authentication and authorization data.
Single Sign-OnSSOSingle sign-on (SSO) is an authentication process that allows a user to access multiple applications with one set of login credentials.
OpenID ConnectOIDCOpenID connect (OIDC) is an authentication layer on top of the OAuth 2.0 authorization framework that can be used to securely sign in a user to web applications.
Administration Toolkit-Desktop application used for the administration of ADOIT.
Admin Page-Web application used for the administration of ADOIT.

At a Glance

The purpose of authentication in ADOIT is to prove that users are who they claim to be. The following authentication mechanisms are available:

  • Standard ADOIT Users

    Users are created manually in the Administration Toolkit. Users log in with username and password. Requires no configuration.

  • LDAP Authentication

    Users are managed in a directory service. Users log in with their familiar LDAP identity and credentials. Requires additional configuration.

  • IDM Authentication

    Users are managed in an external user management system. Users log in via single sign-on or with username and password. Requires additional configuration.

  • SAML Authentication

    Users are managed in an external user management system. Users log in via single sign-on or by entering credentials (username and password, certificates, etc.). Requires additional configuration.

  • OIDC Authentication

    Users are managed in an external user management system. Login via single sign-on is possible. Requires additional configuration.

You can use synchronisation to import users and associated user data from an external source that e.g. supports LDAP or SAML claims. The two most important elements of a synchronisation strategy are:

  • Synchronisation Scope

    This defines what will be synchronised by specifying whether to include user attributes, roles and groups.

  • Synchronisation Timing

    This defines when synchronisation of users and associated user data should occur. Users may either be synchronised on login or through a periodic synchronisation task (requires LDAP coupling).

For more detailed information on the topics of this section, see Authentication Mechanisms and Supported Synchronisation Scenarios.

Feature Overview

This table contains a summary of the features of the different authentication mechanisms.

Standard ADOIT UsersLDAP AuthenticationIDM AuthenticationSAML AuthenticationOIDC Authentication
Login with username and passwordYesYesYes (depending on the IDM solution)Yes (depending on the SAML IdP)Yes (depending on the OP)
SSONoNoYes (depending on the IDM solution)Yes (depending on the SAML IdP)Yes (depending on the OP)
On login, synchronise attributes, role and group assignment (with external user management system)NoYesYesYesYes
Periodically, synchronise attributes, role and group assignment (with external user management system)NoYesYes (with LDAP coupling)Yes (with LDAP coupling)Yes (with LDAP coupling)
Create users automaticallyNoYesYesYesYes

Authentication Mechanisms

The following image shows the supported authentication mechanisms in ADOIT:

 Authentication Mechanisms

The different authentication mechanisms are described in detail in the sections below.

Standard ADOIT Users

  • ADOIT users are created in the Administration Toolkit.

  • Login to the ADOIT web client requires input of username and password. These credentials are used to authenticate the user against the available data in the ADOIT database.

  • The assignment of user attributes, rights and system roles is controlled via the User Management component in the Administration Toolkit.

  • For instructions on how to create ADOIT users, see the chapter User Management in the Administration Manual.

Benefits

  • No additional configuration is required to use ADOIT users.

LDAP Authentication

  • Users can either be imported from a directory service or mapped to ADOIT users.

  • Login to the ADOIT web client requires input of username and password. The provided credentials will be used to authenticate the user against the configured directory service.

  • A precondition for this scenario is that the connection of ADOIT to the directory service in use (e.g. Active Directory) is established on the Admin Page.

  • The assignment of user attributes, rights and system roles may be controlled via the User Management component in the Administration Toolkit or synchronised with an external directory service.

  • Specific configuration steps are necessary when setting up the ADOIT web client for this authentication mechanism. For instructions, see the chapter Set Up Web Client Login with LDAP Coupling.

Benefits

  • Use existing authentication infrastructure.

  • Authentication configuration can be easily extended to include synchronisation.

IDM Authentication

  • Users can either be imported from an external user management system or mapped to ADOIT users.

  • Login to the ADOIT web client via single sign-on is possible using an Identity Management System (IDM).

  • A precondition for this scenario is the connection of ADOIT to an authentication server in the target environment which provides means for authentication with an external user management system (e.g. Microsoft Internet Information Services connected to an Active Directory).

  • The assignment of user attributes, rights and system roles may be controlled via the User Management component in the Administration Toolkit or synchronised with an external user management system.

  • Specific configuration steps are necessary when setting up the ADOIT web client for this authentication mechanism. Please contact your ADOIT consultant to receive instructions.

Benefits

  • Use existing authentication infrastructure.

  • Enables single sign-on (SSO).

SAML Authentication

  • Users can either be imported from an external user management system or mapped to ADOIT users.

  • The external user management system must provide an Identity Provider (IdP) for SAML 2.0 (e.g. Active Directory Federation Services [AD FS] or Shibboleth).

  • To log on to the web client, the user is redirected to the IdP. Depending on the configuration of the IdP, the authentication is carried out via single sign-on or by entering access data (username and password, certificates, etc.).

  • No server-to-server communication is necessary for this authentication mechanism, since all data is transmitted via the browser.

  • The assignment of user attributes, rights and system roles may be controlled via the User Management component in the Administration Toolkit or synchronised with an external user management system.

  • Specific configuration steps are necessary when setting up the ADOIT web client for this authentication mechanism. Please contact your ADOIT consultant to discuss the integration process.

Benefits

  • Use existing authentication infrastructure.

  • Enables single sign-on (SSO).

  • Increased Security. HTTPS based browser communication with centralised authentication system. Original user data can remain behind the firewall while SAML verifies user identities.

OIDC Authentication

  • Users can either be imported from an external user management system or mapped to ADOIT users.

  • A precondition for using OpenID Connect (OIDC) is the connection of ADOIT to an OpenID Connect provider (OP) that verifies the identity of the user as well as provides basic profile information about the user.

  • To log on to the web client, the user is redirected to the OP. Login to the ADOIT web client via single sign-on is possible using OIDC authentication.

  • The assignment of user attributes, rights and system roles may be controlled via the User Management component in the Administration Toolkit or synchronised with an external user management system.

  • Specific configuration steps are necessary when setting up the ADOIT web client for this authentication mechanism. For instructions, see the chapter Set Up OIDC Authentication.

Benefits

  • Use existing authentication infrastructure.

  • Enables single sign-on (SSO).

  • Increased Security. HTTPS based browser communication with centralised authentication system. Original user data can remain behind the firewall while OIDC verifies user identities.

Supported Authentication Scenarios

The following scenarios detail the different ways ADOIT can handle authentication.

 Supported SSO Scenarios

In general, SSO is possible when using the authentication mechanisms IDM (depending on the IDM solution), SAML (depending on the SAML IdP) oder OIDC (depending on the OP).

Scenario 1: Login with Username and Password

Each authentication mechanism allows users to access the web client by entering their login credentials. Once validated, the users are logged in.

Standard ADOIT users are validated against the ADOIT database. When authentication takes place using either the LDAP, IDM, SAML or OIDC authentication mechanisms, the provided credentials are authenticated against an external source.

Scenario 2: SSO

The authentication mechanisms IDM, SAML and OIDC can be configured for SSO.

SSO using an external IDM system requires an external server that enriches the request from the client web browser with the login data. Possible technologies:

  • Microsoft Internet Information Services (IIS)

  • Tomcat Valve

SSO using SAML requires a SAML Identity Provider that can authenticate users and supports SSO. Possible SAML identity providers:

  • Microsoft Active Directory Federation Services (AD FS)

  • Okta

  • Shibboleth

  • Any other SAML 2.0-compliant identity provider (prior evaluation required)

SSO using OIDC requires an OpenID provider (OP) that can authenticate users and supports SSO. Possible OpenID providers:

Supported Synchronisation Scenarios

The following scenarios detail how synchronisation of user properties and access rights can be achieved in ADOIT.

 Supported Synchronisation Scenarios

The authentication mechanisms LDAP, IDM, SAML and OIDC can be configured to use LDAP coupling to fetch additional user data from a directory service. When using IDM authentication, information about the user can also be transported using HTTP headers. When using SAML authentication or OIDC authentication, information about the user can also be transported using so-called claims.

Synchronisation Strategy

The two most important elements of a synchronisation strategy are:

 Defining a Synchronisation Strategy

Synchronisation Scope

You can modify the scope of the synchronisation by specifying whether to include user data.

  • Create user, do not update user data

    This scenario applies if an external user management system should be used, but user attributes, system roles, user groups, repositories and named users be assigned manually in the Administration Toolkit. Default user groups and system roles are assigned to all imported users. User data is not synchronised to prevent the settings made in the Administration Toolkit from being overwritten.

  • Create user, update some user data

    Some user data is updated according to the information retrieved from the external user management system on every synchronisation. It is possible to choose any combination of the options user attributes, system roles, user groups, repositories and named users. This approach is useful, for example, if properties like first name, last name and email address should be synchronised but permissions should be managed in the Administration Toolkit.

  • Create user, update all data

    This scenario applies if users from an external user management system are maintained in groups which correspond to ADOIT roles and permissions. In this case, a mapping can be configured and the user data will be updated on every synchronisation. Users are assigned to specific user groups and system roles based on the mapping.

Synchronisation Timing

It is possible to define when synchronisation of users and associated user data should occur.

  • When synchronisation on login is enabled, user data is updated every time the user logs in. Users that log in to the web client for the first time can be created "on-the-fly" in the database.

  • LDAP coupling is required if a periodic synchronisation task should be run. Users will be created in ADOIT before logging in for the first time. The periodic synchronisation job is useful to make all stakeholders available for assigning organisational responsibilities. Once configured, the synchronisation may also be run on demand.

We recommend combining both synchronisation types and synchronise users on login and periodically.

Scenario 1: Synchronisation Using LDAP Coupling

This scenario requires that authentication takes place using either the LDAP, IDM, SAML or OIDC authentication mechanisms. LDAP coupling can be used on top to fetch additional user data from a directory service. Possible directory services:

  • Microsoft Active Directory (AD)

  • eDirectory

  • Any other LDAP v3-compliant directory service (prior evaluation required)

This synchronisation scenario supports synchronisation on login and periodic synchronisation.

Scenario 2: Synchronisation Using HTTP Headers (IDM Authentication)

This scenario requires that authentication takes place using the IDM authentication mechanism. Specific HTTP headers can be used to transport information about the user. In addition to the username, information about the user’s group memberships in the external user management system can be transported. The type of data that can be transported via HTTP headers depends on the IDM system in use. Possible technologies:

  • Microsoft Internet Information Services (IIS)

  • Tomcat Valve

This synchronisation scenario supports synchronisation on login.

Scenario 3: Synchronisation Using SAML Claims

This scenario requires that authentication takes place using the SAML authentication mechanism. A set of claims is used to transport information about the user. In addition to the username, additional claims to be evaluated can be configured. These additional claims can be mapped to ADOIT user groups and system roles as well as the ADOIT user attributes first name, last name and email address. Possible SAML identity providers:

  • Microsoft Active Directory Federation Services (AD FS)

  • Okta

  • Shibboleth

  • Any other SAML 2.0-compliant identity provider (prior evaluation required)

This synchronisation scenario supports synchronisation on login.

Scenario 4: Synchronisation Using OIDC Claims

This scenario requires that authentication takes place using the OIDC authentication mechanism. A set of claims is used to transport information about the user. In addition to the username, additional claims to be evaluated can be configured. These additional claims can be mapped to ADOIT user groups and system roles as well as the ADOIT user attributes first name, last name and email address. Possible OpenID providers:

This synchronisation scenario supports synchronisation on login.

Choosing an Authentication Mechanism

This section provides guidance on choosing an appropriate authentication mechanism for common application scenarios. Consider the following questions, then check the table below:

  • Should users be created manually in ADOIT or imported from an external user management system where they are managed?

  • Which user data should be managed in ADOIT and which in the external user management system? Consider the assignment of user attributes, rights and roles.

  • Should permissions in ADOIT be based on group membership in an external user management system? If yes, synchronisation of user attributes, rights and roles should be considered.

  • Should users be available in ADOIT before logging in for the first time to make all stakeholders available for assigning organisational responsibilities? If yes, a periodic synchronisation task should be considered.

  • Is SSO required for authentication?

#Use CaseRecommended Authentication Mechanisms
1
  • No external user management system or it should not be used

  • Standard ADOIT users

2
  • An external user management system should be used

  • User attributes, roles and rights should be managed in ADOIT

  • LDAP

  • IDM

  • SAML

  • OIDC

3
  • An external user management system should be used

  • User attributes, roles and rights should be managed in the external user management system (any combination of these)

  • LDAP

  • IDM (with HTTP headers or LDAP coupling)

  • SAML (with SAML claims and optionally LDAP coupling)

  • OIDC (with OIDC claims and optionally LDAP coupling)

4
  • An external user management system should be used

  • SSO should be used

  • IDM

  • SAML

  • OIDC

5
  • Users are managed in an LDAP v3-compliant directory service

  • User attributes, roles and rights should be managed in the external user management system (any combination of these)

  • Users are created via periodic synchronisation task

  • LDAP

  • IDM (with LDAP coupling)

  • SAML (with LDAP coupling)

  • OIDC (with LDAP coupling)

6
  • Users are managed in an LDAP v3-compliant directory service

  • User attributes, roles and rights should be managed in the external user management system (any combination of these)

  • Users are created via periodic synchronisation task

  • SSO should be used

  • IDM (with LDAP coupling)

  • SAML (with LDAP coupling)

  • OIDC (with LDAP coupling)

Technical Concepts

SSO

Single sign-on (SSO) is an authentication process that allows a user to access multiple applications with one set of login credentials. Once the user is authenticated by one application, they can access other applications without having to log in again. Changes to the user data can be made in a central place and have an effect in all single sign-on compliant applications (avoidance of redundancies).

Single sign-on requires that user data be managed centrally, in a directory service, and that single sign-on compliant applications (such as ADOIT) have access to this user data. How the data is accessed depends on the respective directory service.

LDAP

LDAP is a standardised protocol for accessing information in directory services. Directory services that support LDAP are called LDAP-compliant. However, there are also directory services that are not LDAP-compliant and must be accessed in a proprietary way.

In addition to the basic accessibility (LDAP-compliant or otherwise), a single sign-on compliant application must also know which data is stored at which location in the user directory. This depends on the respective directory service and is determined by the directory schema.

IDM

IDM stands for Identity Management. In the IDM scenario, the actual authentication of the user is performed by an IDM system that takes a request from the client (browser) and processes it. After successful authentication, this system enriches the original request with the necessary authentication data and forwards it to the web server.

The web server receives the enriched, original request and forwards it to the desired web application. The web application (deployed in the web server) uses the enriched information to identify the user and its roles and to react accordingly providing the correct functionality.

Only requests that pass the initial check by the IDM system will be forwarded to the web server. If the request is sent by a user that is configured in the IDM system to not have access to ADOIT at all, the request will not be sent to the web server.

SAML

SAML is an XML-based, open-standard data format for exchanging authentication and authorization data between parties, in particular, between an Identity Provider (IdP) and a Service Provider (SP). An IdP is an authority that can authenticate users and has knowledge of the users’ group memberships and other organizational details. The SP is the actual web application that delegates the authentication to the IdP.

The following figure illustrates the authentication process as an interaction between the User Agent (UA), the IdP and the SP.

 Sequence Diagram of a SAML Based Authentication Process © Tom Scavo / CC-BY-SA-3.0

One important feature of the SAML protocol is the fact that there is no server-to-server communication involved. The complete message flow is done via the UA by means of redirects and (possibly auto-submitted) POST requests.

Whenever a user tries to access the SP’s web application without a valid session, the SP generates a SAML authentication request and redirects the UA to the IdP’s URL. The authentication request is sent as an argument of the query string. The IdP may validate the origin of the authentication request by verifying that it has been signed with the SP’s certificate.

The next step is the authentication of the user which can use various procedures including form-based authentication, Integrated Windows Authentication (including SSO), multi-factor authentication and others. If the authentication succeeds, the IdP assembles the authentication response containing the security assertion with the so-called claims that are used to transport information about the user. Once the UA sends this information to the SP, the response can be validated by verifying the signature. The SP can then use the information received to establish the user’s session with the web application.

OIDC

OIDC stands for OpenID connect. OIDC is an authentication layer on top of the OAuth 2.0 authorization framework that can be used to securely sign in users. It allows web applications (also-called relying parties, or RP) to use an OpenID Connect Provider (OP) to verify the identity of a user.

To log on to the web client, the user is redirected to the OP. Tokens of various types are exchanged between the RP and OP in order to verify identity or provide access permissions. These tokens contain claims, which are used to transport all relevant user data (name, e-mail address, etc.) to ADOIT.

Depending on the configuration of the OP, the authentication is carried out via single sign-on or by entering access data (username and password, certificates, etc.).

FAQs

  • Does ADOIT perform write operations to external user management systems?

    No. ADOIT only accesses external user management systems directly (LDAP) or indirectly (IDM, SAML, OIDC) with read access. No objects, attributes or attribute values are created or changed in the external user management system.

  • What information does ADOIT read from external user management systems?

    The attributes which are read from directory services when using LDAP authentication and synchronisation are defined on the Admin Page.

    The attributes which are read from external user management systems when using IDM authentication and synchronisation depend on the used IDM solution and configuration.

    The attributes which are read from external user management systems when using SAML authentication and synchronisation are defined on the IdP side.

    The attributes which are read from external user management systems when using OIDC authentication and synchronisation are defined on the Admin Page.

  • Are passwords retrieved from external user management systems and stored by ADOIT?

    No. User passwords are not retrieved by ADOIT from external user management systems. Passwords are therefore not stored in the ADOIT database or elsewhere in ADOIT, and are not known within ADOIT, when using external user management systems.