Schlagwörter: , ,

Ansicht von 12 Antwort-Themen
  • Autor
    Beiträge
    • #13792
      Goran Plavsic
      Teilnehmer

        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.

         

      • #13793
        Goran Plavsic
        Teilnehmer

          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.

          • #13796
            Goran Plavsic
            Teilnehmer

              Noch eine Ergänzung, folgendes sehe ich noch auf dem Docker Container während dem Login:

          • #13799
            Stefan Rother
            Administrator

              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

            • #13800
              Goran Plavsic
              Teilnehmer

                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.

              • #13803
                Sven Oesterling
                Administrator

                  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.

                • #13805
                  Stefan Rother
                  Administrator

                    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

                     

                  • #13807
                    Goran Plavsic
                    Teilnehmer

                      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.

                       

                    • #13808
                      Sven Oesterling
                      Administrator

                        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

                      • #13814
                        Goran Plavsic
                        Teilnehmer

                          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?

                          • #13815
                            Sven Oesterling
                            Administrator

                              Ja, es werden keine Kundenbenutzer angelegt, kundenseitig ist es nur Authentifizierung. Allerdings kann ja z.B. ein AD angebunden werden, als Kundenbackend.

                          • #13816
                            Goran Plavsic
                            Teilnehmer

                              Okey, danke für die Rückmeldung.

                            • #13865
                              Stefan Rother
                              Administrator

                                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:

                                https://doc.otobo.org/manual/admin/10.1/en/content/communication-notifications/postmaster-mail-accounts.html#pop3-and-imap-oauth2-authentification

                                Big thanks!

                                Stefan

                                Team OTOBO

                                 

                              • #15347
                                David Moufarrege
                                Teilnehmer

                                  Ich habe v10.1 installiert kann aber nichts in den Dokus ueber OpenIDConnect finden.

                                  Ich moechte die Kundendaten ueber eine Schnittstelle mit AzureAD ins Otobo bringen und auch so einlogen.

                                • #15766
                                  Alexandru Mateescu
                                  Teilnehmer

                                    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.

                                     

                                Ansicht von 12 Antwort-Themen
                                • Du musst angemeldet sein, um auf dieses Thema antworten zu können.