Aber Sicher!

Authentifizierung und Autorisierung für konvergente Applikationen mit OAuth und OpenID

Der Bedarf für flexible, sichere und intelligente Authentifizierungs- und Autorisierungslösungen in heterogenen Servicelandschaften ist mit der Ausweitung von Triple-Play auf mobile Endgeräte weiter gewachsen. Um für alle Zugangswege eine konvergente Lösung anbieten zu können, müssen Anbieter auf offene Standards setzen. Dieser Artikel geht auf die besonderen Herausforderungen einer gewachsenen Applikations- und Servicelandschaft ein und stellt mit OAuth 2.0 und OpenID zwei moderne Protokolle vor, um diesen Herausforderungen zu begegnen. Begleitend werden die wichtigsten Architekturmuster des Identity Managements diskutiert. Primär geht es dabei um Ansätze für Dienste die im Internet und nicht ausschließlich in Firmennetzen bereitgestellt werden.

Einen Sack Flöhe hüten – Die Herausforderungen

An den folgenden zwei Beispielen aus der Praxis im Jahr 2010 wird deutlich, wie durch Fusionen im Telekommunikationsmarkt und die Ausweitung des Serviceangebots auf zuvor fremde Marktbereiche eine extrem heterogene Servicelandschaft geschaffen wird. Dieser Effekt wird noch verstärkt durch die rasante Weiterentwicklung der Endgeräte – zuletzt in Richtung Tablet-PC. Genannt seien hier nur die Übernahme von Hansenet durch Telefonica O2 und der Zusammenschluss der beiden Telekom Geschäftseinheiten für Festnetz „T-Home“ und Mobilfunk „T-Mobile“ zur Telekom Deutschland GmbH. Hier wird deutlich, welche Herausforderungen es bei der Integration der vorhandenen Dienste zu meistern gilt:

Zu Problemen bei Fusionen kommt es, da die in jahrelanger Spezialisierung gewachsenen Domänenmodelle von ehemals getrennten Serviceumgebungen mit zueinander meist vollständig inkompatiblen Kunden- und Benutzerstämmen einhergehen. Das fängt bei verschiedenen Authentifizierungsmethoden an (Passwort, Pin, mehrerlei Arten der Anschlusserkennung – um nur einige zu nennen), geht über ungleiche Berechtigungskonzepte und hört nicht mit unterschiedlichen Methoden zur Leistungsverrechnung auf (zum Beispiel Telefonrechnung, Kreditkarte, Lastschrift, Gutscheine, Pre-Paid Karten und so weiter).

Die IDP (Identity Provider) zur Unterstützung des Identity Managements können dabei mehr oder weniger eigenständige Systeme sein oder technisch vollständig mit einem oder mehreren Diensten zusammenhängen. Die folgende Abbildung zeigt ein stark vereinfachtes Beispiel für eine gewachsene Service-Landschaft, wie sie so oder ähnlich anzutreffen ist. Unterschiedliche Formen, Farben und Größen stellen dabei die Vielzahl an verwendeten Technologien und proprietären Protokollen dar.

Beispiel für eine gewachsene Service Landschaft

Natürlich erwarten auch die Endkunden eine vollständig integrierte Produktlandschaft auf allen ihren Endgeräten. Die Service Provider stehen hier vor der Herausforderung, dass nahezu jedes neue Produkt der Unterhaltungs- oder Telekommunikationselektronik mit der Möglichkeit zur Installation zusätzlicher Applikationen und Netzwerkfähigkeit aufwartet – zum Beispiel Set-Top Boxen, Streaming Clients und Smartphones. Im Jahr 2015 wird es laut einer Statistik in Deutschland 22,9 Millionen Haushalte geben, die über internetfähige TV-Geräte verfügen.

Zusätzlich wird auch die Integration der Dienste von Drittanbietern wie etwa Facebook, Twitter, Flickr aber auch Portalen wie Android Market und dem „Windows Marketplace for Mobile“ von Microsoft immer wichtiger. Dabei kann es den Benutzern eines Partners ermöglicht werden, direkt oder indirekt die Dienste des jeweils anderen Partners zu benutzen. Hier geht es daher nicht um einen gleichberechtigten Zusammenschluss der IDM-Systeme der Partner, sondern um die (vielleicht sogar nur temporäre) Bereitstellung von Diensten.

