Skip to main content

Single Sign-on

KIX bietet die Möglichkeit der Nutzerauthentifizierung und Autorisierung über Single Sign-on (SSO). Unterstützt werden aktuell:

Konfigurationsschlüssel

Authentication ###00- Kerberos

Bei Aufruf des Agenten- oder Self Service Portals kann die Authentifizierung des Nutzers durch Kerberos erfolgen. Der Nutzer muss sich somit nicht zwingend mit Nutzername und Passwort an KIX anmelden, wenn er bereits durch sein Login an der Domäne authentifiziert ist (= Single Sign On - Einmalanmeldung).

Voraussetzung dafür ist, dass in Ihrem Unternehmen Kerberos aktiv genutzt wird und ein gegen eine Domäne (z. B. Active Directory/LDAP) authentifizierter Nutzer vorliegt.

Für die Anbindung an KIX benötigen Sie eine Keytab-Datei, die Sie von Ihrem Administrator erhalten. Damit KIX die Keytab-Datei direkt in der SysConfig verwenden kann, muss deren Inhalt in Base64-Format hinterlegt werden (empfohlenes Vorgehen).

Zum Konvertieren der Keytab -Datei ins Base64-Format können Sie entweder freie Tools wie bspw. base64encode.org3 oder die Linux-Konsole verwenden. Alternativ kann die Keytab-Datei in den Backend-Container eingebunden und dann deren Pfad in der SysConfig hinterlegt werden.

