zurück zum Artikel

Single-Sign-on (SSO) wartet immer noch auf den Durchbruch im Internet, dabei existiert mit dem Protokoll OpenID eine gute Implementierung der Technik.

Single-Sign-on (SSO) wartet immer noch auf den Durchbruch im Internet. Wer kennt nicht das komplizierte Hantieren mit der Verwaltung von Benutzernamen und Passwörtern für unterschiedliche Webanwendungen? Folgendes Szenario wäre traumhaft: Man stelle sich vor, man hätte einen Benutzername und ein Passwort und könne sich damit überall in diversen Webanwendungen einloggen. Vielleicht müsste man noch nicht mal ein Passwort besitzen, da die Authentifizierung anders funktioniert – beispielsweise mithilfe von Biometrieverfahren. Was sich attraktiv anhört, bleibt zunächst ein Traum. Was allerdings im Internet mit dem SSO-Protokoll OpenID Realität ist, zeigt dieser Auftaktartikel der Artikelserie "Internet-Identität und Datenaustausch heute – Nutzung und Möglichkeiten von OpenID und OAuth".

Was ist OpenID?

OpenID beschreibt eine URL-basierte Identität (Identifier) wie https://mueller.myopenid.com/. Das Protokoll basiert auf einer dezentralisierten Identitätsinformation. Das heißt, es ist nicht zwingend notwendig, dass die Identität einer Person – im OpenID-Jargon der End User (Endbenutzer) – zentral auf einem einzigen OpenID-Provider (im Folgenden: Provider) vorhanden sein muss beziehungsweise zu speichern ist. Im Idealfall existiert eine Menge an Providern. Die URL-Identität lässt sich beim Einloggen in unterschiedlichen Websites oder Webanwendungen, auch Relying Parties genannt (im Folgenden: Konsument), eingeben, um die Authentifizierung anschließend beim Provider durchführen zu können.

Bei einer erfolgreichen Authentifizierung akzeptiert der Konsument den Endbenutzer. Er kann nun wie gewohnt in der Webanwendung Aktionen durchführen. Je mehr Websites und Webanwendungen das Protokoll unterstützt, desto weniger Benutzernamen und Passwörter muss der Endbenutzer erstellen, verwalten und eingeben. Abbildung 1 stellt die Rollen im OpenID-Umfeld dar.

Seit 2007 kontrolliert die OpenID Foundation [1] die Entwicklung des OpenID-Protokolls. Ihr gehören Unternehmen wie Microsoft, Google, IBM, Yahoo und VeriSign an.

OpenID-Authentifizierung aus Endbenutzer-Sicht