Welche Wege gibt es nun, um flexibel bei der Integration von bestehenden Anwendungen zu sein, ohne eine einheitliche Benutzerdatenbank einführen zu müssen?

Blümchentapete – Muster als Wege aus dem Dilemma

Die vollständige und homogene Zusammenlegung von vorhandenen Benutzerkonten und Kundenstämmen wäre in der Praxis nicht nur technisch mit extrem hohem Aufwand verbunden, sondern auch rechtlich oftmals schlicht unmöglich. Zum Beispiel dann, wenn nur eine temporäre Partnerschaft mit einem 3rd-Party-Provider eingegangen wird, ohne dem Kunden die Zustimmung zu einer neuen AGB abzuverlangen.

Sicherlich kann es hier keine Antwort auf alle Fragen geben – dazu sind die Problemstellungen in der Telekommunikationsbranche zu komplex und vielschichtig. In mehrjähriger Projekterfahrung in diesem Bereich haben sich aber gewisse Muster herausgebildet, die hier kurz vorgestellt werden sollen. Einer der Grundsätze einer serviceorientierten Architektur „Heterogenität akzeptieren und nicht bekämpfen“ (Nicolai Josuttis: „SOA in der Praxis“) kann auch in diesem Problemfeld angewendet werden: Verschiedene Domänenmodelle sowie Authentifizierungskonzepte werden einfach akzeptiert. Die Benutzeridentität kann über einen Realm einem bestimmten IDP zugeordnet werden. Für den Anschluss von bestehenden Diensten gibt es mehrere Möglichkeiten. Der Dienst kann:

  1. Nur Benutzer einer bestimmten Domäne akzeptieren und andere Benutzer ausschließen: Diese Variante kommt immer dann zum Tragen, wenn der Dienst zu eng an das spezifische Domänenmodell seines IDP gebunden ist und Änderungen zu aufwändig wären.
  2. Benutzer mehrerer Domänen akzeptieren: Weisen die Identitäten genügend ähnliche Merkmale auf, kann der Dienst flexibel darauf reagieren und diesen Benutzern beschränkten oder sogar vollen Zugriff erlauben.
  3. Benutzer aller (auch unbekannter) Domänen akzeptieren: Dieser Gedanke wird konsequent durch das OpenID Protokoll weitergeführt – siehe weiter unten im Text.

Um den durch die enge Kopplung von Dienst und Domänenmodell entstehenden Einschränkungen zu begegnen, kann zwischen den beteiligten IDPs eine Vertrauensstellung geschaffen werden. In Verbindung mit einer Verknüpfung von Identitäten über IDP-Grenzen hinweg wird der Dienst immer mit einer Identität ‚seines‘ IDP aufgerufen. Diese Verknüpfungen können temporär sein, wenn es nur darum geht, dass ein Benutzer irgendwie authentifiziert wurde. In diesem Fall wird zum Beispiel für jede Dienstnutzung eine neue temporäre Identität ausgestellt. Eine dauerhafte (vielleicht sogar vom Benutzer wahrgenommene) Kopplung der Identitäten führt dazu, dass ein Dienst auch die Speicherung von Profil- bzw. Benutzerdaten anbieten kann.

Die letzte Möglichkeit, einen Dienst den Benutzern anderer Domänen zur Verfügung zu stellen, ist das Aufsetzen einer neuen Instanz für jeden Benutzerkreis. Ob dies in der Praxis umsetzbar ist, ohne die vollständige Dienstinfrastruktur inklusive aller Backend-Systeme zu duplizieren, muss im Einzelfall entschieden und kann nicht pauschal beantwortet werden. In der Regel ist diese Variante aber sehr aufwändig und am wenigsten flexibel.

Vor allem in Umgebungen mit sehr hohen Anforderungen an die Skalierbarkeit bei Benutzerzahlen zwischen einigen Tausend und mehreren hundert Millionen ist das Architekturmuster des ‚offenen Dreiecks‘ zwischen IDP, Client-Anwendung und Dienst unverzichtbar. Dabei wird zwischen Dienst und IDP über symmetrische oder asymmetrische Kryptografie eine Vertrauensstellung geschaffen. Der Benutzer authentifiziert sich ein einziges Mal gegenüber seinem IDP und erhält ein kryptografisch gesichertes Token. Danach wird das Token vom Client benutzt, um die Dienstnutzung zu authentifizieren und zu autorisieren. Dieses Prinzip wird vom OAuth Protokoll unterstützt, worauf im folgenden Abschnitt näher eingegangen wird.

