AAI in Aktion
Web Single Sign-On an der Uni Wien

von Peter Schober (Ausgabe 07/2, Juni 2007)

"Improving security and usability at the same time. How often do you get a chance to do that?"¹⁾

Wie bereits in der Comment-Ausgabe vom Oktober 2006²⁾ angedeutet, ist der ZID seit einiger Zeit damit beschäftigt, seine Authentifizierungs- und Autorisierungs-Infrastruktur (AAI, siehe untenstehender Kasten) dahingehend auszubauen, dass sie auch von anderen Organisationseinheiten der Universität Wien verwendet werden kann. Als erstes "sichtbares" Ergebnis dieser Arbeiten wird voraussichtlich noch heuer ein Web Single Sign-On(WebSSO)-System in Betrieb genommen werden.

Dabei handelt es sich um eine zentrale Komponente, die allen teilnehmenden Webanwendungen die nötige Authen­tifi­zierung bei Zugriffen auf geschützte Ressourcen abnimmt: Personen, die sich bereits an einem bestimmten System authentifiziert haben, werden als solche erkannt und bis zum Ablauf einer definierten Zeitspanne (z.B. acht Stunden) nicht wieder zur Authentifizierung aufgefordert.³⁾ Dabei kommt es zur oben erwähnten, sich nur selten ergebenden Gelegenheit, einerseits die Sicherheit der beteiligten Systeme zu erhöhen und gleichzeitig die Benutzer­freundlichkeit zu verbessern - eine Gelegenheit, die wir natürlich nicht auslassen wollen.

Der Nutzen eines WebSSO-Systems beginnt bereits bei der zweiten teilnehmenden Anwendung und steigt mit jeder weiteren. Es ist nicht nötig, sofort alle Webanwendungen im "Einzugsbereich" des WebSSO-Systems umzustellen, was den Einstieg in diese Technologie und den sukzessiven Auf­bau eines solchen Systems massiv erleichtert. Neben allen interessierten BenutzerInnen von Webapplikationen (also Anwendungen, die lediglich einen Standard-Webbrowser benötigen - Online-Datenbanken, Wikis, Diskussionsforen usw.) wendet sich dieser Artikel daher vor allem an die BetreiberInnen von Webapplikationen in allen Bereichen der Universität Wien.

Mehr Sicherheit

Da UserID und Passwort bei einem WebSSO-System - unabhängig von der Anzahl der benutzten Anwendungen - nur einmal an den zentralen Authentifizierungsserver übertragen werden, reduziert sich die Zahl der im Netzwerk übertragenen Passwörter insgesamt. Wenn Passwörter gar nicht erst elektronisch übertragen werden, können sie auch nicht abgehört, aufgezeichnet oder manipuliert werden. Etwaige Fehler in anderen sicherheitsrelevanten Kompo­nenten (von der Firewall bis zum SSL-gesicherten Web­browser) verlieren also einen Teil ihrer potentiellen Aus­wirkungen. Ein wichtiger Faktor, denn einmal "ausgekommene" - d.h. in fremde Hände geratene - Passwörter sind nur schwer wieder "einzufangen": Die missbräuchliche Ver­wendung wird oft nicht sofort entdeckt und kann als Aus­gangspunkt für weitere unautorisierte Zu- oder Angriffe auf andere Systeme dienen.

Neben der Anzahl der durchs Netz geisternden Passwörter reduziert ein WebSSO-System auch die Anzahl der Kompo­nenten, die direkt mit dem Passwort in Berührung kommen müssen: Nicht jede Webapplikation, nicht jeder Webserver muss künftig das Passwort zur Überprüfung entgegennehmen, daher sind unautorisierte Zugriffe auf diese Kompo­nen­ten meist weniger gravierend. Das verringert die sicherheitstechnischen Anforderungen an die teilnehmenden Systeme und auch die Folgen ihrer etwaigen Sicherheits­lücken für alle anderen Systeme.

