Qualität von Websystemen - Teil 16: Authentifizierung

Authentifizierung in Websystemen: Nicht nur fürs Protokoll

Daniel Takai, Gion Manetsch

© Shutterstock / jijomathaidesigners

Nachdem wir im letzten Artikel die grundlegenden Konzepte rund um die Identifizierung besprochen haben, wenden wir uns nun den konkreten Protokollen zu, die die Authentifizierung ermöglichen. Wir beginnen mit dem historischen LDAP und X.509 und wenden uns dann über SCIM den modernen RESTful-Verfahren zu, die ein Architekt heute in jedem Fall kennen sollte.

Eines der ältesten Protokolle ist das Lightweight Directory Protocol (LDAP) der IETF, das zur Verwaltung von Identitäten in Verzeichnissen verwendet wird. LDAP ist heute eines der einfachsten Verfahren, das für die Identifizierung angeboten wird. Bei den meisten XaaS-Providern und -Applikationen, die ein Identifizieren von Benutzern benötigen, ist es als Minimum vorhanden. Vorläufer zu LDAP war X.500. 2006 wurde die Version 3 der LDAP-Spezifikation publiziert und ermöglicht über ein API den Zugang zu Web-Apps oder nativen Apps, ohne zwingend die Credentials des Benutzers wie den Benutzernamen oder das Passwort offenzulegen. Da heute SSO-Anforderungen bei der Identifizierung im Vordergrund stehen, wird LDAP kaum noch eingesetzt, trotzdem ist es nach wie vor ein relevantes Protokoll.

X.509 ist ein weiterer, alter Standard, der asymmetrische Schlüssel verwendet und Verfahren zum Verwalten von Public-Key-Infrastruktur definiert. ITU-T 1988 hat X.509 publiziert, die letzte Version stammt von 2008. X.509 wird in diversen Standards zur Identifikation verwendet, hauptsächlich zur Identifikation mittels Zertifikaten. Eine häufige Form ist die Mutual Authentication, bei der sich Client und Server jeweils gegenseitig identifizieren. Eine weitere Form ist die Authentifizierung mittels Zertifikaten auf Smartcards. Zertifikate werden zunehmend auch bei mobilen Apps und im Internet der Dinge zum Identifizieren eingesetzt – und so wird X.509 künftig noch Wachstum erfahren.

Das Simple Cloud Identity Management (SCIM) ist ein Verfahren für das Cross-Domain-Identitätsmanagement, also den Austausch von Identitätsinformationen über verschiedene IT-Domänen und Systeme hinweg. Beispielsweise ist es dafür geeignet, On-Premise-Benutzer in die Cloud zu synchronisieren. SCIM definiert ein RESTful-API und Schemata für die Provisionierung und die Synchronisierung von Benutzeraccounts mit Cloud-Applikationen, ohne die Notwendigkeit, applikationsspezifische Konnektoren zu verwenden. Das Verfahren haben Cloud-Provider und Softwarehersteller entwickelt und über die IETF im September 2015 in der Version 2.0 als RFC 7642, RFC 7643 und RFC 7644 veröffentlicht. Da es sich um einen sehr jungen Standard handelt, ist das Verfahren noch nicht weit verbreitet.

Der User Managed Access (UMA) folgt dem ursprünglichen Konzept der Liberty Alliance, nämlich, dass ein Benutzer selbst steuern kann, wem er welche Identitätsattribute mitteilen möchte. UMA wurde im März 2015 in der Version 1.0 standardisiert und ist ein OAuth-basiertes Access-Management-Protokoll. Die Entwickler von UMA hatten bei der Entwicklung vor allem die Regelung von Privacy-Aspekten im IoT und bei Wearables im Sinn. Es ist nicht abhängig von OpenID, kann aber optional OAuth-basierte OpenID-Connect-Protokolle abhandeln.

Basic Auth ist … basic