Ja, wir schaffen das – Offene Standards als universelle Werkzeuge

Welches sind nun die Vorteile, die aus der Verwendung von Standardprotokollen zur Authentifizierung und Autorisierung resultieren? Ganz allgemein kann mit den beiden offenen Standards OpenID und OAuth die Frage nach Authentifizierung und Autorisierung für alle Dienste eines Providers allgemeingültig beantwortet werden. Auf diese Weise müssen nicht für jeden neuen Dienst erneut einzelne Authentifizierungsmethoden in dessen Schnittstelle vorgesehen werden. Der Zugewinn an Sicherheit durch den Einsatz einer etablierten und geprüften Lösung liegt auf der Hand. Zudem muss nicht jede neue Dienst-Anbindung einen aufwändigen Zertifizierungsprozess durchlaufen – es ist oftmals ausreichend, die Standardkonformität und den Schutz von möglicherweise vorhandenen geheimen Schlüsseln (Shared Secrets) sicherzustellen. Mit jedem neuen Dienst können sowohl die Wiederverwendbarkeit vorhandener Schnittstellen als auch freie Bibliotheken zu weiteren Kosteneinsparungen führen. Die oben als Herausforderung bezeichnete Integration von 3rd-Party Diensten wird ebenfalls einfacher und ist schneller umsetzbar.

Zur Wahrung der Vollständigkeit seien noch die Protokolle bzw. Technologien YAIDS, Microsoft CardSpace und Shibboleth genannt, die aber in der Praxis nicht die gleiche Aufmerksamkeit genießen wie OpenID und OAuth.

OpenID

OpenID steht für „offene Identifikation“ und basiert auf der Grundidee, dass ein Benutzer einen Account bei einem einzigen OP (OpenID-Provider) besitzt, zu dem ein Dienst ihn zum Zweck der Authentifizierung weiterleiten kann. Die Eingabe der Zugangsdaten erfolgt ausschließlich auf der mit mehreren Sicherheitsmerkmalen ausgestatteten Seite des Providers in der Rolle eines IDP.

Nach einer erfolgreichen Authentifizierung des Benutzers durch den OP erhält der Dienst eine OpenID. Der ursprüngliche Ansatz von OpenID Version 1.0 basierte auf der Überlegung, an jeden Dienst die gleiche ID zu übertragen, um im Netz den Aufbau von Reputation zu ermöglichen. Mit Version 2 kam die Möglichkeit hinzu, dienstspezifische OpenIDs zu erzeugen.

OpenID Sequenz
OpenID Sequenz

Ein Dienst, der einem (möglicherweise fremden) OP vertraut, befindet sich nach OpenID Spezifikation in der Rolle einer RP (Relying Party). Die Grafik zeigt vereinfacht den Ablauf.

Single Sign-On und Attributaustausch sind zusätzliche optionale Merkmale einer OpenID Authentifizierung. Es gibt noch eine Reihe weiterer Funktionen und möglicher Abläufe, die aber über den Rahmen dieses Artikels hinausgehen würden.

Seit Veröffentlichung von Version 2.0 im Dezember 2007 unterstützt eine große Anzahl von Unternehmen das OpenID Protokoll in der Rolle eines OpenID Providers. In der Praxis erlauben leider viele dieser Unternehmen keinen Zugriff mit fremden OpenIDs auf ihre eigenen Dienste als Relying Party (siehe hierzu OpenID bei Wikipedia).

OAuth

Im Gegensatz zu OpenID spezifiziert OAuth den Authentifizierungsvorgang selbst nicht näher, sondern definiert nur, dass dieser stattfinden muss. Dies gilt sowohl für den zurzeit gültigen IETF Standard OAuth 1.0a als auch für die noch in der Abstimmung befindliche OAuth 2.0 Spezifikation. Obwohl OAuth 2.0 bisher nur in einer Entwurfsversion (Draft) vorliegt, gibt es bereits eine Reihe von Implementierungen. Daher soll im Folgenden auf Version 2.0 eingegangen werden.

