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 mit den letzteren zwei Punkten, der Einrichtung von Apache und Plone. Es wird vorausgesetzt, dass der Kerberos-Server bereits existiert und korrekt konfiguriert ist. Ferner muss der Server, auf dem Apache läuft, als Kerberos-Client vorkonfiguriert sein. As letztes muss auch das Betriebssystem des Benutzers der Website so konfiguriert sein, dass der Logon für den Benutzer bereits über Kerberos abgewickelt wird.

Unser Beispielsystem setzt auf einem Windows-Server auf, der Benutzerdaten mit Hilfe von Active Directory verwaltet und als Kerberos-Server konfiguriert ist. Der Apache-Server läuft unter Linux und agiert als Kerberos-Client. Die Website-Besucher nutzen Windows mit Internet Explorer und melden sich an ihrem Computer bzw. an ihrem Citrix-Client mit Benutzerdaten an, die in ActiveDirectory vorgehalten sind. 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.

Apache-Konfiguration

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. 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.

In der unten gezeigten Apache-Konfiguration lauscht die Zope-Instanz auf IP 10.0.0.2 Port 8080, und Apache auf 10.0.0.1 Port 80. Das Plone-Portal befindet sich in der Zope-Instanz unter dem Pfad /portal. In Kerberos wird der Realm-Wert MYDOMAIN verwendet.

<VirtualHost 10.0.0.1:80>
  ServerAdmin webmaster@mydomain.com
  ServerName intranet.mydomain.com

  <Location />
    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
  </Location>

  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}]
</VirtualHost>

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. Es stellt ein Plugin für den PluggableAuthService zur Verfügung, welcher in Plone zur Authentifizierung von Benutzern verwendet wird.

Nach Installation von Products.WebserverAuth und Neustart der Plone-Instanz kann nun im acl_users-User Folder der Plone-Instanz ein neues Plugin des Typs WebServerAuth-Plugin erstellt werden. 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.

Das neue Plugin muss in unserer Beispielkonfiguration nur für zwei Dienste aktiviert werden, nämlich 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.

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:

<dtml-var REQUEST>

Dort muss im Bereich environ ein Header namens HTTP_X_REMOTE_USER sichtbar sein, der den vollen Kerberos-Loginnamen des Benutzers enthält. Ist er es nicht, wurde der Login nicht korrekt von Apache weitergegeben.