HTTP Basic Authentication, auch kurz Basic Auth genannt, ist die einfachste Form der Authentifizierung. In ihrer Grundform benötigt sie weder Cookies, ein Session-Token oder eine Log-in-Seite. Basic Auth verwendet standardisierte Felder im HTTP-Header. Dabei wird das Basic-Auth-Feld bei jedem HTTP Request mitgegeben. Der Browser muss dabei die Credentials für einen definierten Zeitraum zwischenspeichern. Basic Auth besitzt keine Methode für den Log-out, es gibt aber Methoden, dies anders zu lösen, beispielsweise ein Redirect auf einen URL der gleichen Domäne, der falsche Credentials enthält, die dann gespeichert werden. Die mitgelieferten Credentials werden nach RFC2045 – MIME mit Base64 codiert. Die Base64-Codierung ist keine Verschlüsselung, sondern eine Codierung und damit unsicher. Eine höhere Sicherheit bietet die Verschlüsselung der Kommunikation mittels SSL. Dennoch kann es für einen Angreifer relativ einfach sein, die Base-64-codierten Credentials aus dem Browser auszulesen.

Basic Auth in seiner ursprünglichen Form sollte nur in Fällen eingesetzt werden, bei denen eine Identifikation des Benutzers auf einer Webapplikation erreicht werden soll, aber keine Sicherheitsanforderungen vorhanden sind. Da die Credentials nur codiert und nicht verschlüsselt im Browser gespeichert werden, können sie relativ einfach gehackt werden. Da es mit wenig Aufwand deutlich bessere Verfahren gibt, sollte auf die Verwendung von Basic Auth in dieser Form verzichtet werden.

Als Verbesserung zu der Base-64-Encodig-Variante von Basic Auth wurde die Digest Authentication entwickelt. Das hierbei verwendete Token wird aus den MD5-gehashten Credentials und einem vom Webserver generierten pseudo-zufälligen Wert gebildet, dem so genannten Nonce. MD5 ist heute als Sicherheitsverfahren nicht mehr zu empfehlen, da es relativ einfach geknackt werden kann, z. B. mit einem Brute Force oder einem Dictionary Attack. Als weitere Verbesserung hat man die HTTP Digest Authentication eingeführt, die einige Verbesserungen zum ursprünglichen Digest-Verfahren aufweist. Hier gibt es einen zusätzlichen Client-Nonce sowie einen erweiterten Server-Nonce mit Timestamp. Aber auch diese Verbesserung gilt als unsicher und sollte vermieden werden.

When Kerberos bites you, you die

Kerberos ist ein Authentifizierungsverfahren für unsichere Netze. Der Name stammt aus der griechischen Mythologie. Kerberos heißt der dreiköpfige Höllenhund, der den Eingang zur Unterwelt bewacht: Ein furchterregendes Biest! Unklar ist, ob dieser Kampfname damals von der Microsoft-PR-Abteilung freigegeben wurde. Der Vorläufer von Kerberos war das proprietäre NT-LAN-Manager-Verfahren (NTLM) von Microsoft. Es handelt sich dabei um eine Challenge-Response-Authentifizierung. Ziel des Verfahrens war es, ein Single Sign-on auf Webservern zu erreichen, damit sich Benutzer nur einmal anmelden müssen. Aufgrund der Sicherheitsprobleme von NTLM Version 1 wurde NTLM Version 2 entwickelt. Diese zweite Version hat man seit 2000 wieder aus Sicherheitsgründen durch das heute verbreitete und bekannte Kerberos ersetzt. NTLM v1 und v2 sollten nicht mehr eingesetzt werden, da sie nicht sicher sind. Kerberos entstand 1978 am Massachusetts Institute of Technology (MIT). Die Industrie nutzt es seit der Version 4, z. B. Microsoft. Die heute verwendete Version von Microsoft ist Version 5. Bei Kerberos sind vier Parteien involviert:

  • der Client, von dem der Zugriff erfolgt
  • die Ressource, auf die zugegriffen werden soll, in diesem Fall ein Webserver
  • der Kerberos Server und
  • der Ticket-Granting-Service
Abb. 1: Das Kerberos-Protokoll

Abb. 1: Das Kerberos-Protokoll

Kerberos verwendet zur Authentifizierung ein so genanntes Ticket. Das Verfahren ist in Abbildung 1 dargestellt. Der Client meldet sich zuerst beim Kerberos Authentication Server an (1), indem er seine Credentials kommuniziert. So erhält man ein Ticket Granting Ticket, kurz TGT. Mit diesem TGT kann der Client weitere Tickets für andere Dienste anfordern (2), ohne nochmals ein Passwort eingeben zu müssen. Das Ticket wird dann an die jeweiligen Ressourcen gesendet, auf die zugegriffen werden soll. Die Ressource kann aufgrund des erhaltenen Tickets überprüfen, ob sie dem Client den Zugriff gestatten soll (3). Zwischen dem Client und dem Kerberos-Server sowie zwischen dem Client und der Ressource werden jeweils eigene Session Keys ausgehandelt. Bei der Verwendung von Kerberos sollte der Zeitunterschied nicht über 5 Minuten betragen, und aus diesem Grund werden die beteiligten Systeme mit einem Zeitdienst (NTP) verbunden, damit die Uhren synchron laufen können. Diese Zeitsynchronisation schafft zusätzliche Sicherheit.