Mehr Benutzerfreundlichkeit

Durch die Integration möglichst vieler Webanwendun­­gen in ein zentrales WebSSO-System wird es für die Be­nutzerInnen dieser Anwendungen möglich, sich nur einmal an einer gesicherten Website anzumelden und dann für eine ge­wisse Zeit direkten Zugriff auf alle teilnehmen­den Anwen­dun­gen zu haben (siehe Abb. 1). Dies erleichtert den Ar­beits­alltag, erübrigt das praktische, aber deutlich weniger sichere Spei­chern von UserID/Passwort im Web­browser⁴⁾ und fördert die Verwendung komplexerer Pass­wörter, da diese im Ideal­fall nur einmal pro Tag eingegeben werden müssen.

Wie weiter unten näher beschrieben wird, ist eine weitere Verbesserung der Benutzerfreundlichkeit vor allem auch im vergrößerten Anwendungsbereich der u:net- und Mailbox-Accounts zu sehen, ohne jedoch den BetreiberInnen von Webapplikationen irgendwelche Freiheiten zu nehmen oder neue Sicherheitsrisiken zu schaffen. Verwirrungen mit verschiedenen Accounts und Passwörtern für die verschiedenen Systeme werden dabei deutlich reduziert. Der Help­desk des ZID ist folglich in der Lage, bei Passwort-Proble­men auch dann zu helfen, wenn die betroffenen Anwen­dungen nicht vom ZID betrieben werden - sofern sie das Angebot der zentralen Authentifizierung nutzen.

Einbindung von Institutsanwendungen

Auch wenn wir am ZID überzeugt sind, viele Services besser zentral anbieten zu können⁵⁾, ist klar, dass die diversen Organisationseinheiten der Universität Wien eine Vielzahl von unterschiedlichen Programmen und Werk­zeugen benö­tigen, die der Zentrale Informatikdienst nicht ähnlich effi­zient für alle Mitglieder der Universität zentral betreiben und auf Jahre hinaus professionell unterstützen kann. In der Folge betreiben also viele Institute ihre eigenen Weban­wen­dun­gen, entweder auf PCs unter einem Schreibtisch⁶⁾, auf "richtiger" Hardware im Rahmen des ZID-Serverhousing oder auch direkt auf den zentralen Webservern des ZID. Nur auf den Servern des ZID ist in der Regel auch eine Authentifizierung mit Hilfe der zentral vergebenen UserIDs möglich, da der ZID nicht für die Sicherheit von externen Systemen sorgen kann - was die Ver­wendung von u:net- und Mailbox-Accounts für solche Systeme bisher unmög­-lich machte.

Mit einem zentralen WebSSO-System lassen sich nun prinzipiell⁷⁾ auch Applikationen, die nicht vom ZID betrieben werden, in die zentrale Authentifizierung integrieren. Die aktuellen Implementierungen solcher WebSSO-Systeme funktionieren auf der Ebene des Webservers, der dazu eine Erweiterung laden muss. Sie verlagern die Überprüfung der zugreifenden Identitäten also von der Webapplikation auf den Webserver, der mit dem WebSSO-System Rücksprache hält, ob die zugreifende UserID bereits bekannt ist.

Wenn weder die Applikation noch der Webserver, auf dem sie läuft, in Berührung mit dem Passwort kommt (das nur dem zentralen Authentifizierungsserver zur Überprüfung anvertraut wird), besteht auch keine Missbrauchs- und Fehler­­möglichkeit am institutseigenen Webserver. Das wiederum senkt die Sicherheitsanforderungen an die teilnehmenden Systeme ganz wesentlich - eine einzelne, "außer Kontrolle" geratene Maschine kann die Sicherheit des gesamten SSO-Systems nicht gefährden. Die Integration eines Moduls in den Webserver hat außerdem den Vorteil, dass das SSO-System damit unabhängig von der in der jeweiliger Webanwendung eingesetzten Programmiersprache (Perl, Python, PHP, Java etc.) funktioniert. Auch muss die Er­wei­terung, die die Teilnahme am WebSSO-System ermöglicht, nur einmal pro Webserver konfiguriert werden - es können auf diesem Server aber beliebig viele Applikationen, Seiten oder Verzeichnisse mittels Passwort geschützt (oder auch selektiv von diesem Schutz ausgenommen) werden.