Im Prinzip geht es um die Umleitung des Benutzer-Logins auf einem ausgewählten Provider. Im ersten Schritt ist der Identifier (zum Beispiel https://mueller.myopenid.com/) auf einer Konsumenten-Webanwendung einzugeben. Zunächst ist der Identifier zu normalisieren beziehungsweise passend zu formatisieren. Aus der gewonnenen Information lässt sich der Provider suchen und finden (Discovery). Danach kann man den Provider kontaktieren (bei OpenID heißt das direkte Kommunikation zwischen Konsument und Provider), um – soweit möglich – eine Beziehung zwischen Konsument und Provider (eine sogenannte Assoziation) in Form eines Geheimschlüssels herzustellen. Der Schlüssel ermöglicht die Beibehaltung des Zustandes, sodass bei späterer Kommunikation kein direkter Informationsaustausch stattfinden muss.

Anschließend ist der Endbenutzer über den Browser an den Provider weiterzuleiten (bei OpenID bezeichnet man das indirekte Kommunikation zwischen Konsumenten und Providern) und eine Login-Maske des Providers zu erstellen, sodass er Benutzername und Passwort eingeben kann. Der Konsument erhält das Ergebnis der Authentifizierung ausschließlich durch eine Weiterleitung (Redirect). Dadurch kann er überprüfen, ob der Endbenutzer eine korrekte Authentifizierung durchgeführt hat. Der Konsument führt in der einfachen Form des Protokolls zusätzlich eine direkte Kommunikation mit dem Provider, um sich das Ergebnis der Authentifizierung noch mal bestätigen zu lassen. Die intelligente Form des Protokolls hingegen verwendet den oben erwähnten Geheimschlüssel, um das Authentifizierungsergebnis zu verifizieren. Danach kann die Webanwendung des Konsumenten wie gewohnt mit ihrer eigenen Applikation weiterarbeiten. Die Abbildung 2 stellt den intelligenten Authentifizierungsmechanismus grafisch dar. Für eine detaillierte Protokollausführung sei auf das OpenID-Online-Buch "Get Ready for OpenID [2]" verwiesen.

Um die Unabhängigkeit eines Identifiers zum Provider zu gewährleisten, muss man seine eigene URL-Adresse als Identifier nutzen. Im Fall, dass ein neuer Provider eingesetzt werden sollte, ist dort die Provideradresse zu verändern. In der OpenID-Welt bezeichnet man das Verfahren als Delegation [3]. In der angegebenen URL-Adresse genügt ein einfacher Eintrag, wie das folgende Beispiel für OpenID 1.x zeigt. Sobald man die Adresse als Identifier eingibt, leitet das OpenID-Protokoll die Seite des Konsumenten an den richtigen Provider um [6 [4]]:

<link rel="openid.server" href="https://www.myopenid.com/server">
<link rel="openid.delegate" href="https://mueller.myopenid.com">

Spezifikationen

SSO- und OpenID-Spezifikationen

Neben OpenID gibt es eine Reihe anderer Protokolle für SSO mit der gleichen Intention, beispielsweise das Liberty Alliance Project mit SAML [5] (Security Assertion Markup Language), Microsoft Passport [6], CAS [7] (Central Authentication Service), Shibboleth [8] und Kerberos [9] (siehe Glossar [10]). OpenID ist für die Authentifizierung in Webanwendungen eine einfache und pragmatische Lösung. Hinzu kommt, dass sowohl die Anzahl der Konsumenten als auch der Provider stetig steigt, was die Akzeptanz der Endbenutzer definitiv erhöht [3 [11]].

OpenID ist durch Erweiterungsspezifikationen wie OpenID Attribute Exchange (OpenID AX) offen, um unterschiedliche Aspekte des Identitätsmanagements abzudecken. Durch OpenID AX lassen sich Attribute eines Endbenutzers – oft innerhalb einer Identitäts-Card beziehungsweise einer Persona zusammengefasst – zwischen einem Konsumenten und einem Provider austauschen. Es ist beispielsweise möglich, E-Mail-Adresse, Nickname und/oder Alter des Endbenutzers von Providern an den Konsumenten und umgekehrt zu übergeben. Beim Implementieren solcher Funktionen ist es jedoch wichtig, dass die informationelle Selbstbestimmung des Endbenutzers stets im Vordergrund steht. Ein Konsument und ein Provider dürfen keine Attribute ohne Zusage des Endbenutzers austauschen. Das gehört jedoch nicht zu den OpenID-Spezifikationen und ist beim Implementieren des Providers genau zu beachten. Die folgende Tabelle beschreibt kurz die wichtigsten Spezifikationen. Ausführliche Informationen zu ihnen gibt es unter openid.net [12]. Konzeptuell setzt das OpenID-Protokoll auf der "Name-Value-Pair"-Beschreibung auf. Bei Java ist dies mit der Verwendung von Map vergleichbar. Im Webservices-Jargon nutzt das OpenID-Protokoll das REST [13]-Modell.

Das folgende Beispiel zeigt, wie eine OpenID-Anfrage innerhalb des Protokolls aussieht:

openid.ns = "http://specs.openid.net/auth/2.0"
openid.mode = "checkid_setup"

OpenID-Provider und -Konsument

Inzwischen gibt es zahlreiche Provider, die mit unterschiedlichen Eigenschaften aufwarten. Unter "Beispiele von OpenID-Providern [15]" sind sie übersichtlich zusammengefasst. Die Liste [16] der Konsumenten ist ebenfalls lang. Für in Deutschland zur Verfügung stehende Konsumenten gibt es eine geringere Anzahl [17]. Bei zahlreichen Konsumenten finden oft White- und Black-Listing-Verfahren Verwendung, um ausschließlich bestimmte Provider zuzulassen. In vielen Fällen ist das sinnvoll, sodass anonyme beziehungsweise Wegwerf-Provider nicht zu verwenden sind. Die bekanntesten OpenID-Konsumenten findet man unter "Beispiele von OpenID-Konsumenten [18]" aufgelistet.

Integration von OpenID aus Sicht des OpenID-Konsumenten

Um die Verbreitung und Akzeptanz von OpenID zu gewährleisten, müssen genügend Konsumenten das Protokoll unterstützen. Daher steht die Einfachheit bei der Anbindung von OpenID in eine Webanwendung im Vordergrund. Im Prinzip ist der Anbindungsprozess zu befolgen, wie er in Abbildung 4 dargestellt ist. Der Registrierungsprozess ist genauer zu beachten, da mehrere Szenarien für die Existenz eines Konsumenten- beziehungsweise Providerkontos möglich sind. Für jedes Kästchen gibt es eine Lösung.

Folgende Vorgehensweise ist bei der Anbindung denkbar: Die Endbenutzer-Datenbank ist zunächst zu erweitern. Hier sind zusätzliche Informationen über den OpenID-Identifier und das OpenID-Konto zu speichern. Bei jedem Endbenutzer-Konto kann man mehrere Identifier verwenden. Im einfachsten Fall beziehungsweise bei einer neuen Anwendung ohne vorhandene Endbenutzer könnte man ausschließlich den OpenID-Identifier speichern, sodass eine separate Endbenutzer-Kontoverwaltung wegfallen würde. Anschließend sind folgende Webseiten des Konsumenten zu überarbeiten:

• Endbenutzerkontoverwaltungsseite: Bei vorhandenen Endbenutzer-Konten auf der Konsumentenanwendung müssen Endbenutzer die vorhandenen Open-ID-Konten eintragen und sie anschließend verwenden können.
• Registrierungsseite des Endbenutzers: Statt des normalen durchläuft die Registrierung mit OpenID-Providern einen kürzeren Prozess. Schließlich will der Endbenutzer die Registrierungsdaten nicht noch einmal eintippen müssen. Spezifikationen wie SReg oder AX übertragen diese Information aus dem Provider.
• Login-Seite des Endbenutzers: Zum Einloggen muss die Eingabe eines OpenID-Identifiers möglich sein. Hierfür ist ein Textfeld mit einem OpenID-Symbol auf der Login-Seite einzufügen.

Fazit

Fazit

Derzeit existieren nach Statistik von JanRain über 27.000 OpenID-Konsumenten weltweit. In der Provider-Rolle konkurrieren inzwischen große Namen wie Yahoo, VeriSign, MySpace, Alice, AOL und Google. Sie exportieren meistens ihre eigenen Benutzer als OpenID-Endbenutzer, die für die Authentifizierung unterschiedlicher Konsumenten zu nutzen sind. Fraglich ist jedoch, ob diese Provider auch als Konsumenten fungieren. Ein Szenario wie "Ich logge mich bei Google Mail mit meinem OpenID-Konto bei Yahoo! ein", würde das Internet in eine neue Dimension katapultieren. In Deutschland ist die Anzahl der verfügbaren Konsumenten und Provider noch sehr gering. Wahrscheinlich ist das mit Zweifeln gegenüber SSO zu begründen.

Dr. Lofi Dewanto [19]
arbeitet als Softwareentwickler bei der Deutschen Post Com GmbH. Er engagiert sich insbesondere für "javanische" Open-Source-Software sowie MDA.

Online-Ressourcen

1. OpenID-Bibliotheken [20]
2. Brands, S.: The Problem(s) with OpenID [21]
3. [22]OpenID Directory [23]
4. OpenID-Verzeichnis für Deutschland [24]
5. Extremes Wank OpenID [25]
6. [26]Scott Gilbertson: How To Make Your Own Domain An OpenID [27] (27. März 2007)
7. OpenID: intro & howto for non-techies [28] (4. April 2008)
8. Deutsche OpenID-Blog-Seite [29]
9. OpenID Foundation [30]
10. OpenID Delegation [31]
11. Rehman, R. U.: Get Ready for OpenID [32]
12. Marco Slot: Beginner's Guide to OpenID Phishing [33]
13. [34]Joseph Smarr: A Recipe for OpenID-Enabling Your Site [35]
14. OpenID-Spezifikationen [36]
15. Justen Stepka: Using OpenID [37] (Mai 2007)
16. Wikipedia: REST – Representational State Transfer [38]

OpenID-Provider

[39]

Beispiele von OpenID-Providern

OpenID-Konsumenten

[40]

Beispiele von OpenID-Konsumenten

Glossar

[41]

Glossar

SAML [42] (Security Assertion Markup Language): eine XML-basierte Auszeichnungssprache für Sicherheitsbestätigungen. Sie wird vom OASIS-Konsortium entwickelt und verwaltet. SAML stellt Funktionen bereit, um sicherheitsbezogene Informationen zu beschreiben und zu übertragen.

Microsoft Passport [43]: ein SSO-System, das Microsoft als Teil der .Net-Strategie entwickelt und in von Microsoft betriebenen Diensten (MSN, Hotmail) verbreitet ist.

CAS [44] (Central Authentication Service): ein föderiertes Identitätsmanagement, welches ursprünglich die Yale-Universität entwickelte. Mittlerweile ist CAS ein Projekt des JA-SIG-Konsortiums, das zum Ziel hat, Universitäten und andere höhere Bildungsinstitute zu vernetzen, um einen freien Austausch von Wissen und Techniken zu gewährleisten.

Shibboleth [45]: ein vom Internet2/MACE entwickeltes SSO-System zur verteilten Authentifizierung und Autorisierung für Webanwendungen und Webservices. Das Konzept von Shibboleth sieht vor, dass der Benutzer sich nur einmal bei seiner Heimateinrichtung authentisieren muss, um ortsunabhängig auf Dienste oder lizenzierte Inhalte unterschiedlicher Anbieter zugreifen zu können. Shibboleth setzt auf einer Erweiterung des Standards SAML auf.

Kerberos [46]: ein verteilter Authentifizierungsdienst, der für offene und unsichere Computernetze wie das Internet entwickelt wurde. Kerberos ist gleichzeitig ein SSO-System. (ane [47])

URL dieses Artikels:
https://www.heise.de/-227202

Links in diesem Artikel:
[1] http://openid.net/foundation/
[2] https://books.google.de/books/about/Get_Ready_for_Openid.html?id=i7yL2yCy-SUC&hl=de
[3] http://wiki.openid.net/Delegation
[4] #l1-u2
[5] http://saml.xml.org/
[6] http://www.passport.net/
[7] http://www.jasig.org/cas
[8] http://shibboleth.internet2.edu/
[9] http://web.mit.edu/Kerberos/
[10] #l2-u5
[11] #l3-u2
[12] http://openid.net/specs/openid.net/specs/
[13] http://de.wikipedia.org/wiki/Representational_State_Transfer
[14] https://verify.sxip.com/papedemoverify.sxip.com/papedemo
[15] #l4-u3
[16] http://openiddirectory.com/
[17] http://openiddirectory.com/germany-c-18.html
[18] #l5-u4
[19] http://lofidewanto.blogspot.com
[20] http://wiki.openid.net/Libraries
[21] http://idcorner.org/2007/08/22/the-problems-with-openid
[22] 
[23] http://openiddirectory.com
[24] http://openiddirectory.com/germany-c-18.html
[25] http://code.google.com/p/extremeswankopenid/wiki/UsingDesktopConsumer
[26] 
[27] http://blog.wired.com/monkeybites/2007/03/how_to_make_you.html
[28] http://www.consumingexperience.com/2006/12/openid-introduction.html
[29] http://openidgermany.de
[30] http://openid.net/foundation
[31] http://wiki.openid.net/Delegation
[32] http://www.openidbook.com/download/openidbook.pdf
[33] http://marcoslot.net/apps/openid
[34] 
[35] http://www.plaxo.com/api/openid_recipe
[36] http://openid.net/specs
[37] http://www.theserverside.com/tt/articles/article.tss?l=OpenID
[38] http://de.wikipedia.org/wiki/Representational_State_Transfer
[39] 
[40] 
[41] 
[42] http://www.oasis-open.org/committees/security
[43] http://www.passport.net
[44] http://www.ja-sig.org/products/cas
[45] http://shibboleth.internet2.edu
[46] http://www.kerberos.org
[47] mailto:ane@heise.de

Copyright © 2009 Heise Medien