Okey habe es nun herausgefunden, aus der /Kernel/Config/Defaults.pm kann die Beispielkonfiguration in /Kernel/Config.pm kopiert und angepasst werden.

Ich versuche nun die OAuth Applikation an das Azure AD anzubinden, ich werde nun erfolgreich zur Loginseite von Microsoft weitergeleitet und kann mich auch problemlos authentifizieren, leider funktioniert aber danach der Login auf Otobo nicht. Ich erhalte ausschliesslich den folgenden Fehler:

[Error][Kernel::System::Cache::Get][294] Need Key!

Meine Konfiguration sieht wie folgt aus:

$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::OpenIDConnect';
$Self->{'Customer::AuthModule::OpenIDConnect::AuthRequest'}->{ResponseType} = [ 'code' ];
$Self->{'Customer::AuthModule::OpenIDConnect::AuthRequest'}->{ResponseType} = [ 'id_token' ];
$Self->{'Customer::AuthModule::OpenIDConnect::AuthRequest'}->{AdditionalScope} = [
qw/profile email/
];
$Self->{'Customer::AuthModule::OpenIDConnect::Config'}{ClientSettings} = {
ClientID => 'xxxxxxxx',
RedirectURI => 'https://xxxxxxxx.azurewebsites.net/otobo/customer.pl?Action=Login',
};
$Self->{'Customer::AuthModule::OpenIDConnect::Config'}{ClientSettings}{ClientSecret} = 'xxxxxxxx';
$Self->{'Customer::AuthModule::OpenIDConnect::Config'}{ProviderSettings} = {
OpenIDConfiguration => 'https://login.microsoftonline.com/xxxxxxxx/v2.0/.well-known/openid-configuration',
SSLOptions => 0,
};
$Self->{'Customer::AuthModule::OpenIDConnect::UID'} = 'sub';
$Self->{'Customer::AuthModule::OpenIDConnect::Config'}{Misc} = {
UseNonce => 1, # add a nonce to request and token (this is primarily important for the implicit flow where it is enabled by default)
RandLength => 22, # length for state and nonce random strings - default: 22
RandTTL => 60 * 5, # valid time period for state and nonce (roughly the time a user can take to authenticate) - default: 300 s
};
$Self->{'Customer::AuthModule::OpenIDConnect::Debug'}->{'LogIDToken'} = 1;

Obwohl der Debug Mode eingeschaltet ist, erhalte ich nicht mehr Informationen und mit der Fehlermeldung kann ich momentan nicht viel anfangen.

Hallo Stefan, dies ist mir gestern auch noch aufgefallen und ich habe momentan ausschliesslich ‚id_token‘ aktiviert. Jedoch erhalte ich immernoch den Fehler ‚Need Key!‘. Im Response habe ich den ‚id_token‘ und auch den Token habe ich decoded und dieser sieht in Ordnung aus. Wäre es möglich mir den Auszug deiner Keycloack Config zuzustellen? Ich denke nicht dass hier Azure AD das Problem ist, es muss meiner Meinung nach an der fehlerhaften Config in Otobo liegen.

Hallo zusammen

Vielen Dank für die Rückmeldung, den Benutzer habe ich auch bereits als Kunden im Otobo erfasst damit die Zuordnung auch gemacht werden kann. Um nun Azure AD als Problemverursacher auszuschliessen habe ich nun eine Keycloak Instanz provisioniert und angebunden, aber auch da ist der Fehler identisch „Need Key!“.

In Otobo habe ich den Kunden angelegt und die folgenden Attribute befüllt:

• Firstname (Wert: gleicher Vorname wie in der Keycloak DB)
• Lastname (Wert: gleicher Nachname wie in der Keycloak DB)
• Username (Wert: gleicher Username wie in der Keycloak DB)
• Email (Wert: gleiche Email wie in der Keycloak DB)
• Customer ID (Wert: Kunde zugewiesen in Otobo)
• Valid (Wert: valid)

Die folgenden Werte sind ebenfalls abgefüllt, jedoch sicherlich nicht relevant für die Authentifizierung und dem Mapping des Benutzers:

• Interface language: English (United Kingdom)
• Time Zone: UTC
• Ticket overview: off
• Number of displayed tickets: 25

Die Keycloak Configuration sieht nun wie folgt aus (habe es sowohl mit id_token als auch mit code versucht, der Fehler ist immer „Need Key!“):

$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::OpenIDConnect';
$Self->{'Customer::AuthModule::OpenIDConnect::AuthRequest'}->{ResponseType} = [ 'code' ];
$Self->{'Customer::AuthModule::OpenIDConnect::AuthRequest'}->{AdditionalScope} = [
qw/profile email/
];
$Self->{'Customer::AuthModule::OpenIDConnect::Config'}{ClientSettings} = {
ClientID => 'account',
RedirectURI => 'https://xxxx.azurewebsites.net/otobo/customer.pl?Action=Login',
};
$Self->{'Customer::AuthModule::OpenIDConnect::Config'}{ClientSettings}{ClientSecret} = 'xxxx';
$Self->{'Customer::AuthModule::OpenIDConnect::Config'}{ProviderSettings} = {
OpenIDConfiguration => 'https://xxxx-keycloak.xxxx/realms/master/.well-known/openid-configuration',
};
$Self->{'Customer::AuthModule::OpenIDConnect::UID'} = 'sub';
$Self->{'Customer::AuthModule::OpenIDConnect::Config'}{Misc} = {
UseNonce => 1,
RandLength => 22,
RandTTL => 60 * 5,
};

Würde mich freuen wenn OIDC auch mit Keycloak funktionieren sollte, denn an der Azure AD Anbindung bin ich nicht weit davon entfernt. Zu der Frage weshalb wir keine LDAP-Anbindung machen, unsere Kunden sind vermehrt cloud-only Kunden, hier würde ich den Sync und die Erfassung der Benutzer wahrscheinlich über Graph API machen. Aber zuerst muss natürlich die Authentifizierung funktionieren bevor ich alle Tenants anbinde :).

@Sven: Ja das war ich auf Github, kannst du gerne ignorieren.

Peinlich! Habe dies völlig übersehen das die UID auf SUB gestellt ist, habe dies nun angepasst auf email und es funktioniert auch mit der Azure Authentifizierung. Habe nun auch den Keycloak am Azure angebunden, damit ich einfacher meine verschiedenen Kundentenants anbinden kann. Danke euch! Für andere welche evtl. dasselbe Problem haben, die Config oben ist korrekt ausschliesslich die folgende Zeile anpassen:

$Self->{'Customer::AuthModule::OpenIDConnect::UID'} = 'email';

Habe ich dies korrekt verstanden dass für das Kundenportal keine automatische Erstellung der Benutzer möglich ist? D.h. der Benutzer muss vorgängig bereits als Kunde erfasst worden sein?

Okey, danke für die Rückmeldung.