Authentifizierung

Jeder Zugriff auf die Applikation, sowohl in der Benutzeroberfläche als auch über Schnittstellen (Metadata REST/API, Metadata Upload/Download), muss authentifiziert werden, um die Identität des Benutzers zu verifizieren.

💡 Tooltipp
Jeder Benutzer kann in einem oder in mehreren Mandanten (mit unterschiedlichen Zugriffsstufen) definiert sein, d.h. die Benutzerkennung existiert in mehreren Mandanten und der Benutzer kann sich mit einem dieser Mandanten anmelden bzw. in der Benutzeroberfläche einen bestimmten Mandanten auswählen.

Für jeden Benutzer kann optional festgelegt werden, dass der Benutzer standardmäßig in einem bestimmten Mandanten angemeldet wird, falls die Benutzerkennung in mehreren Mandanten existiert.

Im Wesentlichen werden bei einer Authentifizierung folgende Schritte durchgeführt:

• Die Zugangsdaten (z.B. Benutzerkennung und Passwort) werden entsprechend der Authentifizierungsmethode ermittelt und gegebenenfalls verifiziert.
• Falls ein Access Key gesetzt ist, wird der Benutzer anhand des Access Keys direkt identifiziert.
• Anderenfalls wird der Benutzer anhand der Zugangsdaten zugeordnet.

🛈 Hinweis
In den nachfolgenden Beispielen werden zur Veranschaulichung die Datenbank test und der Server https://www.myserver.com verwendet (z.B. im Pfad https://www.myserver.com/api/test). Diese Datenbank bzw. dieser Server ist in allen echten Aufrufen entsprechend zu ersetzen. Je nach Konfiguration muss die URL gegebenenfalls auch noch um den Context-Path erweitert werden (z.B. https://www.myserver.com/dataspot/api/test).

What's new?

Folgende Änderungen an der Konfiguration sind zu beachten:

Release	Beschreibung
2026.1	Bei der Authentifizierung mit Benutzerkennung und Passwort (Basic Authentication) werden neue Passwörter mit einem einmaligen, zufälligen Salt und einem optionalen, geheimen Pepper gehasht. Der optionale Server-Parameter DATASPOT_PEPPER_STORE enthält die Liste der Pepper-Werte, die für das Hashing von Passwörtern verwendet werden.
2026.1	Bei den Authentifizierungsmethoden Single Sign-On (Pre-Authentication) und OpenID Connect (Bearer Authentication) definiert der optionale Server-Parameter DATASPOT_OIDC_JWT_TENANT_ID den Namen vom Claim im JSON Web Token (JWT), der die vom Identity Provider bereitgestellte Tenant-ID des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet).
2026.1	Bei der Authentifizierungsmethode Single Sign-On (Pre-Authentication) definiert der optionale Server-Parameter DATASPOT_REMOTE_USER_TENANT_ID den Namen des HTTP-Header Attributs, welches die vom Identity Provider bereitgestellte Tenant-ID des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet).
2026.1	Bei der Authentifizierungsmethode Same Sign-In (Directory Service/LDAP) definiert der optionale Server-Parameter DATASPOT_JNDI_TENANT_ID den Namen des JNDI Attributs, welches die vom Identity Provider bereitgestellte Tenant-ID des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet).
2025.1	Beim Aufruf einer Schnittstelle kann ein Access Key verwendet werden, um einen Benutzer bzw. Service User zu identifizieren.
4.6	Bei den Authentifizierungsmethoden Single Sign-On (Pre-Authentication) und OpenID Connect (Bearer Authentication) definieren die optionalen Server-Parameter DATASPOT_OIDC_JWT_FAMILY_NAME und DATASPOT_OIDC_JWT_GIVEN_NAME die Namen der Claims im JSON Web Token (JWT), die den Nachnamen und Vornamen des Benutzer enthalten (werden bei der Auswertung der Zugriffsregeln verwendet).
4.6	Zugriffsregeln erlauben die Anmeldung als Gast (nur lesend) ohne Benutzer oder sogar die automatische Anlage von Personen und Benutzern mit festgelegten Zugriffsstufen. Die Auswertung der Zugriffsregeln wird mit dem Server-Parameter DATASPOT_ACCESS_RULES (vormals DATASPOT_GUEST_USERS) aktiviert.
4.6	Bei der Authentifizierungsmethode Single Sign-On (Pre-Authentication) definiert der optionale Server-Parameter DATASPOT_REMOTE_USER_GROUP_ID den Namen des HTTP-Header Attributs, welches die vom Identity Provider bereitgestellten Gruppen-IDs des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet). Bei der Authentifizierungsmethode Same Sign-In (Directory Service/LDAP) definiert der optionale Server-Parameter DATASPOT_JNDI_GROUP_ID den Namen des JNDI Attributs, welches die vom Identity Provider bereitgestellten Gruppen-IDs des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet).
4.5	Bei den Authentifizierungsmethoden Single Sign-On (Pre-Authentication) und OpenID Connect (Bearer Authentication) definiert der optionale Server-Parameter DATASPOT_OIDC_JWT_GROUP_ID den Namen vom Claim im JSON Web Token (JWT), der die vom Identity Provider bereitgestellten Gruppen-IDs des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet).
4.4	Bei den Authentifizierungsmethoden Single Sign-On (Pre-Authentication) und OpenID Connect (Bearer Authentication) definiert der optionale Server-Parameter DATASPOT_OIDC_JWT_SUB_ID den Namen vom Claim im JSON Web Token (JWT), der den Subject Identifier des Benutzers enthält.

Authentifizierungsmethoden

Folgende Authentifizierungsmethoden zur Bestimmung der Zugangsdaten werden unterstützt:

• Benutzerkennung und Passwort (Basic Authentication)
• Single Sign-On (Pre-Authentication)
• Same Sign-In (Directory Service/LDAP)
• OpenID Connect (Bearer Authentication)

Benutzerkennung und Passwort (Basic Authentication)

Die Zugangsdaten werden mittels Basic Authentication im HTTP-Header Attribut Authorization übertragen.

Bei dieser Authentifizierungsmethode wird in der Benutzeroberfläche ein Dialog zur Anmeldung (mit Benutzerkennung und Passwort) angezeigt. Die Benutzerkennung und das Passwort werden durch : getrennt und in Base64 kodiert und im HTTP-Header Attribut Authorization an den Server geschickt.

💡 Tooltipp
Wenn ein externes System eine Schnittstelle (Metadata REST/API, Metadata Upload/Download) aufruft, muss das externe System die Zugangsdaten im HTTP-Header Attribut Authorization bereitstellen.

Am Server werden die Benutzerkennung und das Passwort dem HTTP-Header Attribut Authorization entnommen. Zur Verifizierung des übertragenen Passworts wird das Passwort des zugeordneten Benutzers herangezogen. Bei dieser Authentifizierungsmethode werden die Passwörter in der Applikation verwaltet.

⚠️ Achtung
Bei dieser Authentifizierungsmethode wird die Anmeldung als Gast (nur lesend) ohne Benutzer nicht unterstützt, unabhängig davon, ob Zugriffsregeln aktiviert sind oder nicht. Falls die Benutzerkennung keinem Benutzer im Login-Mandanten zugeordnet werden kann, dann wird der Zugriff verweigert.

Konfiguration

Die Konfiguration erfolgt über folgende Server-Parameter:

Parameter	Beschreibung
DATASPOT_PEPPER_STORE	Liste der Pepper-Werte, die für das Hashing von Passwörtern verwendet werden. Die Werte werden im Format <pid>=<value>;<pid>=<value>;... angegeben. - example: pid2=mRHQiprk0S3JySeF;pid1=LnVT6FEkhuVQTU3J
DATASPOT_ACCESS_RULES DATASPOT_GUEST_USERS(deprecated)	Aktiviert/Deaktiviert Zugriffsregeln [true,false] - default: true

⚠️ Achtung
Der Pepper-Store DATASPOT_PEPPER_STORE enthält als ersten Eintrag den aktuell aktiven Pepper-Wert, der zum Hashing neuer Passwörter verwendet wird. Die restlichen Einträge sind alle zuvor aktiven Pepper-Werte, die zur Überprüfung der mit ihnen gehashten Passwörter notwendig sind. Jeder Pepper-Wert wird durch eine eindeutige Pepper-ID identifiziert.

Um den aktiven Pepper-Wert zu ändern, wird ein neuer Wert als <pid>=<value> am Anfang der Liste hinzugefügt, ohne die bisherigen Pepper-Werte zu entfernen oder zu ändern, um mit bestehenden Passwörtern kompatibel zu bleiben. Wenn ein Pepper-Wert geändert oder aus dem Pepper-Store entfernt wird, können Passwörter, die mit diesem Pepper-Wert gehasht wurden, nicht mehr verifiziert werden.

🛈 Hinweis
Mit dem Open-Source Tool OpenSSL können sichere Pepper-Werte (z.B. 24 Byte) folgendermaßen generiert werden:

openssl rand -base64 24

In Java können sichere Pepper-Werte (z.B. 24 Byte) folgendermaßen generiert werden:

var bytes = new byte[24];
new java.security.SecureRandom().nextBytes(bytes);
System.out.println(java.util.Base64.getEncoder().encodeToString(bytes));

🛈 Hinweis
Falls keine andere Authentifizierungsmethode aktiviert ist, dann wird die Authentifizierung mit Benutzerkennung und Passwort (Basic Authentication) automatisch ausgewählt.

Beispiel: Benutzerkennung und Passwort (Basic Authentication)

Die Benutzerkennung myuser und das Passwort s3cr3t werden zu myuser:s3cr3t zusammengefügt, in Base64 als bXl1c2VyOnMzY3IzdA== kodiert und im HTTP-Header Attribut Authorization an den Server geschickt:

Authorization: Basic bXl1c2VyOnMzY3IzdA==

💡 Tooltipp
Beim Aufruf mit dem Open-Source Tool curl können die Zugangsdaten folgendermaßen gesetzt werden:

curl -u "myuser:s3cr3t" https://www.myserver.com/dataspot/rest/test/schemes
curl -H "Authorization: Basic bXl1c2VyOnMzY3IzdA==" https://www.myserver.com/dataspot/rest/test/schemes

Am Server werden die Benutzerkennung myuser und das Passwort s3cr3t dem HTTP-Header Attribut Authorization entnommen.

• Das Passwort s3cr3t wird mit dem Passwort des zugeordneten Benutzers verglichen.

🛈 Hinweis
In der Applikation werden Passwörter nicht als Klartext sondern verschlüsselt gespeichert.

Single Sign-On (Pre-Authentication)

Die Zugangsdaten werden mittels kundenspezifischer HTTP-Header Attribute übertragen. Die Pre-Authentifizierung überprüft die Identität des Benutzers vollständig außerhalb der Applikation.

🛈 Hinweis
Typischerweise erfolgt die Pre-Authentifizierung am Reverse-Proxy, der neben der Anbindung über https auch die Authentifizierung durchführt und die konfigurierten HTTP-Header Attribute setzt.

Bei dieser Authentifizierungsmethode wird in der Benutzeroberfläche kein Dialog zur Anmeldung angezeigt. Es werden keine Zugangsdaten vom Browser an den Server übertragen. Die Authentifizierung findet in einem externen System zwischen Browser und Server (z.B. am Reverse-Proxy) statt, wo die konfigurierten HTTP-Header Attribute gesetzt werden.

💡 Tooltipp
Wenn ein externes System eine Schnittstelle (Metadata REST/API, Metadata Upload/Download) aufruft, muss das externe System die Zugangsdaten in den kundenspezifischen HTTP-Header Attributen bereitstellen.

Am Server wird die Benutzerkennung dem konfigurierten HTTP-Header Attribut entnommen. Es findet keine weitere Verifizierung der Zugangsdaten (z.B. Passwort) statt. Bei dieser Authentifizierungsmethode werden keine Passwörter in der Applikation verwaltet.

⚠️ Achtung
Durch das Aktivieren der Pre-Authentifizierung und das Setzen der entsprechenden HTTP-Header Attribute wird die reguläre Authentifizierung übergangen. Deshalb ist grundsätzlich bei der Konfiguration von Pre-Authentifizierung im Netzwerk darauf zu achten, dass keine unberechtigten Systeme in der Lage sind, Requests gegen den Server mit gesetzten Header-Attributen abzusetzen.

Eine zusätzliche Sicherheitsstufe kann mit der Konfiguration eines API-KEY Token eingeführt werden. Falls DATASPOT_API_KEY_TOKEN definiert ist, dann werden nur Aufrufe authentifiziert, die das konfigurierte HTTP-Header Attribut (siehe DATASPOT_API_KEY) mit dem API-KEY Token (siehe DATASPOT_API_KEY_TOKEN) enthalten.

⚠️ Achtung
Ab Version 4.1 ist es bei aktivierter Pre-Authentifizierung nicht mehr möglich, Schnittstellen mit Benutzerkennung und Passwort (Basic Authentication) aufzurufen.

Konfiguration

Die Konfiguration erfolgt über folgende Server-Parameter:

