Seit Weihnachten ist die VZG offiziell Mitglied der DFN-Föderation zu Shibboleth. Bei Shibboleth handelt es sich nicht um eine Rasse im Star-Trek-Universum (so wie die Ferengi, Borg oder Vulkanier), sondern um ein Verfahren für eine “Authentifizierungs- und Autorisierungs-Infrastruktur” (AAI). Das Identity-Management mit Shibboleth ist vergleichbar mit OpenID, geht aber darüber hinaus. Geregelt werden vor allem nicht nur technische, sondern auch organisatorische Belange. Während bei OpenID hinter jeder Identität letzendlich nur eine URL steht, stellt die DFN-Föderation sicher, dass hinter den verwalteten Identitäten tatsächliche Personen stehen. Die Mitglieder der Föderation garantieren als “Identity-Provider” die Authentizität und Aktualität ihrer Nutzerdaten und einigen sich auf eine Menge von Attributen wie Nachname, Heimatorganisation, Art der Zugehörigkeit und Berechtigungen. Diese Attribute können beim Single-Sign-On an einen “Service-Provider” weitergegeben werden – wobei der Datenschutz hohe Priorität hat. In der Regel wird nicht einmal der Name, sondern nur die Zugehörigkeit und/oder Berechtigung übertragen. Der Anbieter eines Dienstes bekommt vom Identity-Provider also lediglich die Information, dass sich eine Person erfolgreich authentifiziert hat und ihr Identity-Provider eine bestimmte Berechtigung garantiert. Die VZG ist im Rahmen der DFN-Föderation sowohl Identity-Provider (für Einzelnutzer von Nationallizenzen) als auch Service-Provider (mit einem Proxy zum Zugriff auf Nationallizenz-Angebote). In Zukunft sollen weitere Universitäten als Identity-Provider und weitere Verlage direkt als Service-Provider auftreten. Weitere Informationen zu Shibboleth – bspw. Hilfen zur Installation und Konfiguration gibt es auf den Seiten zum Projekt AAR an der Uni Freiburg.

Mich wundert schon etwas, dass bei WordPress standardmäßig die Login-Passwörter und Session-Cookies unverschlüsselt durch die Gegend geschickt werden. Konferenzblogging heisst also, dass alle Teilnehmer über W-LAN ihre Passwörter austauschen? Sicherheit hat bei den WordPress-Entwicklern anscheinend keine Priorität. Zum Glück gibt es seit April wieder das Admin-SSL-Plugin. Um unverschlüsselte Verbindungen auf den Unterordner wp-admin ganz zu verhindern, ist folgender Eintrag in .htaccess angebracht:

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*)  https://%{SERVER_NAME}%{REQUEST_URI}

Im Gegensatz zur HTTPS habe ich nach einigem Überlegen darauf verzichtet Avatare – derer es verschiedene Arten wie Gravatar, Favatar und Pavatar gibt – in meinem Blog einzubinden. Zentralisierte Systeme möchte ich nicht unterstützen und Favatar ist in der jetzigen Form einfach zu unflexibel. Sinnvoller wäre ein Verfahren, dass Avatare an Online-Identitäten knüpft, z.B. durch ein OpenID-Attribut. Vielleicht kommt ja was passendes im Zusammenhang mit der SIOC-Ontologie. Unabhängig davon werde ich in Zukunft meinen Katzen-Avatar verwenden.

Für die Nutzung von OpenID kann ich nach meinem jetzigen Kenntnisstand nur empfehlen, Delegated Authentication zu nutzen, um unabhängig von einem Identity-Provider zu sein. Dafür sind auf einer Webseite, die dauerhaft (Dauer der Identität) unter eigener Kontrolle steht, im HTML-HEAD-Bereich zwei Links anzugeben (bei WordPress gibt es dafür ein Plugin):

<link rel="openid.server" href="...Identity Provider URL..." />
<link rel="openid.delegate" href="...Identity URL..." />

Leider lässt sich WordPress bislang nicht direkt als Identity Provider benutzen (anders als WordPress MU), also ist wahrscheinlich etwas Handarbeit notwendig, um eigene Identitäten per OpenID zu hosten – oder man leitet erstmal an einen existierenden OpenID-Account weiter, Anbieter dafür sprießen ja zur Zeit wie Pilze aus dem Boden. Anders sieht es leider noch bei der Unterstützung zum Einloggen mittels OpenID aus – da tun sich viele Dienste bisher schwer.