Kerberos lässt sich als Standardprotokoll zur Authentisierung einsetzen. Das Active Directory speichert die Schlüssel. Es ist möglich, Unix-Systeme mit Kerberos zu authentifizieren, beispielsweise mit Heimdal. Viele setzen Kerberos meistens nur im Intranet ein, obwohl es von der Grundidee für unsichere Netzwerke entwickelt ist. Da alle beteiligten Systeme in der gleichen Domäne zugeordnet sein müssen, eignet sich dieser Dienst nicht für öffentliche Internetapplikationen.

Da Kerberos eigentlich für Client-Server-Architekturen gedacht ist, hat man den Simple and Protected GSSAPI Negotiation Mechanism entwickelt, kurz SPNEGO (http://spnego.sourceforge.net/). So können webbasierte Anwendungen leichter per Kerberos authentifiziert werden. Ursprünglich sollte SPNEGO das Authentifizierungsprotokoll zwischen dem Client und dem Server aushandeln. Das ist nötig, wenn sich Client und Server nicht sicher sind, welches Authentifizierungsprotokoll verwendet werden soll. In der Praxis wird SPNEGO meist mit der Microsoft-HTTP-Negotiate-Erweiterung verwendet, besser bekannt unter dem Namen Integrated Windows Authentication (IWA). Unterstützt werden dabei sowohl NTLM als auch Kerberos. SPNEGO verwendet die vorhandenen Windows-Benutzerinformationen des Clients, respektive ein Kerberos-Ticket, und ermöglicht so SSO nach erfolgreichem Windows-Log-in. SPNEGO arbeitet mit den meisten modernen Webbrowsern zusammen, aber nicht mit allen Proxy-Servern . SPNEGO wird deshalb nur in Intranets eingesetzt.

SAML: Authentifizierung und Autorisierung inklusive

Der Security-Assertion-Markup-Language-Standard, kurz SAML, definiert die Verwendung von Identitätstokens, den SAML Assertions, sowie verschiedene Protokolle zum Austausch dieser Tokens für die Authentifizierung und die Autorisierung. Ziel ist in den meisten Fällen, ein Web-SSO zu erreichen. Ausgehend von der OASIS-Organisation hat SAML bereits eine längere Entwicklungsgeschichte hinter sich. 2005 wurde die Version 2.0 veröffentlicht, Version 2.1 ist in Arbeit. SAML erfreut sich steigender Beliebtheit, und viele Hersteller bewerben es stark, unter anderem SAP, Microsoft ADFS oder Ping Identity.

SAML wird vor allem im Zusammenhang mit Webapplikationen eingesetzt. Sie ermöglicht sowohl Authentifizierung als auch Autorisierung inklusive SSO. Zusätzlich kann SAML zur Föderation zwischen Securitydomänen eingesetzt werden, den so genannten Realms. Der Vorteil von SAML ist, dass sie den Aufwand für die Erbringung von SSO deutlich reduzieren kann. Versteht eine Applikation SAML, so kann sie mehrere Identity-Provider akzeptieren. Ein SAML Identity Provider wiederum kann mehrere Applikationen bedienen, der Benutzer muss sich nur einmal authentifizieren. Die SAML Assertion und Artefakte werden zwischen dem Identity-Provider (IdP) und dem Service-Provider (SP) verwendet (Abb. 2). Bevor der SP Assertions vom IdP akzeptiert, muss eine vertrauliche Verbindung erstellt werden. Dazu werden oft Zertifikate verwendet (X.509).

Das SAML-Protokoll definiert den Payload (die Assertion in XML) und den Transport. Die Assertion kann dabei Assertions für die Authentifizierung, die Attribute und die Authentifizierungsentscheidung enthalten. SAML findet immer in einer Dreiecksbeziehung statt.

takai_protokollfragen_2

Abb. 2: Security Assertion Markup Language (SAML)

Abb. 3: SAML-Identity-Provider-Initialisierung

Abb. 3: SAML-Identity-Provider-Initialisierung

Abb. 4: SAML-Service-Provider-Initialisierung

Abb. 4: SAML-Service-Provider-Initialisierung

Bei SAML werden zwei verschiedene Initialisierungen verwendet. Die erste Variante wird beim Zugang zu mehreren Applikationen verwendet und heißt IdP-Initialisierung. Hierbei sendet der IdP eine Liste der registrierten Services mit, für die die Authentifizierung gilt. Die Initialisierung funktioniert nach den folgenden Schritten, wie in Abbildung 3 dargestellt:

  1. Alice verlangt Zugang
  2. IdP sendet Alice eine Authentifizierungs-Challenge
  3. Alice authentifiziert sich
  4. Alice erfragt Services
  5. Alice erhält eine SAML Assertion
  6. Alice sendet Assertion an den Service
  7. Der SP erteilt Alice eine Session

Die zweite Variante wird bei einzelnen und verteilten Applikationen verwendet und funktioniert nach den folgenden Schritten (Abb. 4):

  1. Alice verlangt Zugang beim SP
  2. SP schickt Alice die Adresse des IdP
  3. Alice verlangt Zugang beim IdP
  4. IdP sendet Alice eine Authentifizierungs-Challenge
  5. Alice authentifiziert sich
  6. Alice erhält eine SAML Assertion
  7. Alice schickt die Assertion an den Service
  8. Der SP erteilt Alice eine Session

Beide Varianten sind funktional äquivalent und können austauschbar verwendet werden. Der SP definiert in seiner Assertion, was er vom IdP erwartet (z. B. Benutzername, Authentifizierungsmethode, Time Slot), der IdP liefert das Zertifikat, mit dem die Assertion geschützt wird und den URL, über den er erreicht wird. Nach Bedarf können weitere Informationen zwischen SP und IdP ausgetauscht werden. Kurze Requests werden dabei mit HTTP GET ausgetauscht, längere müssen wegen der Größenbeschränkung mittels HTTP Post Bindings übertragen werden. Typische Beispiele für SAML Assertions sind:

<saml:Issuer> enthält eindeutigen Identifier für den IdP
<ds:Signature> enthält die digitale Signatur, mit der die Assertion geschützt wird
<saml:Subject> enthält den User Principal
<saml:Conditions>: Bedingungen, die erfüllt sein müssen, damit eine Assertion gültig ist.
<saml:AuthnStatement>: Beschreibt den Vorgang der Authentifizierung beim IdP

SAML ist analog zu ADFS eine Claim-basierte Authentifizierung. Der IdP beantwortet die Frage „ist/ist nicht“ und der SP die Frage „darf/darf nicht“. Eine Alternative zu der klassischen SAML-Integration von Applikationen ist mit der Umsetzung eines Integrations-Proxies möglich. Dabei ist es möglich, nicht SAML-fähige Applikationen über den Integrationsproxy zu erreichen. Dieser kann z. B. Basic Auth oder Kerberos mit der nachgelagerten Applikation aushandeln. Dieses Verfahren wird angewandt, um Legacy-Applikationen in ein SAML SSO zu integrieren.

Abb. 5: SAML-Service-Provider-Proxy-Architektur

Abb. 5: SAML-Service-Provider-Proxy-Architektur

Das beliebte OAuth

OAuth ist ein Protokoll, das es ermöglicht, eine constrained Delegation vorzunehmen. Es wird heute in verschiedenen Versionen am Markt verwendet. Twitter setzt beispielsweise Version 1.0 ein. Version 2.0 ist leichtgewichtiger für Client-Apps und kommt daher gerne in Mobile-Apps zur Anwendung. Sie wurde von der IETF als RFC 6749 und RFC 6750 standardisiert. Die Verbreitung von OAuth wird noch deutlich mit der Verbreitung von mobilen und Web-Apps zunehmen und ist in diesen beiden Bereichen heute fast obligatorisch.

OAuth 2.0 ist als Authentifizierungsverfahren, das per REST integriert werden kann, im Gegensatz zu SAML deutlich leichtgewichtiger. Es bietet analog zu SAML eine delegierte Authentifizierung an, das heißt, das Passwort wird dabei nicht exponiert. OAuth arbeitet mit Access Tokens und funktioniert nach den Schritten aus Abbildung 6:

  1. Alice möchte auf eine Ressource zugreifen
  2. Der Policy Enforcement Point verweist Alice an den IdP zur Authentifizierung
  3. Alice authentifiziert sich beim IdP
  4. Der STS erteilt ein Token
  5. Der Policy Enforcement Point akzeptiert das Token
  6. Alice kann auf die Ressource zugreifen
Abb. 6: Fluss im OAuth-Protokoll

Abb. 6: Fluss im OAuth-Protokoll

Bei OAuth besitzen die Tokens nur eine beschränkte Lebensdauer, und deswegen erhält Alice auch ein Refresh Token, mit dem sie die Lebensdauer beim Policy Enforcement Point verlängern kann. Da Authentifizierungsinformationen mit allen Tokens transportiert werden, müssen die Tokens geschützt werden. Das ist nicht direkt in der OAuth-Spezifikation enthalten, es wird hierfür in der Regel TLS verwendet.

Bei der Auswahl der notwendigen Komponenten muss auf die Kompatibilität der Komponenten geachtet werden, speziell beim Policy Enforcement Point. Es funktionieren leider nicht alle Kombinationen. Firmen wie Google oder Amazon liefern detaillierte Konfigurationsbeispiele für die Implementierung. Viele OAuth-Service-Provider verwenden immer noch die erste OAuth-Version.

OpenID Connect – Passwort adieu!

OpenID Connect geht aus der OAuth-Version 2.0 und OpenID hervor und lässt sich als SSO-Verfahren für Web- und Native-Client-basierte Apps verwenden. OpenID Connect wurde von der OpenID Foundation im Februar 2014 standardisiert. Obschon OpenID im Namen steht, sind die Zusammenhänge zwischen OpenID und OpenID Connect technisch nur auf einem kleinen Nenner und sollten nicht verwechselt werden. Es gibt einen Migrationspfad von OpenID zu OpenID Connect. Für neue Implementierungen sollte nach Möglichkeit OpenID Connect verwendet werden. Das Protokoll verwendet JSON Payloads über REST, um Identifizierung und Authentifizierung möglichst einfach zu implementieren. OpenID Connect ermöglicht es Entwicklern, ihre Benutzer über Webseiten und Apps zu authentifizieren, ohne dass Passwörter verwendet oder gemanagt werden müssen. Google stellt für Entwickler eine Playground für OpenID Connect und OAuth 2.0 zur Verfügung. Der Protkollfluss ist in Abbildung 7 visualisiert und besteht aus den folgenden Schritten:

  1. Die Relying Party (RP) schickt eine Anfrage an den OpenID Provider (OP)
  2. Der OP authentifiziert Alice und kümmert sich um die Autorisierung
  3. Der OP antwortet mit einem ID und einem Access Token
  4. Die RP kann sich mit dem Access Token an den UserInfo Endpoint des OP wenden
  5. Der UserInfo Endpoint gibt Claims über Alice zurück
Abb. 7: OpenID-Connect-Protokoll

Abb. 7: OpenID-Connect-Protokoll

Fazit

Unternehmen, die es sich leisten können, ihre Authentifizierung mit einem SaaS-Provider durchzuführen, sollten ein möglichst einfaches Verfahren wählen, das maximale Sicherheit bietet. OpenID Connect ist hier eine Empfehlung von uns. Und das trotz der Tatsache, dass es noch nicht viele Identity-Provider gibt, die diesen Standard unterstützen. Für alle anderen kommt SAML in Frage, das heute eine weite Verbreitung genießt, aber aufwändiger zu implementieren ist. Grundsätzlich sollten die beschriebenen Protokolle und Verfahren dem Architekten bekannt sein.

Geschrieben von
Daniel Takai
Daniel Takai
Daniel Takai ist Enterprise-Architekt, arbeitet in der Schweiz und ist auf die digitale Transformation spezialisiert. Er berichtet regelmäßig im Java Magazin über seine Erfahrungen und Erkenntnisse. Im Frühling 2016 erscheint sein Buch über Methoden der Entwicklung von Cloud-basierten und serviceorientierten Websystemen.
Gion Manetsch
Gion Manetsch
Gion Manetsch ist Security-Architekt und arbeitet in Bern. Seine Aufgabe ist es, die Sicherheit im Aufbau von IT-Lösungen sicherzustellen, unter der Berücksichtigung von Businessanforderungen und Wirtschaftlichkeit. Dabei sollen keine Insellösungen gebaut werden, sondern immer die Gesamtsicht im Vordergrund stehen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.