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
Navigieren Sie zum Menü
.Suchen und öffnen Sie den Konfigurationsschlüssel
.[ { "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>" } } ]
Kennzeichnen Sie die Authentifizierung als "aktiv"
(Enabled: 1
,)Hinterlegen Sie unter
Keytab
die ins Base64-Format konvertierte Keytab-Datei.Entfernen oder setzen Sie optionale Parameter.
Speichern Sie Ihre Eingaben mit
.Klicken Sie auf "Lade Frontend-Konfigurationen neu".
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
|
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
Kerberos: https://www.ibm.com/docs/de/was/9.0.5?topic=mechanism-kerberos-krb5-authentication- support-security
Service principal name (SPN): https://www.ibm.com/docs/de/was/9.0.5?topic=server-creating- kerberos-service-principal-name-keytab-file
Kerberos Realm: https://web.mit.edu/kerberos/krb5-1.12/doc/admin/realm_config.html
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.

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
konfiguriert werden:
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

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. |
|
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
|
Gültigkeit |
|
Einrichtung Authentifizierungs-Backend
Menü | KIX > System > SysConfig |
Konfigurationsschlüssel | Authentication###000-OIDC |
Vor der Einrichtung des Authentifizierungs-Backends muss im Menü
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
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. |
| |
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. |
| |
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 angelegt 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ü . | 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)
Wenn nicht gesetzt, wird geprüft, ob der Claim "exp" vorhanden ist. | 0 | 1 | |
IssueAt | (optional)
Wenn nicht gesetzt, wird geprüft, ob der Claim "iat" vorhanden ist. | 0 | 1 | |
Issuer | (optional) Name des Ausstellers |
| |
Leeway | (optional) Toleranz in Sekunden Toleranz für IssueAt, NotBefore und Expiration | ||
NotBefore | (optional)
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 |