1.4.5.9.1.4. Tabbed page "Login"

On the tabbed page for "Login [Login] ", you'll find four subpages:

"Login" tab

"Login" tab

1.4.5.9.1.4.1.  Web Login Methods

Tabbed page "Login [Login]"

Tabbed page "Login [Login]"

Allowed web login methods:

  1. Create new lines by clicking on the plus button.

  2. Enter a computer or domain name in the Hostname [Host name] column.

  3. Click in a field in the Methods column, open the list field with the options basis, ntlm and openid and activate the desired one.

Example:

Windows only (ntlm) Authentication

Windows only (ntlm) Authentication

Username/Password (basic) and Windows Authentication (ntlm)

Username/Password (basic) and Windows Authentication (ntlm)

1.4.5.9.1.4.2.  Client Login Methods

Tabbed page "Login [Login]"

Tabbed page "Login [Login]"

Allowed client login methods:

  1. Create new lines by clicking on the plus button.

  2. Enter a domain (e.g., "CNS") or a hostname (e.g., DE-AGB-NAME-01) in the "Rule [Rule] " column using free-form input.

  3. Click in the Databases column on a field, open the drop-down list containing the options WINDOWS, ERP, OPENIDC, SQL, FILE, and LDAP, and select the desired options.

    The options listed here are configured under the " Permissions Management [Rights administration]" category.

1.4.5.9.1.4.3.  OpenID Provider

Advanced OpenID Authentication

The extensions are now available via a graphical user interface. This eliminates the need to manually edit configuration files.

Enable Basic Authentication without a server request (Insecure) [Enable Basic Authentication without a server request (Insecure)]: If this option is enabled, the username and password are transmitted in plain text.

Login Provider: For AppServer solutions, there is exactly one OpenID provider, which is configured here. This is the OpenID provider that is displayed during the 3Dfindit login.

In addition to the regular login provider [Login Provider], you can configure as many additional OpenID providers [OpenID Provider] as you like by clicking the + button. This allows for the parallel support of various identity sources, which is particularly important for integrations and automation scenarios.

The configuration includes the following settings:

  • Issuer

  • ClientId

  • CientSecret

  • Scopes

  • UserNameClaim

  • MandatoryGroups

  • RolesAsPermission: Setting to use when roles are included in the API token

  • Session-Based User

  • MergeUserInfo

This way, you can configure additional providers regardless of the settings under Rights Management [Rights administration] > User Databases [User databases] > OpenID.

1.4.5.9.1.4.4.  API tokens

AppServer Service > Tabbed page "Login" > "API Tokens [API tokens]" Tabbed page

AppServer Service > Tabbed page "Login" > "API Tokens [API tokens]" Tabbed page

API Token Authentication for easy and secure Web API access

Overview

To support automated access to the server API, an API token mechanism was introduced. The goal is to enable scripts and integrations to authenticate securely without having to use user passwords directly. In addition, the authentication infrastructure has been expanded so that multiple OpenID providers can be configured in parallel. Another advantage of a separate API token is that the API key can be easily deleted without compromising the user in question.

API Tokens for Automated Access

API tokens serve as the recommended authentication method for script-driven REST API access. They are associated with an existing user account and inherit that account's permissions. This allows automated applications to access the API on behalf of a user without knowing or storing the user’s password.

Unlike Basic Authentication, in which the username and password are transmitted, API tokens can be managed independently of the user's password. If a token is compromised, it can be revoked and regenerated without requiring any changes to the user's account.

Security Plan

An API token consists of a public token ID and a secret [Secret].

AppServer Service > "Login" Tabbed page

AppServer Service > "Login" Tabbed page

Use the " Random " button to generate an ID and a secret.

Be sure to enter a user. All users who are listed under " Permissions Management [Rights administration] " can be entered here.

In addition, API tokens can optionally be restricted, for example, to:

  • specific IP address ranges

  • defined user agents

These restrictions reduce the risk of abuse and enable controlled use of automated access.

Copy the ID, Secret, and the remaining settings to the clipboard using the "Copy [Copy]" button.

The secret [Secret] is displayed only during creation and cannot be read afterward. This prevents access data from being disclosed later.

[Note]Note

Make sure to save the ApiToken string before closing the dialog box.

After clicking OK, the entry is saved.

"Secret" is no longer displayed.

"Secret" is no longer displayed.

Advanced OpenID Authentication

The extensions are now available via a graphical user interface. This eliminates the need to manually edit configuration files.

Enable Basic Authentication without a server request (Insecure) [Enable Basic Authentication without a server request (Insecure)]: If this option is enabled, the username and password are transmitted in plain text.

Login Provider: For AppServer solutions, there is exactly one OpenID provider, which is configured here. This is the OpenID provider that is displayed during the 3Dfindit login.

In addition to the regular login provider [Login Provider], you can configure as many additional OpenID providers [OpenID Provider] as you like by clicking the + button. This allows for the simultaneous support of various identity sources, which is particularly important for integrations and automation scenarios.

The configuration includes the following settings:

  • Issuer

  • ClientId

  • CientSecret

  • Scopes

  • UserNameClaim

  • MandatoryGroups

  • RolesAsPermission: Setting for when roles are included in the API token

  • Session-Based User

  • MergeUserInfo

This way, you can configure additional providers regardless of the settings under Permissions Management [Rights administration] > User Databases [User databases] > OpenID.

1.4.5.9.1.4.5. Requirements for Windows authentication
  1. Service runs as a local system and does not require access to network shares (requires access to network shares via UNC path)

    Standard configuration from Microsoft for Windows authentication (Kerberos) works. Only the computer name must be added to the Local Intranet Zone in the browser settings of the clients.

  2. Service requires access to external network shares. It must then run as a service user and the SPN entry (Service Principal Name) must be set correctly in the AD. And the computer name must be included in the Local Intranet Zone in the browser settings of the clients.

    Examples:

    setspn -S HTTP/servername.domain.name DOMAIN\serviceuser