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?"1)

Wie bereits in der Comment-Ausgabe vom Oktober 20062) 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.

Was ist AAI?

AAI steht für Authentifizierungs- und Autorisierungs-Infrastruktur:

  • Authentifizierung ist die Überprüfung elektro­ni­scher Identitäten (UserIDs), basierend auf physiologischen Eigen­heiten (Fingerabdruck, Stimm­muster), Gegenständen, über die verfügt wird (Mo­bil­tele­fon, Chipkarte), Geheim­nissen (PIN-Code, Passwort) oder beliebigen Kombinationen dieser Faktoren. Am häufigsten ist immer noch die Au­then­tifizierung mittels UserID und Passwort. Mit der Wahl eines ent­sprechenden Passworts (siehe www.univie.ac.at/ZID/passwort#sicher) ist diese Methode auch für die meisten elektronischen Vorgänge aus­reichend sicher - und im Gegensatz zu Methoden, die den Besitz von bestimmten Ge­gen­ständen voraussetzen, nicht durch teure An­schaf­fung und Ver­waltung bzw. Probleme bei Verlust dieser Gegen­stände belastet.
  • Autorisierung bezeichnet das Überprüfen der Zu­griffsberechtigungen von bereits authentifizierten Identitäten in Bezug auf bestimmte Ressourcen bzw. Dienste, meist anhand der Zugehörigkeit der Identität zu einer berechtigten Gruppe oder Rolle. Dabei könnten z.B. auch zeitliche (Labornutzung "wochentags bis 18 Uhr") oder quantitative (Bestel­lungen "bis 10000 Euro") Einschränkungen berücksich­tigt werden.
  • Infrastruktur verweist auf den grundlegenden, zen­tralen Charakter, den eine AAI in der elektronisch vermittelten Welt zunehmend spielt

Die wesentlichen Elemente einer Authentifizierungs- und Autorisierungs-Infrastruktur sind in der Regel

  • Identity Management, also die Vergabe und Ver­waltung von UserIDs, deren verschiedenen Zu­stän­den und Wandlungen im universitären Uni­ver­sum, bis zu ihrem Ablauf,
  • Verzeichnisdienste (z.B. LDAP, siehe http://comment.univie.ac.at/06-3/29/) und
  • zentralisierte Authentifizierungs- und Autori­sierungs-Services.

Dieser Kernbereich einer AAI wird auch als Core Middleware bezeichnet, da die Bestandteile selbst in der Regel für die BenutzerInnen nicht sichtbar sind: Middleware sitzt sozusagen zwischen dem Netzwerk und den Anwendungen und "hilft Organisationen, Personen mit Ressourcen zu verbinden" (JISC, www.jisc.ac.uk).

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.3) 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­browser4) 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önnen5), 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 Schreibtisch6), 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 prinzipiell7) 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üpfen8), 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 9) 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.10) 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.

 

 

1) Charlie Catlett, Teragrid Director (siehe http://teragrid.blogspot.com/2006/09/improving-security-and-usability.html)

2) siehe Artikel Wie sag ich?s meinem LDAP-Server? in Comment 06/3, Seite 33 (http://comment.univie.ac.at/06-3/33/), Abschnitt LDAP und Authentifizierung

3) Solche Systeme werden heute auch oft als WebISO-Systeme (Initial Sign-On) bezeichnet, um die initiale Authentifizierung zu betonen und nicht auf dem Single Sign-On zu beharren, das in der Praxis nur selten erreicht wird.

4) Das Speichern von UserID und Passwort im Webbrowser erlaubt auch nicht berechtigten Personen Zugriff auf Ihre Daten/Anwen­dungen, z.B. unbemerkt während einer Kaffeepause oder am Weg zur Toilette. Der Einsatz eines passwortgeschützten Bildschirm­schoners kann dieses Risiko etwas verringern; dieser wird aber in der Regel erst nach einiger Zeit der Inaktivität wirksam und kann unter Umständen auch selbst fehlerhaft sein (und damit umgangen werden) oder durch andere Schadsoftware beeinträchtigt werden. Darüber hinaus wurde bereits demonstriert, dass Unberechtigte unter gewissen Umständen Zugriff auf die im Browser gespeicherten UserIDs und Passwörter bekommen können.

5) Vor allem durch professionelle Betreuung in Bezug auf Klima­technik, Stromversorgung, Hard- und Software, Security und In­­cident Handling, Helpdesk und Beratung u.v.m.

6) siehe Artikel Artgerechte Server-Haltung: Serverhousing am ZID
in Comment 06/1, Seite 6 (http://comment.univie.ac.at/06-1/6/)

7) Je nachdem, wie eine bestimmte Webapplikation die Authen­ti­fizierung und Autorisierung derzeit durchführt, können eventuell Änderungen an der Software nötig werden, um die Integra­tion in das WebSSO-System zu ermöglichen. Oft kann die Software aber konfiguriert werden, die Authentifizierung dem Webserver zu überlassen. Sollten Änderungen an der Software notwendig sein, kann man diese entweder selbst durchführen bzw. jemanden damit beauftragen (einer der vielen Vorteile der Nutzung von Freier und Open Source-Software) oder sich an den Hersteller wenden und diesen um die Software-Unterstützung von HTTP Basic Auth er­­suchen. Der ZID steht in jedem Fall gern beratend zur Seite.

8) D.h. neben der Tatsache, dass immer noch viele Anwendungen von Haus aus eine eigene Benutzerverwaltung mitbringen und manchmal nur mit Mühe dazu gebracht werden können, Daten von BenutzerInnen aus einer zentralen Quelle (wie dem LDAP-Ver­zeichnisdienst) zu beziehen.

9)Die wichtigsten dieser Einrichtungen sind Internet2 (www.internet2.edu/about/), Educause (http://educause.edu/), das Enterprise and Desktop Integration Technologies Consortium der National Science Foundation Middleware Ini­tiative (NMI-EDIT, www.nmi-edit.org) sowie TERENA, die Trans-European Research and Education Networking Association ( www.terena.org).

10)Für die Verwendung innerhalb der Universität Wien werden die Bestimmungen in der Regel weniger streng sein, sodass UserID, Name oder eMail-Adresse einer zugreifenden Person (also Daten, die über die Suche im Online-Personalverzeichnis ohnehin öffent­lich zugänglich sind) an interne Applikationen weitergereicht werden können, um das Anlegen und Einrichten von Accounts für Be­nutzerInnen zu erleichtern oder gar zu erübrigen.