Single Sign On mit Kerberos =========================== Um eine lauffähige Kerberos-Umgebung sowie eine Plone bzw. Zope-Website mit Single Sign On zu erhalten, sind Anpassungen auf mehreren Ebenen notwendig: #. Einrichtung eines zentralen Kerberos-Servers (KDC, Key Distribution Center) #. Einrichtung des Betriebssystems des vorgelagerten Webservers, sodass Kerberos-Tickets vom KDC bezogen werden können #. Einrichtung des Betriebssystems des Website-Benutzers, sodass es beim Maschinen-Login Kerberos-Tickets vom KDC bezieht #. Einrichtung des vorgelagerten Webservers, in diesem Falle Apache #. Installation eines Zope-Zusatzproduktes, damit der User Folder die vom Webserver zusätzlich zur Verfügung gestellten Authentifizierungsdaten auswertet Dieses Dokument befasst sich lediglich mit der serverseitigen Einrichtung. Das Betriebssystem des Benutzers der Website muss also bereits so konfiguriert sein, dass der Logon für den Benutzer bereits über Kerberos abgewickelt wird. Unser Beispielsystem setzt auf einem Linux-Server auf, der als Kerberos-Server konfiguriert wird. Der Apache-Server läuft ebenfalls unter Linux und agiert als Kerberos-Client. Beim Anmeldevorgang wird automatisch ein Kerberos-Ticket bezogen, welches die spätere Abwicklung der Kerberos-Authentifizierung zur Website ermöglicht. Das Einrichten einer solchen Konstellation ist auf dem Internet vielfach beschrieben, siehe auch die Weiterführenden Links am Ende des Dokumentes. Installation des ``mod_auth_kerb``-Authentication-Modul ======================================================= Für Apache wird das Zusatzmodul ``mod_auth_kerb`` benötigt, welches unter Linux mit den Bordmitteln des Betriebssystems installiert werden kann, wie z.B. ``apt-get`` unter Debian und Ubuntu oder ``yum`` unter RedHat-Systemen:: # apt-get install libapache2-mod-auth-kerb oder:: # yum install mod_auth_kerb Falls das Modul anschließend nicht automatisch geladen wird, kann dies manuelle geschehen mit:: # LoadModule auth_kerb_module /usr/lib/apache2/modules/mod_auth_kerb.so Je nach OS muss der Pfadname des Moduls noch angepasst werden. Da die Header der HTTP-Anfrage von Apache modifiziert werden, muss auch ``mod_headers`` installiert sein. In unserer Beispielkonfiguration wird Apache als Proxy für Plone verwendet, womit auch ``mod_rewrite`` und ``mod_proxy`` aktiv sein müssen. Erstellen eines *Service Principal* =================================== Der *Service Principal* kann erstellt werden mit folgendem kadmin-Befehl:: # kadmin -p bofh/admin -q "addprinc -randkey HTTP/www.example.com" Erstellen einer Schlüsseltabelle (``keytab``) ============================================= Ein keytab ist eine Datei zum Speichern der Schlüssel für einen oder mehrere Kerberos-Prinzipals. ``mod_auth_kerb`` benötigt diese Tabelle um den oben erstellten Service Principal nutzen zu können. #. Die Schlüsseltabelle kann mit ``kadmin`` erstellt werden:: # kadmin -p bofh / admin -q "ktadd -k /etc/apache2/http.keytab HTTP / www.example.com" oder auf RedHat-basierten Systemen im Pfad ``/etc/httpd/http.keytab``. Die ``-k``-Option spezifiziert den Pfadnamen der ``keytab``-Datei, die erstellt wird sofern sie noch nicht existiert. Anschließend muss der Eigentümer so geändert werden, dass der Apache-Prozess darauf zugreifen kann:: # chown www-data /etc/apache2/http.keytab oder auf RedHat-basierten Systemen:: # chown apache /etc/httpd/http.keytab Um zu überprüfen, ob der Schlüssel korrekt in die ``keytab`` eingetragen wurde, sollten wir uns als *Service Principal* authentifizieren und uns anschließend das resultierende Granting-Ticket mit ``klist`` anzeigen lassen:: # kinit -k -t /etc/apache2/http.keytab HTTP/www.example.com # klist Konfigurieren des Apache-Webservers =================================== In der unten gezeigten Apache-Konfiguration lauscht die Zope-Instanz auf IP ``10.0.0.2`` am Port ``8080``, und Apache auf ``10.0.0.1`` am Port ``80``. Das Plone-Portal befindet sich in der Zope-Instanz unter dem Pfad ``/portal``. In Kerberos wird der Realm-Wert ``MYDOMAIN`` verwendet:: ServerAdmin webmaster@mydomain.com ServerName intranet.mydomain.com AuthName "Intranet" AuthType Kerberos KrbAuthoritative on KrbAuthRealms MYDOMAIN KrbServiceName HTTP Krb5Keytab /etc/krb5.keytab KrbMethodNegotiate on KrbMethodK5Passwd off KrbSaveCredentials on require valid-user RequestHeader set X_REMOTE_USER %{remoteUser}e RewriteEngine On RewriteRule ^/(.*) http://10.0.0.2:8080/VirtualHostBase/http/intranet.mydomain.com:80/portal/VirtualHostRoot/$1 [L,P,E=remoteUser:%{LA-U:REMOTE_USER}] Um diese Konfiguration nun verwenden zu können, muss der Apache-Webserver neu gestartet werden mit:: # service apache2 force-reload Wie man erkennen kann, reicht das Einfügen der ``mod_auth_kerb``-Direktiven in eine ``Location``-Direktive. Kerberos wird als Authentifizierungsmechanismus festgelegt, und es wird eine positive Identifikation des Benutzers zum Zugriff erfordert (require valid-user). Wichtig hierbei ist das Abschalten von ``KrbMethodK5Passwd``, um eine Abfrage und Übertragung des Kerberos-Logins zwischen Browser und Apache zu verhindern. Es wird ausschliesslich die Negotiate-Methode zugelassen (``KrbMethodNegotiate``), bei der keine Logins über das Netz geschickt werden, sondern nur Kerberos-Ticket-Informationen. Die Plone-Instanz selber muss kein Kerberos verstehen. Wie man in der Apache-Konfiguration ersehen kann, wird der ermittelte Benutzername in einen zusätzlichen HTTP-Header ``X_REMOTE_USER`` geschrieben und so weitergeleitet. Beim Einsatz von ``mod_auth_kerb`` in Apache muss man beachten, dass man Kerberos-Authentifizierung nicht mit anderen Authentifizierungen kombinieren kann. Es ist nicht möglich, bei erfolgloser Kerberos-Authentifizierung auf z.B. normale Basic Auth zurückzufallen. Ferner ist es nicht möglich, diese Authentifizierung optional zu gestalten, sodass auch bei erfolglosem Kerberos- Versuch der Besuch der Website gestattet wird. Das heisst, man kann auf einem für Kerberos-Authentifizierung eingerichteten Hostnamen keine Besucher bedienen, die anonym durchgelassen werden sollen oder die auf andere Weise authentifiziert werden können. Plone-Konfiguration =================== #. Auf der Plone-Seite reicht die Installation und Konfiguration eines Zusatzproduktes, welches den von Apache gesetzten zusätzlichen HTTP-Header versteht und auswertet. Für unser Beispiel benutzen wir `Products.WebserverAuth `_ (siehe auch Weiterführende Links unten). Das Produkt kann als Python Egg einfach in einen bestehenden Plone-Buildout eingebunden werden:: [instance] … eggs = … Products.WebServerAuth #. Nachdem das Buildout-Skript durchlaufen und die Instanz neu gestartet wurde, sollte in portal-url → site setup → Add-on Products *WebServerAuth* aktiviert werden können. #. Damit wird im ``PluggableAuthService`` des Portals das ``WebServerAuth``-Plugin zur Verfügung gestellt. Von der Standardkonfiguration auf dem Reiter *Options* wurde nur in einem Punkt abgewichen: Wir haben die Option ``"Only users with a pre-existing Plone account"`` gewählt, um nur solche Kerberos-Benutzer durchzulassen, die auch in der Plone-Instanz bekannt sind. Zudem muss das neue Plugin in unserer Beispielkonfiguration nur für zwei Dienste aktiviert werden, nämlich für ``Authentication`` und ``Extraction``. ``Extraction`` ist für das Ermitteln von Login-Daten aus der hereinkommenden HTTP-Anfrage zuständig. Da jeder Zugriff über Apache automatisch den vom neuen Plugin ausgewerteten HTTP-Header enthält und die Verarbeitung dieses Headers schnell und einfach ist, setzen wir das neue Plugin als erstes aktives Extraction-Plugin ein. ``Authentication`` nimmt die im ersten Schritt ermittelten Login-Daten und prüft, ob ein Benutzer mit diesen Login-Daten bekannt ist und angemeldet werden kann. Da in unserem Beispielszenario die Benutzer in ActiveDirectory vorgehalten werden und auch Plone dort die Benutzerdaten sucht, ist das neue Plugin als letztes aktives Authentication-Plugin geführt. Somit wird am bisherigen Verfahren vor dem Einsatz von Kerberos am wenigsten geändert. #. Der Abmelden-Link des Plone-Portal (ZMI → Plone-Portal → portal_actions → Benutzer → Logout) sollte auf eine spezielle Logout-Seite umleiten, die z.B. den folgenden Inhalt trägt: *»Sorry, Sie müssen Ihren Web-Browser schließen um sich von diesem Portal abzumelden.«* Hierzu können Sie auch das ``logged_out``-Template entsprechend anpassen. #. Das Login-Portlet sollte nicht angezeigt werden. #. Der *Password ändern*-Link (z.B. in ZMI → Plone-Portal → portal_controlpanel) sollte ebenfalls nicht mehr angezeigt werden. Zusammenfassung =============== Nach den oben genannten Konfigurationsschritten sollte ein korrekt auf Windows angemeldeter und in Plone bekannter Benutzer bei Besuch der Plone-Instanz sofort und ohne Umweg über die Login-Maske angemeldet sein. Das ist schnell erkennbar daran, dass z.B. kein Login-Link mehr angeboten wird, wohl aber eines auf die eigenen Inhalte und Präferenzen. Bei Problemen ist besonders das Dokument `Using mod_auth_kern and Windows 2000/2003 as KDC `_ hilfreich. Es erklärt in kleinen Schritten, wie die Konfiguration geprüft und Fehler ausgemerzt werden können. Auf der Plone-Seite kann man die korrekte Weitergabe der Login-Informationen sehr einfach mit einer simplen DTML-Methode testen, die die Werte des ``REQUEST`` ausgibt:: Dort muss im Bereich environ ein Header namens ``HTTP_X_REMOTE_USER`` sichtbar sein, der den vollen Kerberos-Login-Namen des Benutzers enthält. Ist er es nicht, wurde der Login nicht korrekt von Apache weitergegeben. .. seealso:: - `Single Sign On with Active Directory `_ - `How to set up a Kerberos Server under Linux `_ - `Step by step guide to Kerberos 5 interoperability `_ - `mod_auth_kerb Dokumentation `_