Parameter	Beschreibung
DATASPOT_PRE_AUTHENTICATION	Aktiviert/Deaktiviert Pre-Authentifizierung [true,false] - default: false
DATASPOT_REMOTE_USER_ID DATASPOT_REMOTE_USER(deprecated)	Name des HTTP-Header Attributs, welches die Benutzerkennung des Benutzers enthält
DATASPOT_REMOTE_USER_GROUP_ID	Name des HTTP-Header Attributs, welches die vom Identity Provider bereitgestellten Gruppen-IDs (durch Beistriche getrennt) des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional
DATASPOT_REMOTE_USER_TENANT_ID	Name des HTTP-Header Attributs, welches die vom Identity Provider bereitgestellte Tenant-ID des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional
DATASPOT_REMOTE_USER_FAMILY_NAME	Name des HTTP-Header Attributs, welches den Nachnamen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional
DATASPOT_REMOTE_USER_GIVEN_NAME	Name des HTTP-Header Attributs, welches den Vornamen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional
DATASPOT_REMOTE_USER_TENANT_NAME	Name des HTTP-Header Attributs, welches den Default-Mandanten übersteuert - optional; default: Der Default-Mandant bleibt unverändert
DATASPOT_REMOTE_USER_OIDC_JWT	Name des HTTP-Header Attributs, welches ein JSON Web Token (JWT) enthält - optional
DATASPOT_OIDC_JWT_SUB_ID	Name vom Claim im JSON Web Token (JWT) (siehe DATASPOT_REMOTE_USER_OIDC_JWT), der den Subject Identifier des Benutzers enthält - optional
DATASPOT_OIDC_JWT_GROUP_ID	Name vom Claim im JSON Web Token (JWT) (siehe DATASPOT_REMOTE_USER_OIDC_JWT), der die vom Identity Provider bereitgestellten Gruppen-IDs des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet). Wird nur gelesen, falls das HTTP-Header Attribut DATASPOT_REMOTE_USER_GROUP_ID keinen Wert enthält. - optional
DATASPOT_OIDC_JWT_TENANT_ID	Name vom Claim im JSON Web Token (JWT) (siehe DATASPOT_REMOTE_USER_OIDC_JWT), der die vom Identity Provider bereitgestellte Tenant-ID des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet). Wird nur gelesen, falls das HTTP-Header Attribut DATASPOT_REMOTE_USER_TENANT_ID keinen Wert enthält. - optional
DATASPOT_OIDC_JWT_CLIENT_ID	Name vom Claim im JSON Web Token (JWT) (siehe DATASPOT_REMOTE_USER_OIDC_JWT), der die OpenID Connect Client-ID enthält - default: aud
DATASPOT_OIDC_JWT_USER_NAME	Name vom Claim im JSON Web Token (JWT) (siehe DATASPOT_REMOTE_USER_OIDC_JWT), der den Namen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet). Wird nur gelesen, falls die HTTP-Header Attribute DATASPOT_REMOTE_USER_FAMILY_NAME bzw. DATASPOT_REMOTE_USER_GIVEN_NAME keine Werte enthalten. - optional
DATASPOT_OIDC_JWT_FAMILY_NAME	Name vom Claim im JSON Web Token (JWT) (siehe DATASPOT_REMOTE_USER_OIDC_JWT), der den Nachnamen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet). Wird nur gelesen, falls das HTTP-Header Attribut DATASPOT_REMOTE_USER_FAMILY_NAME keinen Wert enthält. - optional
DATASPOT_OIDC_JWT_GIVEN_NAME	Name vom Claim im JSON Web Token (JWT) (siehe DATASPOT_REMOTE_USER_OIDC_JWT), der den Vornamen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet). Wird nur gelesen, falls das HTTP-Header Attribut DATASPOT_REMOTE_USER_GIVEN_NAME keinen Wert enthält. - optional
DATASPOT_OIDC_JWT_TENANT_NAME	Name vom Claim im JSON Web Token (JWT) (siehe DATASPOT_REMOTE_USER_OIDC_JWT), der den Default-Mandanten übersteuert. Wird nur gelesen, falls das HTTP-Header Attribut DATASPOT_REMOTE_USER_TENANT_NAME keinen Wert enthält. - optional
DATASPOT_API_KEY	Name des HTTP-Header Attributs, welches das API-KEY Token enthält (siehe DATASPOT_API_KEY_TOKEN) - optional
DATASPOT_API_KEY_TOKEN	API-KEY Token - optional
DATASPOT_ACCESS_RULES DATASPOT_GUEST_USERS(deprecated)	Aktiviert/Deaktiviert Zugriffsregeln [true,false] - default: true
DATASPOT_ADMIN_USER	Liste der Benutzerkennungen (durch ; getrennt) aller Benutzer, die als System-Administratoren tätig sein dürfen - optional
DATASPOT_LOGOUT_URL	URL, die durch Klick auf Abmelden im Benutzer-Menü geöffnet wird. Vor dem Öffnen wird der optionale Platzhalter ${POST_LOGOUT_REDIRECT_URL} durch die URL zur aktuellen Datenbank (z.B. https://www.myserver.com/web/test) ersetzt. - optional - example: /.auth/logout?post_logout_redirect_uri=${POST_LOGOUT_REDIRECT_URL} - example: https://www.myserver.com/

⚠️ Achtung
Das optionale JSON Web Token (JWT) (siehe DATASPOT_REMOTE_USER_OIDC_JWT) kann zusätzliche Informationen über den Benutzer enthalten. Da die Authentifizierung nicht explizit als OpenID Connect (Bearer Authentication) konfiguriert ist, wird die Signatur des JWT nicht verifiziert, da dafür eine Verbindung zum Aussteller erforderlich wäre, um den entsprechenden JSON Web Key (JWK) aus dem öffentlichen JSON Web Key Set (JWKS) zu ermitteln. Stattdessen wird davon ausgegangen, dass das JWT von einem Authentifizierungsmodul (z.B. Azure Easy Auth) korrekt ausgestellt, signiert und in den HTTP-Header injiziert wurde.

💡 Tooltipp
Die vom Identity Provider bereitgestellten Gruppen-IDs des Benutzers (siehe DATASPOT_REMOTE_USER_GROUP_ID und DATASPOT_OIDC_JWT_GROUP_ID) können verwendet werden, um entsprechende Zugriffsregeln zu definieren (z.B. der Benutzer wird automatisch mit der Zugriffsstufe Editor angelegt, wenn er Mitglied einer bestimmten Gruppe ist).

💡 Tooltipp
Die vom Identity Provider bereitgestellte Tenant-ID des Benutzers (siehe DATASPOT_REMOTE_USER_TENANT_ID und DATASPOT_OIDC_JWT_TENANT_ID) kann verwendet werden, um entsprechende Zugriffsregeln zu definieren (z.B. alle Benutzer mit einer bestimmten Tenant-ID werden automatisch als Gast angemeldet).

🛈 Hinweis
Bei aktivierter Pre-Authentifizierung wird der Eintrag Abmelden im Benutzer-Menü nur angezeigt, falls der Server-Parameter DATASPOT_LOGOUT_URL definiert ist.

Beispiel: Single Sign-On (Pre-Authentication)

DATASPOT_PRE_AUTHENTICATION=true
DATASPOT_REMOTE_USER_ID=dataspot-user-id
DATASPOT_REMOTE_USER_FAMILY_NAME=dataspot-user-family-name
DATASPOT_REMOTE_USER_GIVEN_NAME=dataspot-user-given-name
DATASPOT_REMOTE_USER_TENANT_NAME=dataspot-user-tenant-name
DATASPOT_REMOTE_USER_OIDC_JWT=X-MS-TOKEN-AAD-ID-TOKEN
DATASPOT_OIDC_JWT_USER_NAME=name
DATASPOT_OIDC_JWT_TENANT_NAME=tenant
DATASPOT_ADMIN_USER=mmustermann;jdoe

Die Authentifizierung findet in einem externen System zwischen Browser und Server (z.B. am Reverse-Proxy) statt, wo die Benutzerkennung myuser in das HTTP-Header Attribut dataspot-user-id geschrieben wird:

dataspot-user-id: myuser

💡 Tooltipp
Beim Aufruf mit dem Open-Source Tool curl können die Zugangsdaten folgendermaßen gesetzt werden:

curl -H "dataspot-user-id: myuser" https://www.myserver.com/dataspot/rest/test/schemes

Am Server wird die Benutzerkennung myuser dem HTTP-Header Attribut dataspot-user-id entnommen.

• Der Default-Mandant kann mit dem HTTP-Header Attribut dataspot-user-tenant-name übersteuert werden. Alternativ wird das JSON Web Token (JWT) aus dem HTTP-Header Attribut X-MS-TOKEN-AAD-ID-TOKEN gelesen und der Default-Mandant kann dem Claim tenant entnommen werden.
• Der Name des Benutzers kann gegebenenfalls den HTTP-Header Attributen dataspot-user-family-name und dataspot-user-given-name entnommen werden. Alternativ wird das JSON Web Token (JWT) aus dem HTTP-Header Attribut X-MS-TOKEN-AAD-ID-TOKEN gelesen und der Name des Benutzers kann dem Claim name entnommen werden.

Ein Benutzer, dessen Benutzerkennung in der Liste mmustermann;jdoe vorkommt, erhält darüber hinaus Zugriff auf alle Mandanten mit zusätzlicher Berechtigung als System-Administrator.

Beispiel: API-KEY Token

DATASPOT_PRE_AUTHENTICATION=true
DATASPOT_REMOTE_USER_ID=dataspot-user-id
DATASPOT_API_KEY=dataspot-api-key
DATASPOT_API_KEY_TOKEN=s3cr3t

Die Authentifizierung findet in einem externen System zwischen Browser und Server (z.B. am Reverse-Proxy) statt, wo die Benutzerkennung myuser in das HTTP-Header Attribut dataspot-user-id und das API-KEY Token s3cr3t in das HTTP-Header Attribut dataspot-api-key gesetzt wird:

dataspot-user-id: myuser
dataspot-api-key: s3cr3t

Am Server wird die Benutzerkennung myuser dem HTTP-Header Attribut dataspot-user-id entnommen.

• Der Aufruf wird nur authentifiziert, falls das HTTP-Header Attribut dataspot-api-key den Wert s3cr3t enthält.

Beispiel: Apache HTTP-Server mit LDAP Modul

Das folgende Beispiel zeigt, wie mithilfe des Apache HTTP-Servers ein vorgeschalteter Reverse-Proxy konfiguriert werden kann, der folgende zusätzliche Funktionalitäten ermöglicht:

• SSL-Anbindung (über https)
• Single Sign-On (der Benutzer muss sich nur einmal gegenüber dem Reverse-Proxy authentifizieren)

Das Beispiel soll nur das grundsätzliche Prinzip der LDAP-Anbindung zeigen. Weitergehende Konfigurationen können gemäß der Dokumentation zu den Apache Modulen durchgeführt werden:

• mod_authnz_ldap
• mod_auth_basic

<VirtualHost *:443>
  ServerName dataspot.example.com
  SSLEngine on

  # Certificate configuration
  SSLCertificateKeyFile /etc/ssl.key/example.com.key
  SSLCertificateFile /etc/ssl.crt/example.com.crt

  # Enable rewrite engine
  RewriteEngine On

  <Location "/dataspot">
    ProxyPass http://localhost:8080
    ProxyPassReverse http://localhost:8080
    Require all granted

    AuthName "My Company"
    AuthBasicProvider ldap
    AuthType Basic

    AuthLDAPURL ldap://ldap.example.com/o=Example?uid

    Require valid-user
    Require ldap-group cn=Users, o=Example

    # Do not rewrite sub requests
    RewriteCond %{IS_SUBREQ} ^false$

    # store the value of the environment variable REMOTE_USER into the variable RU (look-ahead)
    RewriteCond %{LA-U:REMOTE_USER} (.+)
    RewriteRule .* - [E=RU:%1]

    # add the value of the variable RU to the request headers
    RequestHeader set X-AUTHENTICATED-USER %{RU}e

    # clear the Authorization header
    RequestHeader unset Authorization
  </Location>
</VirtualHost>

Same Sign-In (Directory Service/LDAP)

Die Zugangsdaten werden mittels Basic Authentication im HTTP-Header Attribut Authorization übertragen und in einem externen Verzeichnisdienst (Directory Service) authentifiziert.

Bei dieser Authentifizierungsmethode wird in der Benutzeroberfläche ein Dialog zur Anmeldung (mit Benutzerkennung und Passwort) angezeigt. Die Benutzerkennung und das Passwort werden durch : getrennt und in Base64 kodiert und im HTTP-Header Attribut Authorization an den Server geschickt.

💡 Tooltipp
Wenn ein externes System eine Schnittstelle (Metadata REST/API, Metadata Upload/Download) aufruft, muss das externe System die Zugangsdaten im HTTP-Header Attribut Authorization bereitstellen.

Am Server werden die Benutzerkennung und das Passwort dem HTTP-Header Attribut Authorization entnommen. Zur Verifizierung des Passworts wird über JNDI (Java Naming and Directory Interface) ein externer Verzeichnisdienst herangezogen. Bei dieser Authentifizierungsmethode werden keine Passwörter in der Applikation verwaltet.

🛈 Hinweis
Obwohl typischerweise LDAP (Lightweight Directory Access Protocol) zur Authentifizierung verwendet wird, können prinzipiell alle Verzeichnisdienste, die JNDI unterstützen, für die Authentifizierung verwendet werden.

Die Verifizierung der Benutzerkennung und des Passworts aus den Zugangsdaten ist mit JNDI (Java Naming and Directory Interface) implementiert, wie folgt:

• Der Verzeichnisdienst (siehe DATASPOT_JNDI_FACTORY und DATASPOT_JNDI_URL) wird mit dem Benutzer (siehe DATASPOT_JNDI_USER) und dem Passwort (siehe DATASPOT_JNDI_PASSWORD) kontaktiert. Dieser Benutzer muss die Berechtigung haben, im Verzeichnisdienst nach Objekten zu suchen.
• Im Kontext (siehe DATASPOT_JNDI_CONTEXT) wird unter Verwendung der Filter-Expression (siehe DATASPOT_JNDI_FILTER) nach einem Objekt mit der Benutzerkennung aus den Zugangsdaten gesucht. Der Platzhalter {0} in der Filter-Expression wird durch die Benutzerkennung ersetzt.
• Falls ein Objekt mit der Benutzerkennung gefunden wird, dann wird der Verzeichnisdienst mit diesem Objekt und dem Passwort aus den Zugangsdaten erneut kontaktiert, um das Passwort zu verifizieren.

Konfiguration

Die Konfiguration erfolgt über folgende Server-Parameter:

Parameter	Beschreibung
DATASPOT_JNDI_AUTHENTICATION	Aktiviert/Deaktiviert JNDI-Authentifizierung [true,false] - default: false
DATASPOT_JNDI_FACTORY	Initial Context Factory - default: com.sun.jndi.ldap.LdapCtxFactory (LDAP)
DATASPOT_JNDI_URL	URL vom Verzeichnisdienst - example: ldaps://ldap.example.com
DATASPOT_JNDI_USER	Benutzer, der die Berechtigung hat, im Verzeichnisdienst nach Objekten zu suchen - example: uid=admin,ou=administrators,dc=example,dc=com
DATASPOT_JNDI_PASSWORD	Passwort (siehe DATASPOT_JNDI_USER)
DATASPOT_JNDI_CONTEXT	Kontext, in dem nach Objekten gesucht wird - optional; example: ou=users,dc=example,dc=com
DATASPOT_JNDI_FILTER	Filter-Expression für die Abfrage des Objekts (der Platzhalter {0} wird durch die Benutzerkennung aus den Zugangsdaten ersetzt) - default: uid={0} - example: samaccountname={0} (Active Directory)
DATASPOT_JNDI_GROUP_ID	Name des JNDI Attributs, welches die vom Identity Provider bereitgestellten Gruppen-IDs des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional; example: groups
DATASPOT_JNDI_TENANT_ID	Name des JNDI Attributs, welches die vom Identity Provider bereitgestellte Tenant-ID des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional; example: tenant
DATASPOT_JNDI_COMMON_NAME	Name des JNDI Attributs, welches den Namen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional; example: cn
DATASPOT_JNDI_FAMILY_NAME	Name des JNDI Attributs, welches den Nachnamen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional; example: sn
DATASPOT_JNDI_GIVEN_NAME	Name des JNDI Attributs, welches den Vornamen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional; example: givenName
DATASPOT_JNDI_TENANT_NAME	Name des JNDI Attributs, welches den Default-Mandanten übersteuert - optional; default: Der Default-Mandant bleibt unverändert
DATASPOT_ACCESS_RULES DATASPOT_GUEST_USERS(deprecated)	Aktiviert/Deaktiviert Zugriffsregeln [true,false] - default: true

💡 Tooltipp
Für LDAP kann das Kommandozeilenprogramm ldapsearch verwendet werden, um die entsprechende Filter-Expression zu bestimmen und zu testen.

💡 Tooltipp
Die vom Identity Provider bereitgestellten Gruppen-IDs des Benutzers (siehe DATASPOT_JNDI_GROUP_ID) können verwendet werden, um entsprechende Zugriffsregeln zu definieren (z.B. der Benutzer wird automatisch mit der Zugriffsstufe Editor angelegt, wenn er Mitglied einer bestimmten Gruppe ist).

💡 Tooltipp
Die vom Identity Provider bereitgestellte Tenant-ID des Benutzers (siehe DATASPOT_JNDI_TENANT_ID) kann verwendet werden, um entsprechende Zugriffsregeln zu definieren (z.B. alle Benutzer mit einer bestimmten Tenant-ID werden automatisch als Gast angemeldet).

Beispiel: Same Sign-In (Directory Service/LDAP)

DATASPOT_JNDI_AUTHENTICATION=true
DATASPOT_JNDI_URL=ldap://ldap.example.com
DATASPOT_JNDI_USER=cn=admin,dc=example,dc=com
DATASPOT_JNDI_PASSWORD=pa$$word
DATASPOT_JNDI_CONTEXT=ou=users,dc=example,dc=com
DATASPOT_JNDI_FILTER=uid={0}
DATASPOT_JNDI_COMMON_NAME=cn
DATASPOT_JNDI_TENANT_NAME=group

Die Benutzerkennung myuser und das Passwort s3cr3t werden zu myuser:s3cr3t zusammengefügt, in Base64 als bXl1c2VyOnMzY3IzdA== kodiert und im HTTP-Header Attribut Authorization an den Server geschickt:

Authorization: Basic bXl1c2VyOnMzY3IzdA==

💡 Tooltipp
Beim Aufruf mit dem Open-Source Tool curl können die Zugangsdaten folgendermaßen gesetzt werden:

curl -u "myuser:s3cr3t" https://www.myserver.com/dataspot/rest/test/schemes
curl -H "Authorization: Basic bXl1c2VyOnMzY3IzdA==" https://www.myserver.com/dataspot/rest/test/schemes

Am Server werden die Benutzerkennung myuser und das Passwort s3cr3t dem HTTP-Header Attribut Authorization entnommen und in LDAP authentifiziert.

Der Verzeichnisdienst LDAP wird unter der URL ldap://ldap.example.com mit dem Benutzer cn=admin,dc=example,dc=com und dem Passwort pa$$word kontaktiert. Ein Objekt mit der Benutzerkennung myuser wird im Context ou=users,dc=example,dc=com mit dem Filter uid={0} gesucht.

• Der Default-Mandant kann mit dem LDAP-Attribut group des gefundenen Objekts übersteuert werden.
• Der Name des Benutzers kann gegebenenfalls dem LDAP-Attribut cn des gefundenen Objekts entnommen werden.
• Der Verzeichnisdienst wird mit dem gefundenen Objekt und dem Passwort s3cr3t erneut kontaktiert, um das Passwort zu verifizieren.

🛈 Hinweis
LDAP Unauthenticated Authentication (mit leerem Passwort) wird nicht unterstützt.

OpenID Connect (Bearer Authentication)

Die Zugangsdaten werden mittels Bearer Authentication im HTTP-Header Attribut Authorization übertragen.

Bei dieser Authentifizierungsmethode wird in der Benutzeroberfläche ein Dialog zur Anmeldung bei einem externen Identity Provider, z.B. Microsoft Entra ID (vormals Microsoft Azure AD), angezeigt. Die Identität des Benutzers wird mittels OpenID Connect (OIDC) verifiziert. Die Zugangsdaten werden als signiertes JSON Web Token (JWT) in Base64 kodiert und im HTTP-Header Attribut Authorization an den Server geschickt.

💡 Tooltipp
Wenn ein externes System eine Schnittstelle (Metadata REST/API, Metadata Upload/Download) aufruft, muss das externe System die Zugangsdaten als signiertes JSON Web Token (JWT) im HTTP-Header Attribut Authorization bereitstellen.

Am Server wird die Benutzerkennung dem konfigurierten Claim im signierten JSON Web Token (JWT) aus dem HTTP-Header Attribut Authorization entnommen. Es findet keine weitere Verifizierung der Zugangsdaten (z.B. Passwort) statt. Bei dieser Authentifizierungsmethode werden keine Passwörter in der Applikation verwaltet.

⚠️ Achtung
Aus Sicherheitsgründen muss die OpenID Connect Client-ID (siehe DATASPOT_OIDC_CLIENT_ID) im konfigurierten Claim (siehe DATASPOT_OIDC_JWT_CLIENT_ID) enthalten sein.

Konfiguration

Die Konfiguration erfolgt über folgende Server-Parameter:

Parameter	Beschreibung
DATASPOT_OIDC_AUTHENTICATION	Aktiviert/Deaktiviert OIDC-Authentifizierung [true,false] - default: false
DATASPOT_OIDC_CLIENT_ID	OpenID Connect Client-ID
DATASPOT_OIDC_PROVIDER_NAME	Name vom Identity Provider, der OpenID Connect unterstützt: AzureAD (Microsoft Entra ID, vormals Microsoft Azure AD)
DATASPOT_OIDC_PROVIDER_URL	URL vom Identity Provider, der OpenID Connect unterstützt
DATASPOT_OIDC_JWT_USER_ID	Name vom Claim im JSON Web Token (JWT), der die Benutzerkennung des Benutzers enthält
DATASPOT_OIDC_JWT_SUB_ID	Name vom Claim im JSON Web Token (JWT), der den Subject Identifier des Benutzers enthält - optional
DATASPOT_OIDC_JWT_GROUP_ID	Name vom Claim im JSON Web Token (JWT), der die vom Identity Provider bereitgestellten Gruppen-IDs des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional
DATASPOT_OIDC_JWT_TENANT_ID	Name vom Claim im JSON Web Token (JWT), der die vom Identity Provider bereitgestellte Tenant-ID des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional
DATASPOT_OIDC_JWT_CLIENT_ID	Name vom Claim im JSON Web Token (JWT), der die OpenID Connect Client-ID (siehe DATASPOT_OIDC_CLIENT_ID) enthält - default: aud
DATASPOT_OIDC_JWT_USER_NAME	Name vom Claim im JSON Web Token (JWT), der den Namen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional
DATASPOT_OIDC_JWT_FAMILY_NAME	Name vom Claim im JSON Web Token (JWT), der den Nachnamen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional
DATASPOT_OIDC_JWT_GIVEN_NAME	Name vom Claim im JSON Web Token (JWT), der den Vornamen des Benutzers enthält (wird bei der Auswertung der Zugriffsregeln verwendet) - optional
DATASPOT_OIDC_JWT_TENANT_NAME	Name vom Claim im JSON Web Token (JWT), der den Default-Mandanten übersteuert - optional; default: Der Default-Mandant bleibt unverändert
DATASPOT_ACCESS_RULES DATASPOT_GUEST_USERS(deprecated)	Aktiviert/Deaktiviert Zugriffsregeln [true,false] - default: true
DATASPOT_ADMIN_USER	Liste der Benutzerkennungen (durch ; getrennt) aller Benutzer, die als System-Administratoren tätig sein dürfen - optional

💡 Tooltipp
Die Verwendung von Microsoft Entra ID (vormals Microsoft Azure AD) setzt voraus, dass die Applikation im Azure Portal registriert ist. Die URI https://www.myserver.com/dataspot/web/auth muss zur Liste der akzeptierten Umleitungs-URIs hinzugefügt werden.

⚠️ Achtung
Zur Verifikation der Signatur des JSON Web Token (JWT) muss der passende JSON Web Key (JWK) aus einem öffentlichen JSON Web Key Set (JWKS) geladen werden. Die URI des öffentlichen JSON Web Key Set (JWKS) wird in der OpenID Provider Configuration (siehe Claim iss) bekanntgegeben. Der Server muss daher sowohl Zugriff auf die OpenID Provider Configuration als auch auf das öffentliche JSON Web Key Set (JWKS) haben.

💡 Tooltipp
Die vom Identity Provider bereitgestellten Gruppen-IDs des Benutzers (siehe DATASPOT_OIDC_JWT_GROUP_ID) können verwendet werden, um entsprechende Zugriffsregeln zu definieren (z.B. der Benutzer wird automatisch mit der Zugriffsstufe Editor angelegt, wenn er Mitglied einer bestimmten Gruppe ist).

💡 Tooltipp
Die vom Identity Provider bereitgestellte Tenant-ID des Benutzers (siehe DATASPOT_OIDC_JWT_TENANT_ID) kann verwendet werden, um entsprechende Zugriffsregeln zu definieren (z.B. alle Benutzer mit einer bestimmten Tenant-ID werden automatisch als Gast angemeldet).

Subject Identifier

Der Subject Identifier eines Benutzers ist eine eindeutige und nie neu zugewiesene Kennung, die vom Identity Provider ausgestellt wird.

Falls der optionale Server-Parameter DATASPOT_OIDC_JWT_SUB_ID gesetzt ist, muss der entsprechende Claim im JSON Web Token (JWT) einen Subject Identifier enthalten und mit dem internen Subject Identifier des Benutzers übereinstimmen. Ansonsten wird die Authentifizierung abgelehnt.

🛈 Hinweis
Falls der Benutzer noch keinen internen Subject Identifier hat, wird der Subject Identifier aus dem JSON Web Token (JWT) dem Benutzer zugeordnet (und in nachfolgenden Zugriffen verifiziert). Der interne Subject Identifier des Benutzers kann nachträglich nicht mehr geändert werden.

Beispiel: OpenID Connect (Bearer Authentication)

DATASPOT_OIDC_AUTHENTICATION=true
DATASPOT_OIDC_CLIENT_ID=6731de76-14a6-49ae-97bc-6eba6914391e
DATASPOT_OIDC_PROVIDER_NAME=AzureAD
DATASPOT_OIDC_PROVIDER_URL=https://login.microsoftonline.com/a1ebd953-fb5f-425e-99fc-ec46bf8ce3f0
DATASPOT_OIDC_JWT_CLIENT_ID=aud
DATASPOT_OIDC_JWT_USER_ID=email
DATASPOT_OIDC_JWT_SUB_ID=sub
DATASPOT_OIDC_JWT_USER_NAME=name
DATASPOT_OIDC_JWT_TENANT_NAME=group
DATASPOT_ADMIN_USER=john.smith@mydomain.com;joe.public@mydomain.com

Die Identität eines Benutzers in der Benutzeroberfläche wird mittels OpenID Connect (OIDC) beim externen Identity Provider AzureAD unter der URL https://login.microsoftonline.com/a1ebd953-fb5f-425e-99fc-ec46bf8ce3f0 verifiziert. Die Zugangsdaten werden als signiertes JSON Web Token (JWT) abgebildet, bestehend aus Header und Payload, zum Beispiel:

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "iss": "https://sts.windows.net/a1ebd953-fb5f-425e-99fc-ec46bf8ce3f0/",
  "sub": "123456",
  "aud": "6731de76-14a6-49ae-97bc-6eba6914391e",
  "exp": 1311281970,
  "iat": 1311280970,
  "name": "Jane Doe",
  "email": "jane.doe@mydomain.com"
}