Ein schönes Gegenbeispiel ist der Kalenderdienst wevent (der Name wird sich Anfang 2008 noch ändern). Zwar hat wevent noch einige Probleme mit OpenID (trotz OpenID-Account können in den Benutzereinstellungen Passwort und andere Benutzerdaten geändert werden, die eigentlich beim Identity-Provider verwaltet werden sollten – ich habe mir beim Probieren deshalb schon einen Account zerschossen), aber der Dienst selber ist sehr zu empfehlen und von der Usability kann ich anderswo nur Träumen. Es fehlt lediglich eine gute Import-Funktion (sic!). Doch genug der Werbung, sonst geht die Seite noch wegen Benutzeransturm in die Knie

Da im Netbib-Weblog der Web 2.0-Dienst (auf den mich Antischokke gebracht hat) noch nicht entdeckt worden ist, dachte ich schon, ich wäre der erste aus der Biblioblogosphäre – allerdings hat die Staats- und Universitaetsbibliothek Bremen (SuUB) schon einen Account – es freut, mich sehr, wenn Bibliotheken neue Webdienste einfach so mal ausprobieren; vielleicht hat der Account auch damit etwas zu tun, dass die wevent-Macher aus Bremen kommen? Meine Termine gibt es jedenfalls 2008 unten rechts in der Sidebar dieses Blogs.

Search: SRU/SRW (including CQL), OpenSearch, Z39.50

Harvest/Syndicate: OAI-PMH, RSS, Atom Syndication (also with ATOM Extensions)

Copy/Provide: unAPI, COinS, Microformats (not a real API but a way to provide data)

Upload/Edit: SRU Update, Atom Publishing Protocol

Identity Management: Shibboleth (and other SAML-based protocols), OpenID (see also OSIS)

For more complex applications, additional (REST)-APIs and common metadata standards need to be found (or defined) – but only if the application is just another kind of search, harvest/syndicate, copy/provide, upload/edit, or Identity Management.

P.S: I forgot NCIP, a “standard for the exchange of circulation data”. Frankly I don’t fully understand the meaning and importance of “circulation data” and the standard looks more complex then needed. More on APIs for libraries can be found in WorldCat Developer Network, in the Jangle project and a DLF Working group on digital library APIs. For staying in the limited world if libraries, this may suffice, but on the web simplicity and availability of implementations matters – that’s why I am working on the SeeAlso linkserver protocol and now at a simple API to query availaibility information (more in August/September 2008).

P.P.S: A more detailed list of concrete library-related APIs was published by Roy Tennant based on a list by Owen Stephens.

P.P.S: And another list by Stephen Abram (SirsiDynix) from September 1st, 2009

Shibboleth ist ein Projekt des Internet2-Konsortiums und eine Open Source Anwendung zur Authentifizierung und Autorisierung für webbasierte Anwendungen und Services, die auf dem SAML-Standard basiert. Die Grundidee von Shibboleth ist es, dass jeder Benutzer sich nur einmal bei seiner Heimateinrichtung identifizieren muss, um die Dienste verschiedener Anbieter ortsunabhängig nutzen zu können. Dieses Prinzip nennt man „Single Sign-On“. Dadurch wird das Problem vieler verschiedener Nutzernamen und Passwörter für unterschiedliche Services oder lizensierte Materialien gelöst und ihre Nutzung wesentlich vereinfacht.

Wenn ein Benutzer über eine beliebige Internetverbindung auf einen Service oder eine geschützte Quelle zugreifen möchte, dann muss zunächst geprüft werden, ob er schon authentifiziert ist. Wenn das nicht der Fall ist, leitet der Service-Provider den Nutzer an einen Lokalisierungsdienst weiter, der die Heimateinrichtung des Nutzers ermittelt. Dort muss sich der Benutzer beim Identity-Provider der Heimateinrichtung mit Nutzernamen und Passwort identifizieren. Nach erfolgreicher Identifikation wird der Nutzer zurück zum Anbieter geleitet. Wenn der Service-Provider noch weitere Informationen benötigt, kann er beim Identity-Provider bestimmt Rechte oder Zugehörigkeiten erfragen, um zu ermitteln, ob der Nutzer autorisiert ist.

Die Authentifizierungs- und Autorisierungsinformationen können während der Sitzung in einem Cookie gespeichert werden, dadurch ist dann die Möglichkeit des Single Sign-On gegeben und der Nutzer spart sich bei einem weiteren Serviceanbieter erneute Anmeldeschritte. Voraussetzung für dieses ganze System ist, dass die Heimateinrichtung eine Instanz des Identity-Providers betreibt und die Serviceanbieter der angefragten Quelle den Service-Provider von Shibboleth betreiben.

