-
Beiträge
-
-
Für die Benutzerauthentifizierung benötigen wir zwingend OpenID und gemäss den aktuellsten Release Notes sollte dies von Otobo unterstützt sein. Leider finden wir in den Handbüchern und auch im Forum keine genauen Beschreibungen wie dieses Plugin aktiviert und konfiguriert werden kann.
Bisher habe ich ausschliesslich in der Systemkonfiguration das folgende Setting angepasst und auf OAuth umgestellt:
Kernel::System::CustomerAuth::OpenIDConnect
Nun suche ich verzweifelt nach der Option die OpenID Konfiguration im System zu konfigurieren (wie z.B. URL, Secret, App ID, etc.). Leider finde ich diese Möglichkeit im Backend des Systemes nicht, im Code bin ich auch nicht wirklich schlau geworden wo ich diese Einstellungen angeben kann. Wäre hilfreich wenn ich wenigstens wüsste, welche Anpassungen ich welchen Files vorgenommen werden müssen damit Open ID für das Customer Portal in Betrieb genommen werden kann.
-
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 Goran,
was mir auf den ersten Blick auffällt, ist dass Du beide Optionen aktiv hast:
$Self->{‘Customer::AuthModule::OpenIDConnect::AuthRequest’}->{ResponseType} = [ ‘code’ ];
$Self->{‘Customer::AuthModule::OpenIDConnect::AuthRequest’}->{ResponseType} = [ ‘id_token’ ];In dem Fall nimmt OTOBO glaube ich “id_Token” und nicht den “code” Flow. Aber beides macht keinen Sinn. Ich habe bisher die Anbindung nur an Keycloak vorgenommen, weiß also leider nicht was Azure benötigt.
Ich hoffe ich konnte ein bisschen weiterhelfen!
Schöne Grüße,
Stefan
Team OTOBO
-
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 Goran,
da wird ein Fehler nicht richtig abgefangen, das werden wir Code anpassen – was das ganze auslöst, ist, dass der UserLogin der aus dem Token gelesen wird nicht existiert.
Auf Kundenseite ist es derzeit so, dass das OpenIDConnect nur zur Authentifizierung genutzt werden kann. Das hat ein bisschen den Hintergrund, dass man Kundenbenutzer in der Regel unabhängig davon angelegt haben möchte, ob Sie sich einmal angemeldet haben, oder nicht (Email z.B. müssen ja trotzdem zugeordnet werden). Zudem sind die Backends für die Kundenbenutzer konfigurabel, während Agenten immer in der OTOBO-DB selbst angelegt sind,… Der ganze Synchronisationsprozess existiert auch bei LDAP z.B. nur für Agenten. (Wobei da natürlich der Kundenbenutzer unabhängig von seinem Login aus dem LDAP gelesen werden kann.)
Viele Grüße, Sven
P.S.: Ich nehme an, dass du g0g11 auf github bist, dann werde ich da nicht nochmal antworten.
-
Hallo Goran,
nur um Missverständnisse zu vermeiden, der Fehler hat keine Auswirkungen, außer einer unschönen Fehlermeldung.
Was Du tun musst ist einen Kundendatentopf zu konfigurieren, damit OTOBO den User nach der Authentifizierung kennt. Kannst Du die Kundendaten nicht per LDAP abfragen? Anschließend kann die Authentifizierung über OpenID Connect erfolgen.
Schöne Grüße,
Stefan
-
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.
-
Wenn du
$Self->{'Customer::AuthModule::OpenIDConnect::Debug'}->{'LogIDToken'} = 1;aktiviert hast, sollte dir das Token im Log ausgegeben werden. Da du die UID auf ‘sub’ gesetzt hast, überprüf doch mal bitte, ob der Username des Kundenbenutzers tatsächlich dem Wert entspricht, der in dem Token unter ‘sub’ mitgeliefert wird.
Viele Grüße
-
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?
-
-
-
Hallo Goran,
falls Du mal Zeit hast, wäre es super wenn Du kurz Deine Einstellungen im Azure und in OTOBO posten könntest, damit wir das in eine Doku übernehmen können.
Für POP und IMAP über OAuth haben wir gerade eine Anleitung erstellt, wir verwenden nur bei uns keine MS Produkte und können das nicht so einfach nachstellen. Die Doku als Beispiel findest Du hier:
Vielen Dank!
Stefan
Team OTOBO
-
-
I finally managed to sort out OpenIDconnect for Azure AD. In the settings that you can find in this forum there is an error.
$Self->{‘Customer::AuthModule::OpenIDConnect::UID’} = ‘sub’; (looking at the tocken dump in the log the ‘sub’ is actually the cookie and you actually want ‘upn’ or ’email’
$Self->{‘Customer::AuthModule::OpenIDConnect::UID’} = ‘upn’;
Apart from that make sure the customer gets put in the correct group and all is working.
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.