Anbindung

  1. Navigieren Sie zum Menü System > SysConfig.

  2. Suchen und öffnen Sie den Konfigurationsschlüssel Authentication###00-Kerberos.

    [
      {
        "Name": "Kerberos Example",
        "Enabled": 0,
        "Module": "KIXPro::Kernel::System::Auth::Kerberos",
        "Config": {
          "Keytab":     "<insert base64 content of keytab file here>",
          "KeytabFile": "(optional)<path to keytab file in filesystem>",
          "Realm":      "(optional)<insert your realm here>",
          "krb5.conf":  "(optional)<insert base64 content of krb5.conf file here>"
        }
      }
    ]
  3. Kennzeichnen Sie die Authentifizierung als "aktiv" (Enabled: 1,)

  4. Hinterlegen Sie unter Keytab die ins Base64-Format konvertierte Keytab-Datei.

  5. Entfernen oder setzen Sie optionale Parameter.

    (siehe Konfigurationsparameter in KIX

  6. Speichern Sie Ihre Eingaben mit Speichern.

  7. Klicken Sie auf "Lade Frontend-Konfigurationen neu".

  8. Aktivieren Sie SSO im Frontend

    SSO kann sowohl für das Agenten- als auch für das Self Service Portal aktiviert werden.

    Dazu müssen die jeweiligen Konfigurationen in der environment-Datei Ihrer On-Premise-Konfiguration aktiviert werden:

    SSO_ENABLED = true
    SSO_ENABLED_SSP = true

    Anschließend ist ein Stack-Neustart erforderlich.

Danach kann die Kerberos-Authentifizierung genutzt werden.

Konfigurationsparameter in KIX

Parameter

Beschreibung

Keytab

Inhalt der Keytab-Datei als Base64-String

Keytabfile

Angabe des Dateipfads zur Keytab-Datei, wie sie im Backend- Container eingebunden ist.

(Alternative Angabe zu "Keytab")

Realm

Geben Sie optional den Kerberos Realm als RegEx an (Name der DNS-Domäne)

Zum Beispiel: "example\.org".

Beachten Sie dabei Groß- und Kleinschreibung (wie von Keberos geliefert).

Ist nichts angegeben, wird der Teil vor dem @ für das Log-in verwendet (max.mustermann@example.org)

Wenn angegeben und die E-Mail-Adresse

  • passt, dann wird der Teil vor dem @ (Nutzername) als Log-in verwendet (max.mustermann).

  • passt nicht, dann wird die vollständige, von Kerberos gelieferte Angabe als das Log-in verwendet (max.mustermann@example.org)

krb.conf

Kerberos-Konfigurationsdatei als Base64-String (optional)

Die Keytab Datei

Eine Keytab-Datei ist eine kryptografische, binäre Textdatei, welche die Benutzerkonten inkl. der mit einem Hash verschlüsselten Passwörter enthält. Sie ermöglicht die automatische Anmeldung KIX.

Die Keytab-Datei können Sie bspw. mit dem Kerberos Dienstprogramm ktpass erstellen. Informationen hierzu finden Sie bspw. unter: https://docs.microsoft.com/de-de/windows-server/administration/windows- commands/ktpass.

Ersetzen Sie im nachfolgenden Beispiel FQDN, DOMAIN, USER und PASSWORD durch Ihre entsprechenden Parameter. Beachten Sie dabei Groß- und Kleinschreibung.

Beispiel: Angaben für eine Keytab Datei:

C:\temp> ktpass -princ HTTP/fqdn@DOMAIN -mapuser USER@DOMAIN -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass PASSWORD -out c:\temp\kix.keytab

Wichtig

Achten Sie darauf, beim Erstellen der Keytab-Datei einen korrekten Service Principal Namen (SPN) anzugeben, z. B: HTTP/my.webserver.hostname@DOMAIN.IN.GROSSBUCHSTABEN.ORG

Besteht die Notwendigkeit mehrere Service Principal Namen (SPN) anzugeben (z.B. wenn "your-kix- agent.example.com" und "your-kix-ssp.example.com" verwendet werden um Agentenportal und SSP unter versch. Hostnamen anzusprechen), werden die Keytabs kombiniert:

Beispiel: Angaben für kombinierte Angaben in der Keytab Datei:

C:\temp> ktpass -princ HTTP/fqdn@DOMAIN -mapuser USER@DOMAIN -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass PASSWORD -out c:\temp\kix1.keytab
C:\temp> ktpass -princ HTTP/fqdn2@DOMAIN -mapuser USER@DOMAIN -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass PASSWORD -in c:\temp\kix1.keytab -out c: \temp\kixAll.keytab

Hinweise zur Base64 Codierung

Unter Linux können Sie dazu folgende Kommandozeile verwenden um die Keytab Base64 zu codieren (Ergebnis in Datei kix.keytab.b64). Der Inhalt kann direkt in Parameter "Keytab" verwendet werden.

SomeLinuxSystem:~# base64 -w 0 ./kix.keytab > ./kix.keytab.b64

Unter Windows können Sie folgende Kommandozeilen verwenden um die Keytab Base64 zu codieren (Ergebnis in Datei kix.keytab.b64). Für die Verwendung in in Parameter "Keytab" müssen die Zeilenbrüche entfernt werden.

C:\temp> certutil -encode -f kix.keytab kix.keytab.encoded
C:\temp> type kix.keytab.encoded | find /v "CERTIFICATE" > kix.keytab.b64

Verwendung / client-seitige Voraussetzungen

Damit Single Sign On via Firefox funktioniert, muss in diesem die Einstellung "network.negotiate-auth.trusted- uris" den FQDN der KIX-Umgebung oder auch der gesamten Zieldomain beinhalten (z.B. "yourkix.example.com" oder "*.example.com".

Im Edge-Browser muss die Sicherheitsrichtlinie entsprechend konfiguriert werden.

Fehlerbehandlung

Sollte SSO mittels Kerberos nicht funktionieren, prüfen Sie zunächst, ob auf dem sich authentifizierenden Windows-Client ein Kerberosticket für den KIX-FQDN vorhanden ist. Verwenden Sie dazu das Kommandozeilentool klist.

Um Problemen vorzubeugen, beachten Sie weiterhin folgende wesentliche Anforderungen beim Einsatz von Kerberos:

  • Die Namensauflösung des FQDN muss auch rückwärts funktionieren.

  • FQDN muss ein A-Host-Eintrag im DNS sein.

  • Systemzeit des KIX (Backends) muss korrekt sein.

Verweise

OpenID Connect (OIDC) ist ein offenes Authentifizierungsprotokoll auf Basis von OAuth2. Es wird von verschiedenen Systemen für die Authentifizierung und Autorisierung der Nutzer verwendet. KIX unterstützt eine Reihe von Identification Providern (IDP), die auf Basis von OpenID Connect arbeiten, z. B.

  • GitLab

  • Keycloak

  • Microsoft Active Directory Federation Service (AD FS)

  • Microsoft Entra/Azure.

Somit können berechtigte Nutzer mit den bei einem Identity Provider (IDP) zentral abgelegten Zugangsdaten auf KIX zugreifen, ohne sich mit eigenen Zugangsdaten zusätzlich an KIX anmelden zu müssen. Die Nutzer müssen in KIX bereits als Nutzer für den jeweiligen Kontext (Agentenportal/Self Service Portal) angelegt sein.

Entsprechend der Konfiguration steht im Login-Fenster des Agenten- und/oder Self Service Portals ein separater Button zur Verfügung, mit dem sich der Nutzer via OpenID Connect an KIX anmelden kann. Nach Klick auf den Button erfolgt eine Weiterleitung zum Identity Provider, um die notwendigen Zugangsdaten für KIX abzufragen und den Zugang zu gewähren.

sso_oidc_nutzer-login.png

Abb.: SSO mit OpenID Connect

Hinweis

  • Aktuell erfolgt nur eine Authentifizierung durch den IDP. In KIX muss dafür bereits ein Nutzer mit entsprechendem Zugang und Rechten gepflegt sein.

  • Ein Datenabgleich der Kontaktdaten, oder die Pflege von Zugängen und Berechtigungen ist bisher NICHT implementiert.

  • Sowohl der Browser des Nutzers als auch das KIX-Backend müssen mit dem IDP kommunizieren können.

    Gegebenenfalls muss der Proxy im SysConfig-Schlüssel WebUserAgent::Proxy konfiguriert werden:

    sso_oidc_proxy.png

Einrichtung Identity Provider (IDP)

Die Einrichtung der Applikation seitens Identification Provider obliegt Ihnen und Ihrem Unternehmen. Informationen dazu finden Sie unter anderem hier:

Einrichtung OAuth2 Profil

Menü

System > OAuth2 Profile

Richten Sie zunächst ein OAuth2 Profil ein und hinterlegen Sie die vom Identity Provider bereitgestellten

Weiterführende Informationen s. auch: OAuth2 Profiles

sso_oidc_profil.png

Abb.: Einrichtung eines OIDC Profils

Konfigurationsparameter

Parameter

Beschreibung

Beispiel

Name

Aussagekräftiger Name des Profils.

Der Name des Profils wird in der Konfiguration der Authentifizierungsmodule benötigt (s. unten)

GitLab OIDC

Autorisier ungs-URL

Tragen Sie die URL für die OIDC Autorisierung ein.

Sie wird zum Starten der Anfrage verwendet.

http://your-git-path.example.com/oauth/authorize

Token URL

Tragen Sie die URL für den OIDC Token ein.

Sie wird für den Abruf des ID-Tokens durch das Backend verwendet.

http://your-git-path.example.com/oauth/token

Redirect URL

Für die Verwendung mit OIDC ist diese Angabe nicht relevant, da Agenten Portal und Self Service Portal die URLs eigenständig im Authentifizierungsprozess vorgeben.

Wenn Sie OIDC zur Anmeldung ab der API verwenden wollen, können Sie hier die URL zur Authentifizierung am Backend hinterlegen.

  • https://your-frontend- host.example.com/oauth2redirect

  • https://your-frontend- host.example.com:47111/api/v1/auth

Client ID

Tragen Sie hier die alphanumerische Client-ID ein.

Azure: die Anwendungs-ID (Client)

Client Secret

Tragen Sie hier das Client-Secret ein.

Azure: der Clientschlüssel aus "Zertifikate & Geheimnisse"

Scope

Die Angabe des Geltungsbereichs hängt vom verwendeten System ab.

Der Scope sollte immer die Angabe 'openid' enthalten. Je nach IDP und gewünschten Login-Attribut, können weitere Angaben nötig sein.

openid | openid profile | openid email

  • Microsoft Entra / Azure:

    • Anmeldung per Email:

      • Scope: "openid email"

    • Anmeldung per Login-Name:

      • Scope: "openid profile"

      • Login-Attribute: "name" oder "preferred_username"

  • KeyCloak:

    • Anmeldung per Email: Scope 'openid email'

Gültigkeit

  • gültig: Das Profil kann verwendet werden. Nutzer können sich hierüber anmelden.

  • (temporär) ungültig: Das Profil kann nicht verwendet werden. Nutzer können sich hierüber nicht anmelden.

Einrichtung Authentifizierungs-Backend

Menü

KIX > System > SysConfig

Konfigurationsschlüssel

Authentication###000-OIDC

Vor der Einrichtung des Authentifizierungs-Backends muss im Menü System > OAuth2 Profile mindestens ein OAuth2-Profil angelegt und eingerichtet worden sein.

Sie können mehrere Backends konfigurieren. Geben Sie für jedes Backend das jeweilige OAuth2-Profil an. Achten Sie darauf, dass zu jedem eingerichteten Backend ein entsprechendes OAuth2-Profil vorliegt und die Angaben korrekt sind. Anderenfalls schlägt der Login fehl.

Nach dem Speichern der Konfiguration und Klick auf Lade Frontendkonfiguration neu steht den Nutzern am Login-Fenster des Agenten- und Self Service Portals ein zusätzlicher Button für die Anmeldung via OIDC zur Verfügung.

Beispiel für das Authentifizierungs-Backend:

[
   {
      "Config": {
         "JWKS": {
            "URI": "http://git.example.de/oauth/discovery/keys"
         },
         "LoginAttribute": "nickname",
         "Profile": "GitLab OIDC",
         "Verify": {
            "Audience": "<ClientID>",
            "Issuer": "http://git.example.de"
         }
      },
      "Enabled": 1,
      "Module": "Auth::OIDC",
      "Name": "OIDC Log-in"
   },
   {
      "Config": {
         "JWKS": {
            "URI": "https://login.microsoftonline.com/alphanumerischer-schluessel/discovery/v2.0/keys"
         },
         "LoginAttribute": "email",
         "Profile": "Azure",
         "Verify": {
            "Audience": "<ClientID>",
            "Issuer": "https://login.microsoftonline.com/alpanumerischer- schluessel/v2.0"
         }
      },
      "Enabled": 1,
      "Module": "Auth::OIDC",
      "Name": "Azure Log-in"
   }
]

Konfigurationsparameter

Parameter

Beschreibung

Beispiel

JWKS

JSON Web Key Set

Diese Angaben dienen der Verifizierung der Signatur des aufgerufenen ID- Tokens.

CacheTTL

(Optional) Angabe der Zeit in Sekunden, um angeforderte Schlüssel von URI im Cache zu behalten.

  • Wenn nicht angegeben, wird 360 (eine Stunde) verwendet.

  • Zur Deaktivierung des Caches '0' angeben.

Key

Tragen Sie den Schlüsselstring zur Verifizierung des ID-Tokens ein.

Die Angabe hat Vorrang vor "JWKS_URI".

Wird hier ein verschlüsseltes Zertifikat angegeben, kann mit "KeyPass" das Passwort zur Entschlüsselung µngegeben werden.

PEM Schlüssel oder JWK (JSON Web Key)

URI

(Optional) Tragen Sie die URI zur Abfrage gültiger Schlüssel ein.

  • Azure: "https:// login.microsoftonli ne.com/ alphanumerischer- schluessel/ discovery/v2.0/ keys"

  • GitLab: "http:// git.example.de/ oauth/discovery/ keys

LoginAttribute

(Optional) Attribut in ID-Token zur Verwendung als Login

email | nickname

Profile

Exakter Name des zu verwendenden OAuth2- Profils.

Das Profil muss zuvor unter OAuth2 Profileangelegt worden und gültig sein.

Existiert das angegebene Profil nicht oder ist ungültig, dann ist die Authentifizierung nicht möglich. Der Login-Button wird nicht angezeigt.

Fehlermeldungen finden Sie im Menü System > Logs.

GitLab OIDC | Azure | o.a.

Verify

Angaben zur Verifizierung des ID-Tokens

Audience

(optional) Name der Zielgruppe, für die der Token ausgestellt wurde.

Verwenden Sie "<ClientID>", um die Kunden-ID aus dem Profil zu verwenden.

<ClientID>

Expiration

(optional)

  • 0 - deaktiviert die Prüfung

  • 1 - erfordert Prüfung.

Wenn nicht gesetzt, wird geprüft, ob der Claim "exp" vorhanden ist.

0 | 1

IssueAt

(optional)

  • 0 - deaktiviert die Prüfung

  • 1 - erfordert Prüfung.

Wenn nicht gesetzt, wird geprüft, ob der Claim "iat" vorhanden ist.

0 | 1

Issuer

(optional) Name des Ausstellers

  • Azure: "https:// login.microsoftonli ne.com/ alphanumerischer- schluessel/v2.0"

  • GitLab: http:// git.example.de.

Leeway

(optional) Toleranz in Sekunden

Toleranz für IssueAt, NotBefore und Expiration

NotBefore

(optional)

  • 0 - deaktiviert die Prüfung

  • 1 - erfordert Prüfung.

Wenn nicht gesetzt, wird geprüft, ob der Claim "nbf" vorhanden ist.

0 | 1

Enabled

De-/Aktiviert das Authentifizierungsbackend

0 | 1

Module

Für die Nutzung der OIDC-Authentifizierung ist als Modul "Auth::OIDC" anzugeben.

Auth::OIDC

Name

Name des Authentifizierungs-Backends.

Dieser steht dann auf dem Login-Button

OIDC Log-in

UsageContext

(Optional) Definiert, für welchen Nutzungskontext dieses Authentifizierungs-Backend genutzt werden kann.

Ist nichts angegeben, wird es sowohl für das Agentenportal als auch für das Self Service Portal genutzt.

Agent | Customer