Header, Payload und Signatur werden in Base64 kodiert und durch . getrennt im HTTP-Header Attribut Authorization als Bearer Token an den Server geschickt:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC82NzMxZGU3Ni0xNGE2LTQ5YWUtOTdiYy02ZWJhNjkxNDM5MWUvIiwic3ViIjoiMTIzNDU2IiwiYXVkIjoiNjczMWRlNzYtMTRhNi00OWFlLTk3YmMtNmViYTY5MTQzOTFlIiwiZXhwIjoxMzExMjgxOTcwLCJpYXQiOjEzMTEyODA5NzAsIm5hbWUiOiJKYW5lIERvZSIsImVtYWlsIjoiamFuZS5kb2VAbXlkb21haW4uY29tIn0.FPo7QaEAmb5jNuaShUtbdg2PXEVrTseIPjovN3s2Pz4

💡 Tooltipp
Beim Aufruf mit dem Open-Source Tool curl können die Zugangsdaten folgendermaßen gesetzt werden:

curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC82NzMxZGU3Ni0xNGE2LTQ5YWUtOTdiYy02ZWJhNjkxNDM5MWUvIiwic3ViIjoiMTIzNDU2IiwiYXVkIjoiNjczMWRlNzYtMTRhNi00OWFlLTk3YmMtNmViYTY5MTQzOTFlIiwiZXhwIjoxMzExMjgxOTcwLCJpYXQiOjEzMTEyODA5NzAsIm5hbWUiOiJKYW5lIERvZSIsImVtYWlsIjoiamFuZS5kb2VAbXlkb21haW4uY29tIn0.FPo7QaEAmb5jNuaShUtbdg2PXEVrTseIPjovN3s2Pz4" https://www.myserver.com/dataspot/rest/test/schemes