Um auf einen Web Service (in OAuth die Protected Resource und damit das Pendant zur OpenID Relying Party) zugreifen zu können, muss der Client ein gültiges Access Token vorweisen (Schritt 5). Dieses Token wird vom Authorization Server nach erfolgreicher Authentifizierung des Benutzers und Autorisierung der Client-Anwendung ausgestellt (Schritt 4).

OAuth2 Sequenz
OAuth2 Sequenz

Einer der wesentlichen Vorteile von OAuth besteht in der Möglichkeit, langlebige Tokens (in OAuth 2.0 Refresh Token genannt) als Ersatz für Benutzername und Passwort in Client-Anwendungen abzulegen. Diese Tokens können von der Applikation ohne Interaktion mit dem Benutzer dazu verwendet werden, neue (kurzlebige) Access Tokens vom Authorization Server anzufordern.

Durch das Prinzip der delegierten Authentifizierung ist es zudem möglich, neue Authentifizierungsverfahren anzubieten, ohne Änderungen an den angeschlossenen Diensten vornehmen zu müssen. Die von OAuth standardisierte Zugriffserlaubnis (Autorisierung) für Clients wird inzwischen auch für automatisierte Service-zu-Service Kommunikation verwendet. So nutzt zum Beispiel Second Life die öffentliche Twitter OAuth Schnittstelle, um seinen Benutzern die Möglichkeit zu bieten, von beliebigen Objekten in Second Life Updates zu ihren Twitter-Feeds zu schicken, wenn eine vordefinierte Interaktion mit einem Objekt stattfindet.

Der OAuth Standard sagt allerdings nichts über Inhalt und Format der Access Tokens aus. Die Nutzung eines Dienstes mit von verschiedenen IDPs ausgestellten Tokens setzt daher voraus, dass entweder der Dienst mehrere Token-Formate unterstützt oder die IDPs sich auf ein gemeinsames Format geeinigt haben. Mit der Bearer Tokens Spezifikation, die als Ergänzung zu OAuth 2.0 ebenfalls Ende 2010 erstmals veröffentlicht wurde, können Service Provider ihre Dienste genau auf diese Anforderung vorbereiten. Weitere mögliche Token-Formate sind zum Beispiel JSON Web Tokens und SAML.

Um mit Token echte Interoperabilität zu erreichen, muss neben dem Format auch ein gemeinsamer Satz an übertragenen Attributen vereinbart werden. OpenID hat genau dies mit der „Attribute Exchange Extension“ getan. Auch hier zeigen sich nutzbringende Parallelen zwischen OAuth und OpenID.

Die Qual der Wahl – Wann welches Protokoll einsetzen?

Sicher ist die Frage nach dem Protokoll nicht immer einfach zu beantworten und hängt von vielen Faktoren ab. Vielleicht unterstützen auch deshalb immer mehr Unternehmen beide der oben vorgestellten Protokolle. So verwendet zum Beispiel Google für seinen Apps-Marketplace sowohl OpenID als OAuth – in bestimmten Fällen sogar in Verbindung miteinander als Hybrid-Lösung. Auf einer Dokumentationsseite für Applikationsentwickler wird von Google als Antwort auf die Frage nach der Wahl des richtigen „Auth“ Mechanismus folgende einfache Regel aufgestellt:

  • OAuth – Autorisierung für Web- und lokal installierte Anwendungen
  • Hybrid Protocol (OAuth und OpenID) – Authentifizierung und Autorisierung für Web-Anwendungen
  • OpenID – Authentifizierung für Web-Anwendungen

Logout – Das Fazit

Der Markt ist für Telekommunikationsunternehmen permanent im rasanten Umbruch begriffen. Es bleibt zu hoffen, dass die hier vorgestellten Architekturmuster und Protokolle des Identity Managements zu einer Stabilisierung der Dienstlandschaft beitragen können. Um flexibel auf neue Herausforderungen reagieren zu können, müssen Unternehmen untereinander aktiv zusammenarbeiten und eine Weiterentwicklung der bestehenden offenen Standards sicherstellen. Der Anfang ist mit OpenID und OAuth gemacht. Jetzt heißt es zum Kundennutzen konvergente Dienste anzubieten.

Quellen:
Grafiken: Christian Stübner
Verwendete Avatare: Microsoft® Office Online. Nutzung mit Genehmigung von Microsoft®.

Update:
Inzwischen wurde die finale OAuth 2.0 Spezifikation veröffentlicht.

Kommentare sind abgeschaltet.