Ein weiterer Grund, Webanwendungen mit einer eigenen, lokalen Benutzerdatenbank zu verknüpfen⁸⁾, ist die Anforde­rung, auch externen Personen ohne u:net- bzw. Mailbox-Account Zugriff auf eigene Ressourcen zu gewähren. Das zentrale Authentifizierungs-System kann klarerweise nur zentral vergebene UserIDs überprüfen; an der Universität werden jedoch zunehmend auch elektronische Identitäten von Personen verwaltet, die traditionell keinen Account erhalten haben (externe DienstleisterInnen, KollegInnen aus anderen Forschungseinrichtungen etc.). Die Verbindungen dieser Personen zur Uni Wien sind ebenso unterschiedlich wie die Berechtigungen, die sie innerhalb der Universität benötigen, um erfolgreich kooperieren zu können. Daher sind die standardisierten und mit vielen Privilegien - von Zugriffen auf geschützte Ressourcen der Universitätsbiblio­thek bis hin zu Speicherplatz am zentralen Storage-System - ausgestatteten u:net- und Mailbox-Accounts für die Au­thentifizierung dieser BenutzerInnen ungeeignet. Mit dem vor kurzem etablierten Konzept der Mailbox Light-Accounts (siehe ArtikelBenutzungsberechtigungen nach Maß) kann jedoch auch für diese "neuen" Benutzer­gruppen eine zentrale Authentifizierung eingerichtet werden, ohne zu viele Privilegien zu verleihen. Über den "Um­weg" der zentral verwalteten Light-IDs können also lokale Webanwendungen auf die zentrale Authentifizierung umgestellt werden und gleichzeitig wie bisher auch externen Per­sonen Zugriff gewähren.

Wie bereits erwähnt, ermöglicht es die Integration in ein zentrales WebSSO-System den BenutzerInnen von dezentralen Webanwendungen, ihr Passwort jederzeit über die ge­wohnten Webmasken des ZID zu ändern und im Problem­fall (Passwort vergessen, Passwort "funktioniert" nicht etc.) beim Helpdesk des ZID schnelle und unbürokratische Un­ter­stützung zu bekommen. Für die BetreiberInnen dieser dezentralen Anwendungen entfällt vor allem auch der Sup­port für das Vergeben oder Neusetzen von Passwörtern, die nur für dieses eine System gelten und allein schon deshalb entweder häufiger vergessen (und daher eventuell aufgeschrieben) oder niemals geändert werden, was beides für die Sicherheit der betroffenen Systeme nicht förderlich ist.

Attributbasierte Autorisierung

Aus dem Umstand, dass zunehmend auch neue Benutzer­kreise ihre individuell limitierten Zugangsberechtigungen am ZID erhalten können, folgt schließlich, dass eine Zu­griffskontrolle über korrekte Authentifizierung allein mög­licher­weise in manchen Fällen nicht mehr ausreichend ist. Ein zentrales Authentifizierungs-Service sollte deshalb auch Mög­lichkeiten bieten, den Zugriff auf ein Service aufgrund weiterer Eigenschaften (oder Attribute) der anfragenden Identität zu erlauben oder zu verweigern.