💡 Tooltipp
Zum Bearbeiten und Verifizieren von signierten JSON Web Tokens (JWTs) kann jwt.io verwendet werden.

Am Server wird die Benutzerkennung jane.doe@mydomain.com dem Claim email im signierten JSON Web Token (JWT) aus dem HTTP-Header Attribut Authorization entnommen.

• Der Default-Mandant kann mit dem Claim group übersteuert werden.
• Der Name des Benutzers kann gegebenenfalls dem Claim name entnommen werden.
• Die OpenID Connect Client-ID 6731de76-14a6-49ae-97bc-6eba6914391e muss im Claim aud enthalten sein.
• Der Subject Identifier 123456 aus dem Claim sub muss mit dem internen Subject Identifier des Benutzers übereinstimmen.

Ein Benutzer, dessen Benutzerkennung in der Liste john.smith@mydomain.com;joe.public@mydomain.com vorkommt, erhält darüber hinaus Zugriff auf alle Mandanten mit zusätzlicher Berechtigung als System-Administrator.

Beispiel: Resource Owner Password Credentials (ROPC)

Für den Aufruf einer Schnittstelle kann das Bearer Token mittels Resource Owner Password Credentials (ROPC) programmatisch (ohne Interaktion mit einem Benutzer) ermittelt und anschließend verwendet werden.

