Friday, November 29, 2013

Durchgängiges Enterprise Single-Sign-On per OpenID?

Die zunehmende Verwendung freier, moderner, web-basierte Services ist insgesamt zu begrüßen. Beispiele hierfür sind: DokuWiki, Bug Tracking, vSphere Web Client (VMWare im Browser), WordPress (Blog), RedMine (Project Management), Jenkins (Build Server), GitBlit (SCM), Sonar (Code Quality) und ggf. noch einige Andere die mir gerade nicht einfallen oder die ich nicht kenne.

Diese Services lassen sich in der Regel erstaunlich gut miteinander kombinieren (z.B. RedMine - GitBlit - Jenkins - Sonar), aber natürlich lassen sie sich auch immer einzeln betreiben. Zu diesem Zweck bringt daher jeder Service seine eigene Nutzerverwaltung mit. In der Regel lässt sich diese über ein LDAP-Plugin auf unser gemeinsames Active Directory umkonfigurieren, sodass die redundante Verwaltung von Nutzern/Gruppen vermieden werden kann. Man kommt also mit einem einzigen Zugang jeden Service nutzen (sofern die Rechte das zulassen). Das ist schon ganz prima.

Je mehr Services hinzukommen, umso wünschenswerter wird jedoch eine unternehmensweite Single-Sign-On-Lösung (SSO). Zurzeit muss man hier seine Login-Daten bei jedem Service erneut eingeben. SSO bedeutet prinzipiell, dass man sich nur noch einmal selbst authentifizieren muss. Besucht man eine Service-Website wird der entsprechende Login (die Authentifizierung) automatisiert abgewickelt. Ein Kollege hat für das DokuWiki den sog. Kerberos-basierten Ansatz einmal prototypisch realisiert. Mit dem entsprechenden DokuWiki-Plugin für SSO funktioniert das ganz prima. Einziger kleiner Schönheitsfehler ist dass es nicht ganz ohne Modifikation am Client ging: Für den Firefox-Browser musste dazu per Gruppenrichtlinie das lokale Firefox-Nutzerprofil verändert werden.

Von dem Kollegen angesprochen habe ich zwischendurch bzgl. ähnlicher Kerberos-Lösungen für die anderen mir bekannten Services recherchiert. Ergebnis: SSO wird mittlerweile eher per OpenID unterstützt, eine Authentifizierungslösung die im weltweiten Netz zunehmend Anklang findet. Als weitere Schwierigkeit empfand ich die Heterogonität der Web-Server. Der gut bekannte Weg mit einem Apache 2 Web-Server steht gegenüber, dass die meisten Services meist einen eigenen kleinen Web-Server mitbringen. Die Kerberos-Ticket-Lösung da hinein zu konfigurieren ist mal einfach, mal aufwendig und mal fast unmöglich.

Für unser Unternehmen ist es natürlich völlig ausgeschlossen, einen externen OpenID-Server zur Athentifizierung zu verwenden. Also habe ich noch ein wenig weiter nach Unternehmenslösungen recherchiert, in denen ein eigener OpenID-Server einem existierenden LDAP/Active Directory-Server als sog. "Proxy" vorgeschaltet werden kann. Zum Glück gibt es da noch nicht so viel sodass ich schnell fündig wurde:
  • Der bekannte Hersteller Atlassian bietet mit Crowd eine kommerzielle, Rund-um-glücklich-Authentifizierungslösung an die als Proxy für alle gängigen Protokolle dienen kann.
  • Dann gibt es noch OpenID-LDAP, eine auf den ersten Blick schlankere und besser auf das o.a. Problem passende Lösung. Zudem noch frei. Die Entwicklung scheint allerdings schon seit Beginn 2011 abgeschlossen zu sein.
Das scheint mir einen Versuch wert. Was meint ihr?

No comments:

Post a Comment