Auf den zentralen Webservern des ZID ist es schon lange möglich, nur Studierenden oder/und Uni-MitarbeiterInnen Zugriff zu gewähren bzw. diese Beschränkung mit Hilfe so genannter "Authentifizierungsklassen" (basierend auf Ab­fragen in der Personaldatenbank, siehe www.univie.ac.at/ZID/www-htaccess/#institut) noch weiter einzugrenzen - z.B. auf Angehörige einer Fakultät oder eines Instituts. Aus technischen Gründen kann der direkte Datenbankzugriff aber nur für die zentralen Webserver des ZID zur Verfügung gestellt werden, was die Einsatz­mög­lichkeiten dieser attributbasierten Autorisierung stark reduziert. Um auch allen TeilnehmerInnen am künftigen Au­thentifizierungs-System eine detailliertere Selektion der Zu­griffsberechtigten zu erlauben, soll dieses System daher um ein zentrales Autorisierungs-Service ergänzt werden. Dazu ist es notwendig, Standards zum Austausch solcher Da­ten zu definieren und umzusetzen. An der Entwicklung dieser Standards wird bereits gearbeitet; die entsprechenden De­tails werden - ebenso wie alle Einzelheiten zum kommenden Authentifizierungs-System - rechtzeitig im Comment und auf den Webseiten des ZID bekannt gegeben werden.

Zukunftsmusik: Organisations­übergreifendes Single Sign-On

Da die zentralen Fragen des Themenkreises AAI nicht spezifisch für die Uni Wien sind, haben sich schon einige andere Institutionen der höheren Bildung ⁹⁾ damit befasst und auch bereits Konzepte und Anwendungen vorgestellt. Im lokalen und internationalen Diskurs von Forschungs­ein­richtungen und Universitäten wurden Standards entwickelt, die zur Zeit weltweit umgesetzt werden. Dazu gehören Sche­mata zur Verwaltung und zum Austausch von Attribu­ten, die bisher folgende Punkte abdecken:

• Organisationen und Organisationseinheiten,
• Personen und ihre Organisationszugehörigkeit,
• Gruppen (als Zusammensetzung von Personen oder wiederum Gruppen),
• Berechtigungsinformationen bezüglich Personen und Ressourcen,
• Kennzeichnung von Lehrveranstaltungen.

Um die gemeinsam entwickelten Konzepte für die welt­weite wissenschaftliche Gemeinschaft praktisch nutzbar zu machen, wurden wesentliche Komponenten vom Internet2-Konsortium als Freie bzw. Open Source-Software ent­wickelt: Grouper zur Gruppenverwaltung innerhalb einer Organisa­tion, Signet zur gruppenbasierten Verwaltung von Berech­tigungen sowie Shibboleth zum sicheren Austausch dieser In­formationen innerhalb einer Organisation, aber auch zwischen koope­rierenden Universitäten und Forschungs­ein­richtungen. Einerseits werden damit best practices etabliert und vermittelt, die Interessierte für die Verwaltung ihres lokalen Campus übernehmen können, andererseits ergeben sich damit neue Möglichkeiten in der elektronisch vermittel­ten Zusammenarbeit und Lehre, die über die jeweilige Hei­mat­institution hinausreichen.

Dies gilt insbesondere für das Shibboleth-Projekt (http://shibboleth.internet2.edu/), welches das Campus-interne Single Sign-On-Prinzip (Authentifizierung für verschiedene Ressourcen einer Institution an einem ein­zigen gesicherten Ort) um inter-institutionelles Single Sign-On erweitert: Die Authentifizierung findet hierbei ebenso am SSO-System der jeweils eigenen Heimateinrichtung statt, ermöglicht aber durch Austausch von standardisierten Attribu­ten auch die Verwendung von Ressourcen anderer teilnehmender Institutionen. Beispielsweise kann die Universität Wien, sofern gewünscht und vereinbart, damit auch Ange­hörigen anderer Universitäten (ohne gültigen Account an der Universität Wien) Ressourcen zur Verfügung stellen (und umgekehrt) und sich gleichzeitig darauf verlassen, dass nur Personen darauf zugreifen können, die sich an einer Partner-Einrichtung bereits erfolgreich authentifiziert haben und nach gemeinsam beschlossenen Kriterien autorisiert wurden.

Die notwendige Zugriffsbeschränkung für gewisse (z.B. lizenzpflichtige) Ressourcen auf bestimmte Benutzergruppen wird dabei mittels eines vertraglich und technisch zwischen den Kooperationspartnern geregelten Attribut-Austausches rea­lisiert, bei gleichzeitiger voller Wahrung des Daten­schutzes und der Privacy: "Anbieter" von Identitäten (hier die Univer­sitäten als Verwalter der UserIDs) und Anbieter von Ressour­cen (das können auch externe Content Provider sein) schließen sich zu einem Verbund (einer so genannten Federation) zusammen und vereinbaren, welche Daten un­ter welchen Bedingungen innerhalb dieses Verbundes ausgetauscht werden sollen.

Dieses Konzept ermöglicht es beispielsweise auch, einem bestimmten Anbieter nur mitzuteilen, dass die Person, die so­eben eine seiner geschützten Ressourcen aufgerufen hat, sich zuvor erfolgreich z.B. an der Universität Wien authenti­fiziert hat und dort den Status Studierende besitzt, ohne aber ihren Namen oder ihre eMail-Adresse preiszugeben.¹⁰⁾ Dem Anbieter kann auch eine automatisch generierte pseu­donyme Identität für die zugreifende Person über­mittelt werden: Das ermöglicht ihm bei Bedarf eine Wieder­erken­nung (was sinnvoll ist, wenn BenutzerInnen Daten oder Pro­file beim Anbieter speichern können sollen) bzw. kann umgekehrt auch - durch Generieren einer neuen pseu­do­nymen Identität bei jedem Zugriff - das Erstellen von Daten­banken über Benutzerverhalten wirksam verhindern. Dazu kommt noch die Funktion, vor der Weitergabe von persönlichen Informationen die explizite Zustimmung der betroffenen Person einzuholen. Die neuen Koopera­tions­mög­lichkeiten werden also keineswegs mit einem Verzicht auf Privacy oder Datenschutz erkauft - aufgrund der poten­tiellen anonymen oder pseudonymen Nutzung gilt sogar eher das Gegen­teil: Ein solches System ermöglicht verbesserten Datenschutz, erhöhte Sicherheit, weniger Auf­wand für BenutzerInnen und ApplikationsbetreiberInnen sowie neue Kooperationen durch den interoperablen Zu­sam­men­schluss von lokalen Authentifizierungs- und Auto­risierung­s­strukturen an Universitäten und anderen For­schungs- und Bildungseinrich­tungen.

So utopisch das alles klingen mag, so sehr haben sich die ersten Umsetzungen dieser Konzepte bereits international be­währt. Nicht zuletzt die KollegInnen vom Schweizer Wis­senschaftsnetz SWITCH haben gezeigt, wie eine gemein­same Nutzung von im ganzen Land verstreuten eLearning-Systemen mit jeweils lokalen Benutzerdatenbanken erfolgreich möglich ist (siehe www.switch.ch/aai/), und sind damit Vorreiter zahlreicher existierender und geplan­ter Federations weltweit. Neben der Schweiz betreiben oder entwickeln zur Zeit auch Australien, Dänemark, Deutsch­land, Finnland, Frankreich, Norwegen, Schweden und Groß­britannien Shibboleth-basierte nationale Federations. Damit nicht genug, sind bereits erste Zusammenschlüsse solcher nationalen Federations - so genannte Confederations - im Entstehen, etwa für den Bereich des Grid-Computing.

Der ZID der Universität Wien wird daher im Zuge seiner lokalen Aktivitäten um eine verbesserte AAI auch mit den anderen Teilnehmern am österreichischen Wissenschaftsnetz ACOnet zusammenarbeiten, um die vielfältigen Anwen­dungs­möglichkeiten solcher Systeme im Laufe der Zeit so weit wie möglich auszuschöpfen.