⚠️ Achtung
Falls der Identity Provider eine Multi-Faktor-Authentifizierung (MFA) (und somit eine Benutzer-Interaktion) erfordert, ist die Authentifizierung mit Resource Owner Password Credentials (ROPC) für den programmatischen Aufruf von Schnittstellen nicht geeignet. Stattdessen muss eine nicht-interaktive Authentifizierung (z.B. OAuth 2.0 Client Credentials Grant) verwendet werden.

Unter Windows können in einer PowerShell die Open-Source Tools curl und jq verwendet werden:

$USERNAME="jane.doe@mydomain.com"
$PASSWORD="s3cr3t"
$CLIENT_ID="6731de76-14a6-49ae-97bc-6eba6914391e"
$ID_TOKEN=$(curl.exe -X POST https://login.microsoftonline.com/organizations/oauth2/v2.0/token -d "username=$USERNAME&password=$PASSWORD&client_id=$CLIENT_ID&grant_type=password&scope=openid" | jq.exe -r ".id_token")
curl.exe -X GET -H "Authorization: Bearer $ID_TOKEN" https://www.myserver.com/dataspot/rest/test/schemes

Unter Linux können in einer Bash die Open-Source Tools curl und jq verwendet werden:

USERNAME="jane.doe@mydomain.com"
PASSWORD="s3cr3t"
CLIENT_ID="6731de76-14a6-49ae-97bc-6eba6914391e"
ID_TOKEN=$(curl -X POST https://login.microsoftonline.com/organizations/oauth2/v2.0/token -d "username=$USERNAME&password=$PASSWORD&client_id=$CLIENT_ID&grant_type=password&scope=openid" | jq -r ".id_token")
curl -X GET -H "Authorization: Bearer $ID_TOKEN" https://www.myserver.com/dataspot/rest/test/schemes

Zunächst wird der Identity Provider, der OpenID Connect unterstützt (z.B. Microsoft Entra ID), unter dem Endpunkt /token mit der Benutzerkennung und dem Passwort sowie der OpenID Connect Client-ID kontaktiert. Aus der Antwort in JSON wird unter Verwendung von jq die JSON-Property id_token extrahiert und als Umgebungsvariable ID_TOKEN gesetzt. Zuletzt wird die Schnittstelle /rest/test/schemes aufgerufen und das Bearer Token aus der Umgebungsvariable ID_TOKEN im HTTP-Header Attribut Authorization übermittelt.

Beispiel: OAuth 2.0 Client Credentials Grant

Wenn die Applikation in der Cloud gehostet wird (z.B. als Software-as-a-Service in Microsoft Azure), kann der Server durch ein Authentifizierungsmodul (z.B. Azure Easy Auth) geschützt sein. Beim Aufruf einer Schnittstelle muss ein gültiges und signiertes JSON Web Token (JWT) übergeben werden, damit die Abfrage das Authentifizierungsmodul passieren kann.

💡 Hinweis
Falls der Identity Provider eine Multi-Faktor-Authentifizierung (MFA) (und somit eine Benutzer-Interaktion) erfordert, ist die Authentifizierung mit Benutzerkennung und Passwort für den programmatischen Aufruf von Schnittstellen nicht geeignet.

Falls eine Schnittstelle von einem externen Programm aufgerufen wird, muss das JSON Web Token (JWT) deshalb mit einer nicht-interaktiven Methode beschafft werden (z.B. mit OAuth 2.0 Client Credentials Grant).

💡 Hinweis
In OAuth 2.0 Client Credentials Grant wird kein Benutzer sondern ein Client-Programm nicht-interaktiv (Machine-to-Machine) authentifiziert. Das aufrufende Client-Programm erhält die Berechtigung, auf die Applikation zuzugreifen.

In diesem Fall ist das JSON Web Token (JWT) kein OpenID Connect ID-Token, welches einen Benutzer identifiziert, sondern ein Access-Token, welches das Client-Programm authentifiziert. Das Access-Token enthält nicht die erforderliche Benutzerkennung die einem Benutzer in der Applikation zugeordnet werden kann.

Zusätzlich zum Access-Token, um das Authentifizierungsmodul zu passieren, muss bei jedem Schnittstellenaufruf zusätzlich ein Access Key übergeben werden, um den Benutzer bzw. Service User in der Applikation zu identifizieren.

Unter Windows können in einer PowerShell die Open-Source Tools curl und jq verwendet werden:

$TENANT_ID="b0ebd953-fb5f-425e-98fc-ec46bf8ce2f1"
$CLIENT_ID="6731de76-14a6-49ae-97bc-6eba6914391e"
$CLIENT_SECRET="s3cr3t"
$SCOPE="api://$CLIENT_ID/.default"
$ACCESS_KEY="0W7aB0dMEmRoGOq3M85gBD5CxSnNQhCBvlZsBm5XABkyxzjlE1tm7EPDF3bvIlTd6Uyu3_lReBTuhiFKWXAimU"
$ACCESS_TOKEN=$(curl.exe -X POST https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token -d "client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&grant_type=client_credentials&scope=$SCOPE" | jq.exe -r ".access_token")
curl.exe -X GET -H "Authorization: Bearer $ACCESS_TOKEN" -H "dataspot-access-key: $ACCESS_KEY" https://www.myserver.com/dataspot/rest/test/schemes

Unter Linux können in einer Bash die Open-Source Tools curl und jq verwendet werden:

TENANT_ID="b0ebd953-fb5f-425e-98fc-ec46bf8ce2f1"
CLIENT_ID="6731de76-14a6-49ae-97bc-6eba6914391e"
CLIENT_SECRET="s3cr3t"
SCOPE="api://$CLIENT_ID/.default"
ACCESS_KEY="0W7aB0dMEmRoGOq3M85gBD5CxSnNQhCBvlZsBm5XABkyxzjlE1tm7EPDF3bvIlTd6Uyu3_lReBTuhiFKWXAimU"
ACCESS_TOKEN=$(curl -X POST https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token -d "client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&grant_type=client_credentials&scope=$SCOPE" | jq -r ".access_token")
curl -X GET -H "Authorization: Bearer $ACCESS_TOKEN" -H "dataspot-access-key: $ACCESS_KEY" https://www.myserver.com/dataspot/rest/test/schemes

Zunächst wird der Identity Provider, der OAuth 2.0 Client Credentials Grant unterstützt (z.B. Microsoft Entra ID), unter dem Endpunkt /token mit der Client-ID und dem Client-Secret kontaktiert. Aus der Antwort in JSON wird unter Verwendung von jq die JSON-Property access_token extrahiert und als Umgebungsvariable ACCESS_TOKEN gesetzt. Zuletzt wird die Schnittstelle /rest/test/schemes aufgerufen und das Bearer Token aus der Umgebungsvariable ACCESS_TOKEN im HTTP-Header Attribut Authorization übermittelt. Der Access Key wird im HTTP-Header Attribut dataspot-access-key gesetzt.

Access Key

Ein Access Key ist eine geheime Zeichenfolge, die eindeutig einem Benutzer bzw. Service User zugewiesen wird. Beim Aufruf einer Schnittstelle kann der Access Key verwendet werden, um den Benutzer bzw. Service User zu identifizieren.

⚠️ Achtung
Bei der Authentifizierung mit Access Key wird der Benutzer nicht anhand der Zugangsdaten zugeordnet, d.h. der Access Key ersetzt die Anmeldung mit Zugangsdaten (z.B. Benutzerkennung und Passwort). Der Benutzer bzw. Service User und der Mandant werden direkt durch den Access Key identifiziert.

Bei der Authentifizierung mit Access Key werden die Zugriffsregeln nicht ausgewertet.

Der Access Key wird im HTTP-Header Attribut dataspot-access-key übertragen.

⚠️ Hinweis
Access Keys könnnen auscchließlich beim Aufruf von Schnittstellen verwendet werden. Die Anmeldung auf der Benutzeroberfläche mit einem Access Key ist nicht möglich.

Am Server wird der Access Key dem HTTP-Header Attribut dataspot-access-key entnommen. Der Access Key wird verifiziert und identifiziert eindeutig einen Benutzer bzw. Service User in der Applikation. Der Access Key gilt nur in einem einzigen Mandanten, d.h. der Mandant wird ebenfalls eindeutig durch den Access Key festgelegt.

⚠️ Hinweis
Falls ein Mandant im HTTP-Header Attribut dataspot-tenant gesetzt ist, dann wird die Anmeldung in diesem Mandanten erzwungen, unabhängig von der Authentifizierungsmethode. Falls der Mandant, der durch den Access Key bestimmt wird, sich davon unterscheidet, wird die Anmeldung abgelehnt.

Beispiel: Access Key

Der Access Key wird im HTTP-Header Attribut dataspot-access-key an den Server geschickt:

dataspot-access-key: 0W7aB0dMEmRoGOq3M85gBD5CxSnNQhCBvlZsBm5XABkyxzjlE1tm7EPDF3bvIlTd6Uyu3_lReBTuhiFKWXAimU

💡 Tooltipp
Beim Aufruf mit dem Open-Source Tool curl kann der Access Key folgendermaßen gesetzt werden:

curl -H "dataspot-access-key: 0W7aB0dMEmRoGOq3M85gBD5CxSnNQhCBvlZsBm5XABkyxzjlE1tm7EPDF3bvIlTd6Uyu3_lReBTuhiFKWXAimU" https://www.myserver.com/dataspot/rest/test/schemes

Am Server wird der Access Key dem HTTP-Header Attribut dataspot-access-key entnommen.

• Der Access Key bestimmt den Benutzer bzw. Service User und den Mandanten.
• Die Zugriffsregeln werden nicht ausgewertet.

Zuordnen von Zugangsdaten zu Benutzern

Der Login-Mandant ist jener Mandant, in dem ein Benutzer in der Benutzeroberfläche bzw. über Schnittstelle (Metadata REST/API, Metadata Upload/Download) angemeldet wird. Anhand der Benutzerkennung aus den Zugangsdaten wird der Login-Mandant wie folgt ermittelt:

• Falls ein Mandant im HTTP-Header Attribut dataspot-tenant gesetzt ist, dann erfolgt die Anmeldung in diesem Mandanten.
• Falls die Benutzerkennung dem System-Administrator entspricht, dann erfolgt die Anmeldung im Default-Mandanten.
• Falls ein Benutzer mit der Benutzerkennung und dem Kennzeichen, dass der Benutzer standardmäßig angemeldet wird, in einem Mandanten existiert, dann erfolgt die Anmeldung in diesem Mandanten.
• Falls ein Benutzer mit der Benutzerkennung im Default-Mandanten existiert, dann erfolgt die Anmeldung im Default-Mandanten.
• Falls ein Benutzer mit der Benutzerkennung in einem anderen Mandanten existiert, dann erfolgt die Anmeldung in diesem Mandanten.
• Die Benutzerkennung existiert nicht, daher erfolgt die Anmeldung im Default-Mandanten.

⚠️ Achtung
Falls ein Mandant im HTTP-Header Attribut dataspot-tenant gesetzt ist, dann wird die Anmeldung in diesem Mandanten erzwungen, unabhängig von der Authentifizierungsmethode. Falls der Benutzer keinen Zugriff auf den Mandanten hat oder der Mandant nicht existiert, dann wird die Anmeldung abgelehnt.

🛈 Hinweis
In jeder Datenbank ist genau ein Default-Mandant definiert. Je nach Authentifizierungsmethode kann dieser Default-Mandant in den Zugangsdaten übersteuert werden (siehe DATASPOT_REMOTE_USER_TENANT_NAME, DATASPOT_JNDI_TENANT_NAME und DATASPOT_OIDC_JWT_TENANT_NAME).

Sowohl für den Login-Mandanten als auch für alle anderen Mandanten wird ermittelt, ob der Benutzer Zugriff auf den Mandanten hat bzw. ob der Mandant in der Benutzeroberfläche ausgewählt werden kann:

• Falls die Benutzerkennung in einem Mandanten existiert, erhält der Benutzer Zugriff entsprechend seiner festgelegten Zugriffsstufe.
• Falls die Benutzerkennung in einem Mandanten nicht existiert, werden die Zugriffsregeln des Mandanten ausgewertet.
• Ein System-Administrator bzw. ein Benutzer, der als System-Administrator tätig sein darf (siehe DATASPOT_ADMIN_USER), erhält darüber hinaus Zugriff auf alle Mandanten mit zusätzlicher Berechtigung als System-Administrator.
• Ansonsten erhält der Benutzer keinen Zugriff auf den Mandanten.

⚠️ Achtung
Falls der Benutzer keinen Zugriff auf den Login-Mandanten hat, dann wird die Anmeldung abgelehnt.

Zugriffsregeln auswerten

Ein Benutzer, dessen Benutzerkennung in einem Mandanten nicht existiert, kann trotzdem Zugriff auf den Mandanten erhalten. Dazu können im Mandanten entsprechende Zugriffsregeln konfiguriert werden, um die Anmeldung und die Auswahl des Mandanten in der Benutzeroberfläche zu ermöglichen.

⚠️ Achtung
Die Zugriffsregeln werden nicht ausgewertet, falls die Authentifizierung mit einem Access Key erfolgt.

Die zusätzlichen Regeln für den Zugriff auf den Mandanten werden ausgewertet, wenn ein extern authentifizierter Benutzer nicht der Benutzerkennung eines vorhandenen Benutzers zugeordnet werden kann. Die Zugriffsregeln werden von oben nach unten abgearbeitet:

• Für jede Zugriffsregel wird die Bedingung ausgewertet.
  • Falls die Bedingung zutrifft, wird die Aktion durchgeführt, d.h. der Zugriff wird zugelassen oder abgelehnt und gegebenenfalls wird ein Benutzer automatisch angelegt. Falls keine Bedingung definiert ist, wird die Aktion immer durchgeführt. Keine weiteren Zugriffsregeln werden verarbeitet.
  • Falls die Bedingung nicht zutrifft, wird mit der Auswertung der nächsten Zugriffsregel fortgefahren.
• Falls keine Zugriffsregel zutrifft, wird der Zugriff abgelehnt.

🛈 Hinweis
Zugriffsregeln werden nur ausgewertet, wenn sie aktiviert sind (DATASPOT_ACCESS_RULES). Anderenfalls werden externe Benutzer immer abgelehnt.

⚠️ Achtung
Die Authentifizierungsmethode mit Benutzerkennung und Passwort (Basic Authentication) unterstützt keine Anmeldung als Gast (nur-lesend) ohne Benutzer.

Je nach Authentifizierungsmethode (Single Sign-On, Same Sign-In, OpenID Connect) muss der Benutzer trotzdem im externen System (am Reverse-Proxy, in LDAP, in Microsoft Entra ID, usw.) verifiziert werden können.

🛈 Hinweis
Damit die Zugangsdaten ausgewertet und einem Benutzer in der Applikation zugeordnet werden können, muss beim Öffnen der Benutzeroberfläche bzw. beim Aufruf einer Schnittstelle der Datenbankname (z.B. test) in der URL angegeben werden (z.B. https://www.myserver.com/dataspot/web/test).