Univention Bugzilla – Bug 14593
Einmal authentifizieren für UDM und UMC
Last modified: 2012-07-06 12:34:53 CEST
Ein Partner hatte folgenden Vorschlag: Die Weboberfläche der UMC oder des UDM so aufzurufen, daß die Authentifizierung "durchreichen" kann? Also ich möchte einen "angemeldet" Zustand auf der Weboberfläche haben (habe ich schon) und von dort aus die UMC oder den UDM so aufrufen, daß ich nicht nochmals nach der Authentifizierung gefragt werde... Ticket Nr.: 2009052510000098
*** This bug has been marked as a duplicate of bug 3341 ***
*** Bug 3341 has been marked as a duplicate of this bug. ***
Ggf. hilft OpenID in diesem Zusammenhang: Bug #10412.
Für die Umsetzung des Single-Sign-On wird derzeit noch das Klartext-Passwort in UDM/UMC benötigt, da dies u.a. für zusätzliche LDAP-Verbindungen usw. verwendet wird. OpenID kann deshalb nicht für die Authentifizierung nicht verwendet werden, da das Passwort vom Browser nur an den OpenID-Provider übermittelt wird. Die Relying-Component bekommt vom OpenID-Provider nur zurückgeliefert, ob der Benutzer sich korrekt authentifiziert hat. Derzeit wird das Passwort nur innerhalb des UMC/UDM-(Kind)Prozesses zwischengespeichert und nicht auf die Festplatte geschrieben. Lösungen wie WebAuth führen die Authentifizierung direkt im Apache vor/während der HTTP-Kommunikation durch. WebAuth holt für den Benutzer mit den übergebenen Credentials ein Kerberosticket und schickt dieses als Cookie an den Browser zurück. Nachteile bei der WebAuth-Lösung: - kein Klartextpasswort (siehe oben) - Ticket kann für max. Cookiegröße zu groß sein - Einige Browser (z.B. IE7) haben gelegentlich Probleme mit anderen Host-/Domänennamen, für die die Cookies eigentlich auch freigegeben sein sollten - Auf dem Rechner wo UMC/UDM ausgeführt werden, liegt als User www-data ggf. ein gültiger Ticketcache auf der Festplatte (gültiges Ticket für z.B. Domänenadmin, das von jedem PHP-Prozess ausgelesen werden kann) Angedachte Lösung (UMC --> UMC/UDM): - Benutzer klickt auf speziellen Button in UMC-Modul - Browser schickt AJAX-Request an das UMC-Modul - UMC-Modul baut HTTPS-Verbindung zu UDM auf, meldet den Benutzer über UDM-Login-Interface an und extrahiert aus der Antwort die UDM-SessionID - AJAX-Request liefert die SessionID zurück - Browser sendet POST-Request mit SessionID an UDM und öffnet dafür ein neues Fenster Angedachte Lösung (UDM --> UMC/UDM): - Benutzer klickt auf Button in UDM - Browser schickt normalen Request an den UDM - UDM baut HTTPS-Verbindung zu UDM auf, meldet den Benutzer über UMC-Login- Interface an und extrahiert aus der Antwort die UMC-SessionID - UDM sendet "gleiche Seite" noch einmal an Browser zurück, die diesmal zusätzlich ein Formular+SessionID für POST-Request enthält - Browser sendet POST-Request mit SessionID an UMC und öffnet dafür ein neues Fenster Vorteil: - Klartext-Passwort wird nicht noch einmal an Browser gesendet - Es liegt kein gültiges Kerberos-Ticket für www-data lesbar auf der Festplatte Nachteil: - ggf. Wartezeit durch Anmeldeverbindung zwischen UDM und UMC ==> Ladeanimation in UMC möglich - Verbindung zwischen UDM und UMC notwendig (ggf. Probleme mit Firewall) - Passwort wird zwischen UDM und UMC über HTTPS im Klartext ausgetauscht; eine Prüfung des Aufrufenden, ob man wirklich mit der/dem gewünschten UMC/UDM kommuniziert, ist nach derzeitigem Framework nicht möglich ==> bei einfachem Redirect ohne Anmeldung würde der Benutzer das Passwort an UMC übergeben, ohne dass eine Verifikation möglich ist, so dass es auf das gleiche Problem hinausläuft Notwendige Anpassungen: - Anmeldung an UMC/UDM ohne vorheriges Erstellen einer Session (Sessionerstellung und Anmeldung finden in einem Schritt statt) ==> Patch ist angehängt - UMC-Redirect zu UDM/UMC - Implementierung eines neuen UMC-Redirect-Widgets (beim Klick AJAX-Request an UMC absetzen und zurückgegebene Antwort verwenden, um POST-Request in neuem Fenster abzuschicken) ==> Aufwand: 8h - Implementierung eines internen UMC-Kommandos in modules/univention/management/console/protocol/session.py, das den Sessionaufbau und Anmeldung an UDM/UMC durchführt und die SessionID zurückliefert. Weiterhin Anpassung von ajax.py, um internes UMC-Kommando ausführen zu können. (Prototyp für Sessionaufbau siehe Anhang) ==> Aufwand: 5h - UDM-Redirect zu UDM/UMC - Implementierung eines Buttons, der beim Auslösen den Sessionaufbau und Anmeldung an UDM/UMC durchführt, eine Seite mit "gleichem" Inhalt sowie zusätzlich ein verstecktes HTML-Formular/Javascript mit SessionID enthält, das nach dem Laden der Seite das Formular in einem neuen Fenster absendet. ==> 8-10h
Created attachment 2252 [details] Neue Session in python erstellen
Created attachment 2253 [details] Presession-Login for UDM and UMC
(In reply to comment #4) Aus meiner Sicht ist der Vorschlag gut.
Im Zuge von Bug 18627 ("Update Available"-Msg beim Login im UDM) wurde ein Single-Sign-On von UDM zu UMC implementiert (wie oben bereits beschrieben). Der UDM wurde daher um das Modul "modredirect" erweitert, das für die Anmeldung und Weiterleitung zu anderen Anwendungen zuständig ist. Vor dem Aufruf von modredirect muss in self.save hinterlegt werden, auf welchem Host die UMC-Session mit welchen Parametern gestartet werden soll: self.save.put('redirect_host', 'master10.univention.qa') self.save.put('redirect_args', ['init_umccmd=update/overview']) Für die Anmeldung verwendet modredirect immer eine HTTPS-Verbindung sowie die Credentials und Sprache, die der Benutzer bei der UDM-Anmeldung angegeben hat. Bei der Weiterleitung zur UMC wird das gleiche Protokoll (HTTP/HTTPS) wie aktuell zum UDM verwendet. Ist die Session erstellt, wird der Benutzer per Javascript zur UMC weitergeleitet. Dafür öffnet sich ein neues Fenster. Im alten Fenster wechselt der UDM nach 3 Sekunden zurück zur UDM-Startseite. Voraussetzungen: - der UDM kann HTTPS-Verbindungen zur UMC aufbauen (in Bug 18627 ist das der gleiche Rechner); sollte eine Firewall/Routing/DNS/... die direkte Verbindung verhindern, kann vom UDM keine UMC-Session erstellt werden! - der Browser erlaubt Javascript und ggf. Popups-Windows für den UDM; ohne Javascript erhält der Benutzer einen Link über den er zur UMC kommt (und sich manuell anmelden muss); ohne erlaubte Popup-Windows kehrt der UDM nach wenigen Sekunden wieder zurück zur UDM-Startseite; der Benutzer erhält je nach Browser eine/eine kurz sichtbare/keine Nachricht bzgl. des unterdrückten Popups. Über die UCR-Variable directory/manager/web/singlesignon/umc=no kann das SingleSignOn deaktiviert werden, falls dies z.B. aufgrund von Firewall/Routing/DNS/... permanent nicht möglich ist. Es wird dann ein direkter Link zur UMC angezeigt. Verwendung von SingleSignOn in anderen Anwendungen: =================================================== Das neue Python-Modul univention-webui/modules/unisignon.py enthält jetzt eine Klasse "SignOnRedirect", die bei der Erstellung einer Session und ggf. eines Redirects des Browsers zu dieser neuen Session unterstützt. Bei der Instantiierung der Klasse können Hostname, Benutzername, Passwort, Sprache, Anwendung (UDM/UMC), Protokoll (HTTP/HTTPS) sowie weitere GET-Argumente übergeben werden. Das SignOnRedirect-Objekt erstellt eine Session bei der angegebenen Anwendung und kann dann Session-ID und/oder Javascript-Code für den Redirect zurückgeben. sso = unisignon.SignOnRedirect('master.test.qa', 'Administrator', 'univention', language='de', application='UMC', protocol='https', arguments=['init_umccmd=update/overview']) try: sso.createSession() except: print 'Hat nicht funktioniert' print 'SessionID:', sso.getSessionID() print 'Javascript1:', sso.getJavascript() print 'Javascript2:', sso.getOnLoadJavascript() print 'Javascript3:', sso.getOnLoadJavascriptTag() Der Javascript1-Code kann direkt in z.B. ein onClick="" eingefügt werden und setzt voraus, dass auf der aktuell angezeigten Seite bereits ein Formular mit dem Namen "redirectsignon" existiert (siehe univention-webui/www/include/container.inc). Das Javascript fügt dort die Session-ID und die Ziel-URL ein und schickt das Formular ab, so dass der Browser augenblicklich zu der angegebenen Anwendung umgeleitet wird und der Benutzer sich nicht neu anmelden muss. Wird im Formular "target='_blank'" gesetzt, kann die Anwendung auch in einem neuen Fenster geöffnet werden. Formularbeispiel: <form name="redirectsignon" target="_blank" id="redirectsignon" method="post" enctype="multipart/form-data" action="/"> <input type="hidden" name="usrinput[0]" value="" /> <input type="hidden" name="session_id" value="" /> <input type="hidden" name="is_js" value="1" /> </form> HINWEIS: Bei der Verwendung von HTTPS muss der angegebene Hostname mit dem CommonName im SSL-Zertifikat übereinstimmen, da sonst die HTTPS-Verbindung nicht aufgebaut wird. Daher kann i.d.R. os.environ["HTTP_HOST"] nicht verwendet werden, wenn der Benutzer z.B. eine URL mit IP-Adresse verwendet hat!
Changelog-Eintrag ist comitted
Die Variable "redirect_host" wurde nach "redirect_host_session" umbenannt. Optional kann jetzt auch die Variable "redirect_host_browser" gesetzt werden, die für die Weiterleitung des Browsers verwendet wird. So kann für den Aufbau der Session der notwenige FQDN verwendet werden, während im Browser ein URL mit IP-Adresse genutzt wird. self.save.put('redirect_host_session', 'master10.univention.qa') self.save.put('redirect_host_browser', '10.200.18.10')
Funktioniert über http / https, auch der UMC-Link bei den Rechnen funktioniert.
In der syslog tauchen diese Debug-Meldungen auf: Aug 10 00:02:28 master python2.4: modredirect: sending SSO request Aug 10 00:02:36 master python2.4: modredirect: SSO request done - no error
Kannst du die Changelog-Einträge (Bug #14593 Bug #19232) noch zusammenführen?
*** Bug 19338 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > In der syslog tauchen diese Debug-Meldungen auf: > > Aug 10 00:02:28 master python2.4: modredirect: sending SSO request > Aug 10 00:02:36 master python2.4: modredirect: SSO request done - no error Der Loglevel wurde von ERROR auf WARN gesenkt. (In reply to comment #13) > Kannst du die Changelog-Einträge (Bug #14593 Bug #19232) noch zusammenführen? Done.
Ok
UCS 2.4 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".