Angestrebt ist ein flächendeckender und vielleicht sogar europaweit einheitlicher Einsatz von Shibboleth. Ab einer gewissen Größe des Einsatzgebietes übernimmt eine sogenannte Föderation die Organisation. Die Föderation soll alle Identity-Provider und Service-Provider in einer Dachorganisation vereinen und alle Standards des Verfahrens einheitlich für alle Mitglieder regeln. Außerdem soll sie den Lokalisierungsdienst für alle Mitglieder betreiben. In Deutschland wurde eine solche Föderation (DFN-AAI) vom Deutschen Forschungsnetz (DFN) in Zusammenarbeit mit der Universität Freiburg gegründet und auch in anderen Ländern gibt es schon Föderationen zur Leitung des Einsatzes von Shibboleth:DK-AAI (Dänemark), HAKA (Finnland), CRU (Frankreich), UKFederation (Großbritannien), SWITCH (Schweiz).

Die Unterschiede zu anderen Programmen wie OpenID (ähnlich wie Shibboleth, aber Konzept der URL-basierten Identität, eher für Unternehmen) und LDAP („Leihtweight Directory Access Protocol“, Einsatz bei Verzeichnisdiensten, Client/Server-Modell, Informationen auf Abfrage) liegt unter anderem darin, dass der Zugriff auf eine zugriffsgeschützte Quelle nicht mehr an einen Rechner gebunden ist, sondern an die Person, die auf die Quelle zugreifen möchte. Nutzer erhalten eine elektronische Identität mit Attributen, die die Grundlage für die Autorisierung und Zugriffskontrolle mit Shibboleth bilden. Shibboleth soll durch die stärkere Trennung von Personendaten und Services den bisherigen IP-Nummern-basierten Zugriff möglichst ganz ersetzen und ein organisationsübergreifendes Identity-Management schaffen.

Shibboleth wird bereits in verschiedenen Bereichen eingesetzt, vor allem in der Wissenschaft und Lehre, denn an vielen Bibliotheken oder Universitäten gibt es mittlerweile eine Vielzahl an elektronischen Diensten, Angeboten und lizensierten Materialen, für die eine komfortable und zugleich sichere Zugangsverwaltung und –kontrolle notwendig ist. In Deutschland beteiligen sich beispielsweise: Uni Freiburg, Uni Regensburg, Vascoda, das FIZ-Technik, Genios, der GBV und Springer. Auf der offiziellen Website gibt es eine relativ lange Liste von Anwendungen und Services, in denen Shibboleth integriert ist oder gerade integriert wird, zum Beispiel EBSCO Publishing, ExLibris, OCLC, Moodle und Napster. Außerdem findet man auf der gleichen Seite die Links zu den Föderationen im Ausland.

Wie Dare Obasanjo schreibt ist es zwar technisch (mit OpenID) machbar aber aufgrund ihrer konkurrierenden Geschäftsmodelle unwahrscheinlich, dass sich jemand mit einem Facebook-Account bei MySpace anmelden und die jeweils beim anderen Dienst gesammelten Kontakte nutzen kann. Wie D’Arcus bemerkt würde die Verknüpfung von Benutzerprofilen auch für bibliographische Dienste wie Zotero, CiteULike, RefBase und Bibsonomy sehr interessant und dort eher möglich sein.

Da frag ich mich doch, welche Bibliothek bereits OpenID für ihre Benutzeraccounts unterstützt oder die Unterstützung plant. Dass man gleich den Benutzernamen und Passwort bei einem anderen Dienst eingeben muss, kann ja nicht der Weisheit letzter Schluss sein. Diese Lösung nutzt übrigens der überaus hilfreiche Bücherwecker, der ebenso wie ZACK aus einer Abschlussarbeit entstanden ist. Ich hoffe, dass sich mal eine Bibliothekseinrichtung der Sache annimmt und dabei hilft, daraus einen stabilen Webservice für alle Bibliotheken zu erstellen anstatt dass eine Erinnerungsfunktion mehr schlecht als recht in jeder einzelnen Bibibliothessoftware nachprogrammiert werden muss.

Im Bibliotheksbereich gewinnt zum Glück Shibboleth an Bedeutung, aber davon kann ich mich leider trotzdem noch nicht mit meinem Wikipedia- oder LibraryThing-Account bei der nächsten Stadtbücherei anmelden (übrigens kommt Single Sign on für die Wikimedia-Projekte ganz bestimmt … irgendwann .