SCIM: System for Cross-domain Identity Management

Transkript

1 SCIM: System for Cross-domain Identity Management Nico Ritschel Technische Universität Darmstadt, Fachbereich Informatik, Hochschulstraße 10, Darmstadt Zusammenfassung. Die Zahl der angebotenen Internetdienste steigt seit Jahren immer weiter an. Da für viele Dienste ein Benutzerkonto erforderlich ist, wird es für Nutzer häufig zur Herausforderung, den Überblick zu behalten. Um dieses Problem zu lösen, bieten viele Anbieter Systeme an, bei denen nur noch ein einziges Benutzerkonto verwaltet werden muss, auf dessen Daten auch andere Dienste zugreifen können. Damit dies reibungslos funktioniert, sind gemeinsame Schnittstellen zwischen den verschiedenen Diensten erforderlich. SCIM ist eine solche Schnittstelle, die den Datenaustausch standardisieren und so eine bessere Kompatibilität aller Dienste erreichen will. Wie SCIM funktioniert, wie es in der Praxis eingesetzt wird und welche Vorteile und Herausforderungen SCIM mit sich bringt, wird in dieser Arbeit erläutert. 1 Einführung Ganz gleich, ob klassisch via Webbrowser, über Desktopprogramme oder über Apps für Mobilfunkgeräte der Zugriff auf das Internet als Datenquelle und Kommunikationsmedium wird immer alltäglicher. Für viele Internetdienste ist es dabei zwecks Autorisierung oder Personalisierung erforderlich, die Nutzerdaten zu erfassen und an ein Benutzerkonto (Account) zu binden. Gerade für Nutzer, die viele Dienste parallel verwenden, wird es somit zu einer zunehmenden Herausforderung, den Überblick und die Kontrolle über ihre bei den verschiedenen Anbietern und Diensten gespeicherten Daten zu behalten. Den Nutzer bei der Verwaltung seiner persönlichen Daten, Dokumente und Informationen zu unterstützen und dabei Komfort und Sicherheit gleichermaßen zu wahren, ist eines der Kernziele des Identitätsmanagements. 1.1 Cross-domain Identity Management Im Identitätsmanagement wird häufig der Begriff Domäne für ein Umfeld verwendet, in dem auf eine einzelne, zentral gespeicherte Kopie eines Benutzerdatensatzes zugegriffen wird. Eine Domäne ist dabei üblicherweise einem einzigen Diensteanbieter zugeordnet. Hat ein Nutzer Accounts bei verschiedenen Anbietern (d. h. in verschiedenen Domänen), gibt es unterschiedliche klassische Ansätze, seine Identität zu verwalten. Die technisch meist einfachste Möglichkeit

2 2 ist die vollständige Isolation der Datensätze der jeweiligen Domänen. Dieser überwiegend bei klassischen Internetdiensten verwendete Ansatz garantiert allerdings keinerlei Synchronisation der Datensätze, und auch eine domänenübergreifende Nutzung von Daten ist nicht möglich; stattdessen müssen für mehrere Anbieter relevante Daten für jede Domäne erneut erfasst werden. Dem gegenüber steht die Zentralisierung der gespeicherten Nutzerdaten. Hierbei greifen alle beteiligten Dienste auf die gleiche Nutzerdatenbank zu und teilen sich somit die gleiche Domäne. Bei diesem Ansatz tritt zwar keine Synchronitätsund Redundanzproblematik auf, allerdings hat der Nutzer keinerlei Kontrolle mehr darüber, auf welche Daten die einzelnen Anbieter zugreifen. Entsprechend ist dieser Ansatz schon aus Gesichtspunkten des Datenschutzes nur in begrenztem Rahmen, z. B. in Firmennetzwerken, möglich. Ein Ansatz, der versucht, die Vorteile beider Ansätze zu vereinen, ist das Cross-domain Identity Management (CIM). Hier besitzt zwar jeder Anbieter seinen eigenen Datensatz, d. h. seine eigene Domäne, es gibt jedoch Schnittstellen, die einen vom Nutzer kontrollierbaren Austausch und eine Synchronisation der Daten ermöglichen. Beim Datenaustausch sind in der Regel vier Basisfunktionalitäten zu beachten: die Authentifizierung des Nutzers, die Autorisierung des Zugriffs durch den Nutzer, die eigentliche Datenübertragung und die Protokollierung der abgerufenen Daten. [1] Bei der Authentifizierung bestätigt der Nutzer zunächst gegenüber der Datenquelle, d. h. gegenüber dem Anbieter, der seine Daten besitzt, seine Identität, z. B. über seine Login-Daten. Anschließend autorisiert er den Datenempfänger, auf die von diesem angeforderten Daten zuzugreifen. In der Regel bleibt die Autorisierung bis auf Widerruf bestehen, sodass ein späterer Datenabruf ohne Benutzerinteraktion möglich ist. Daraufhin erfolgt die eigentliche Datenübertragung in einem von beiden Seiten unterstützten Protokoll. Zuletzt ist es Aufgabe der Datenquelle, die erfolgten Zugriffe zu protokollieren und ggf. dem Nutzer zur Verfügung zu stellen. Abbildung 1 zeigt schematisch den Ablauf der ersten Verknüpfung von Datenquelle und Datenempfänger. Insbesondere die Authentifizierung und Autorisierung sind hier nicht im Detail dargestellt. Zudem werden bei CIM üblicherweise nicht nur einmalig Benutzerdaten ausgetauscht, auch die spätere Nutzeranmeldung beim Datenempfänger erfolgt durch eine erneute Authentifizierung gegenüber der Datenquelle. Diese bestätigt dann dem Datenempfänger die Identität des Nutzers. Der Vorgang wird häufig auch als Single Sign-on (SSO) bezeichnet und läuft ähnlich zur ersten Verknüpfung ab, wobei einige Punkte wie die Autorisation des Zugriffs übersprungen werden.

3 3 Abb. 1. Sequenzdiagramm der Verknüpfung von Datenquelle und -empfänger im CIM 1.2 SCIM als Werkzeug für Cross-domain Identity Management Für die Authentifizierung des Nutzers und auch die nachträgliche Autorisierung des Datenempfängers wurden in der Anfangszeit von CIM meist proprietäre Lösungen auf Basis der seit 2001 vom OASIS-Konsortium entwickelten Security Assertion Markup Language (SAML) verwendet. Das nicht auf SAML basierende OpenID ersetzte nach seiner Einführung im Jahr 2007 die meisten dieser Lösungen und gilt bis heute zusammen mit dem proprietären Facebook Connect als Quasi-Standard für CIM. [2] Vor allem für die eigentliche Übertragung der Nutzerdaten gab es jedoch lange Zeit keinen einheitlichen Standard. Die meist von den Diensteanbietern selbst entwickelten proprietären Lösungen führten dazu, dass aufgrund des hohen Inte-

4 4 grationsaufwands für jeden einzelnen Dienst eine Fokussierung auf soziale Netzwerke mit hohen Nutzerzahlen stattfand; hierzu zählen insbesondere Facebook, Twitter und Google (seit 2012 als Teil des Netzwerks Google+). Zudem entstand ein Markt von Software- und Plug-in-Lösungen, um Diensteanbietern die Integration mehrerer Datenquellen zu erleichtern. Um auch für die Datenübertragung einen einheitlichen Standard zu schaffen, wurde 2011 ein Entwurf für das System for Cross-domain Identity Management (SCIM) veröffentlicht, der von der Internet Engineering Task Force (IETF) aufgegriffen wurde und seitdem von dieser weiterentwickelt wird. Bei SCIM handelt es sich um ein Protokoll, das sich ausschließlich auf die Übermittlung von Nutzerdaten konzentriert und daher mit nahezu allen Lösungen zur Authentifizierung oder Autorisierung kompatibel ist. Ferner kann SCIM parallel zu anderen Lösungen angeboten werden, um einen schrittweisen Umstieg von bestehenden Systemen zu erleichtern. 2 Allgemeine Beschreibung von SCIM Gemäß der Spezifikation von SCIM stellt die Datenquelle dem Datenempfänger eine Schnittstelle (API) auf Basis des Hypertext Transfer Protocol (HTTP) bereit, über die Anfragen zu bestimmten Daten gestellt und beantwortet werden. Beim eigentlichen Datenformat, in dem Anfragen beantwortet werden, kann zwischen der seit 1998 vom World Wide Web Consortium (W3C) entwickelten Extensible Markup Language (XML) und der von Douglas Crockford spezifizierten JavaScript Object Notation (JSON) gewählt werden. 2.1 Spezifikation der SCIM-Schnittstelle Die SCIM-API basiert auf den Prinzipien des Representational State Transfer (REST), d. h., sie ist adressierbar, zustandslos und basiert auf HTTP. Adressierbarkeit bedeutet, dass jedes abfragbare Objekt, also hier z. B. ein Nutzer, einen eindeutigen Uniform Resource Identifier (URI) besitzt, über den er identifiziert werden kann. Zustandslosigkeit sagt aus, dass jede Abfrage für sich betrachtet alle relevanten Informationen enthalten muss, sodass die Datenquelle keinen Kontext früherer Abfragen kennen muss. [3] Über die API sind (immer unter Voraussetzung einer entsprechenden Autorisierung) sowohl lesende als auch schreibende Operationen möglich, die durch die entsprechenden HTTP-Kommandos ausgeführt werden. Ein lesender Zugriff verwendet dabei das GET-Kommando, während schreibende Zugriffe bei Änderungen die Kommandos PUT (vollständige Ersetzung eines Datensatzes) und PATCH (spezifische Änderung einzelner Werte) verwenden. Es ist auch möglich, über das POST-Kommando völlig neue Benutzer anzulegen oder über DELETE existierende Benutzer zu löschen. Allerdings beschränkt sich die praktische Nutzung fast ausschließlich auf lesende Zugriffe oder gezielte Änderungen einzelner Werte.

5 5 Beispiel für einen lesenden Zugriff auf die SCIM-API GET /Users/de100a f5c-ac15-b24df69935e6 Host: example.com Accept: application/json Neben der ID des gewünschten Benutzers (vgl. Abschnitt 2.2) kann auch angegeben werden, ob eine Antwort im JSON- oder im XML-Format gewünscht ist. Zudem ist es möglich, als Datenempfänger nach Benutzern zu suchen oder sich eine Liste aller Benutzer anzeigen zu lassen. Ob ein Datenanbieter diese Funktion unterstützt, wird ihm jedoch freigestellt. Beispiele für eine Änderung von Nutzerdaten (via PATCH-Kommando) und eine Suchabfrage befinden sich im Anhang. [4] 2.2 Spezifikation des SCIM-Datenformats Das SCIM-Datenformat ist grundsätzlich als Folge von Schlüssel-Wert-Paaren aufgebaut, wobei die erlaubten Schlüssel in der Spezifikation fest vorgegeben sind. Als Werte sind je nach Art des Schlüssels Boolsche Variablen, Zahlen, Zeichenketten, Datumsangaben nach ISO 8601, Datenfelder oder auch wiederum aus Schlüssel-Wert-Paaren bestehende komplexe Strukturen vorgesehen. Beispiele für verschiedene Schlüssel-Wert-Paare im JSON-Format: "username": "example", "displayname": "Edgar X. Ample", " s": [ "value": "example@gmail.com", "primary": true ], "active": true, "created": " T11:20:42Z" Nahezu alle im Datenformat spezifizierten Schlüssel sind optional, lediglich die Schlüssel schemas, id und username müssen bei jeder Lese- oder Schreiboperation gesetzt werden. schemas ist dabei ein Datenfeld, das alle genutzten Erweiterungen von SCIM (siehe Abschnitt 2.3) aufzählt. Die Zeichenkette id gibt einen eindeutigen, permanenten Bezeichner für den Nutzer an, für den üblicherweise ein 32-stelliger Universally Unique Identifier (UUID) verwendet wird. Die Zeichenkette username gibt ebenfalls einen eindeutigen Bezeichner an, der allerdings in der Regel vom Benutzer selbst gewählt wurde und für den z. B. dessen Login-Name verwendet werden kann. Weiterhin definierte, optionale Schlüssel umfassen Namens- und Adressdaten, Kontaktinformationen, regionale Informationen wie präferierte Sprachen

6 6 und Zeitzonen, Gruppenzugehörigkeiten sowie Zertifikate für die sichere Kommunikation. Eine Besonderheit sind dabei die Gruppenzugehörigkeiten, da die darin aufgeführten Gruppenbezeichner ebenfalls über die SCIM-Schnittstelle abgefragt und so andere Mitglieder erfragt werden können. Es wird außerdem empfohlen, zu jeder Antwort der Schnittstelle noch Metadaten bereitzustellen, die üblicherweise das Datum der Benutzerregistrierung und der letzten Datenänderung erfassen. [5] 2.3 Erweiterbarkeit von SCIM SCIM bietet neben den bereits aufgeführten, fest definierten Schlüsseln auch die Möglichkeit, die vorgegebene Spezifikation zu erweitern. Daten aus Erweiterungen werden dabei in einem separaten Block, dessen Schlüssel der Name der Erweiterung ist, gesendet, sodass dieser einfach ignoriert werden kann, wenn der Empfänger die Erweiterung nicht unterstützt. Die SCIM-Spezifikation definiert bereits selbst eine erste Erweiterung, die sich auf Daten im geschäftlichen Umfeld spezialisiert. Über diese Erweiterung können beispielsweise Personalnummer, Abteilung oder Vorgesetzte übertragen werden. Ein Beispiel für einen vollständigen Benutzerdatensatz inkl. geschäftlicher Daten befindet sich im Anhang. [5] 3 Realisierte Implementationen von SCIM Bei SCIM handelt es sich wie bereits erwähnt ausschließlich um einen Standard. Von Seiten der IETF wird zudem keine Referenzimplementation einer SCIM-API bereitgestellt, auf der andere Implementationen aufbauen können. Allerdings existiert mit OpenSCIM eine unter der GNU General Public License (GPL) frei lizenzierte Implementation in den Programmiersprachen Java und C#, die sich sehr nah am Standard orientiert. Daneben existieren noch zahlreiche weitere Implementationen unter freien und proprietären Lizenzen, u. a. von Cisco, McAfee und Ping Identity, die oft in komplexere Daten-und Benutzerverwaltungssysteme integriert sind. Beispielhaft wird im Folgenden neben OpenSCIM auch auf die recht verbreitete freie Implementation von Gluu eingegangen, die unter der freien MIT License steht. 3.1 OpenSCIM Die 2011 zu großen Teilen von Matthew Crooke entwickelte SCIM-Implementation OpenSCIM unterstützt das gesamte Spektrum der SCIM-API. Die Java- Variante des Projekts basiert auf dem Framework Spring und nutzt für die Kommunikation über HTTP die Erweiterung Spring Web Services. Die C#-Variante verwendet die von Microsoft entwickelte Windows Communication Foundation (WCF).

7 7 Beide Varianten der Implementierung bieten kein integriertes Backend zur Verwaltung oder Speicherung der über SCIM empfangenen oder gesendeten Daten, sondern lediglich Schnittstellen, um eine Anbindung an vorhandene Benutzerverwaltungssysteme zu ermöglichen. Die am weitesten ausgearbeitete und von Varianten der Implementierung unterstützte Schnittstelle ist dabei die zum Verzeichnisdienst-Protokoll Lightweight Directory Access Protocol (LDAP). Diese ermöglicht es, mit geringem Aufwand schon existierende, ebenfalls LDAPkompatible Benutzer-Verwaltungssysteme, wie z. B. den Microsoft Active Directory Service, anzubinden. OpenSCIM ist derzeit vollständig implementiert, allerdings nur sehr spärlich dokumentiert. Außerdem wurden seit Ende 2011 keine weiteren Aktualisierungen der Software mehr vorgenommen, sodass nicht mit einer zeitnahen Behebung von Fehlern oder einer Unterstützung von zukünftigen SCIM-Versionen (siehe Abschnitt 4.2) zu rechnen ist. 3.2 Gluu Das frei lizenzierte Benutzerverwaltungssystem Gluu unterstützt ebenfalls SCIM als Schnittstelle zum Datenaustausch. Im Gegensatz zu OpenSCIM wird hier jedoch auch ein vollständiges Backend zur Speicherung und Verwaltung von Nutzerdaten auf Basis von LDAP mitgeliefert. Neben der angebotenen freien Implementierung bietet die Entwicklerfirma Gluu Inc. auch kommerzielle Lösungen in Form von technischem Support, Komplettpaketen inkl. Server-Hardware oder auch vollständigem Hosting des Servers durch Gluu Inc. an. Nach Aussagen des Entwicklers ist Gluu besonders auf hohe Skalierbarkeit ausgelegt und unterstützt neben SCIM auch andere, proprietäre Protokolle; zudem bietet Gluu eine Vielzahl von Authentifizierungslösungen. Die SCIM- Schnittstelle von Gluu wurde im Jahr 2013 regelmäßig gepflegt und weiterentwickelt, sodass eine zeitnahe Unterstützung von zukünftigen SCIM-Versionen (siehe Abschnitt 4.2) wahrscheinlich ist. 4 Bewertung von Cross-domain Identity Management Im Vergleich zum klassischen Identitätsmanagement innerhalb einer einzelnen Domäne bietet Cross-domain Identity Management zahlreiche Vorteile, verursacht jedoch auch neue Probleme und Risiken. Im Folgenden werden diese erläutert und Lösungsansätze aufgezeigt. Dabei wird ein besonderer Fokus auf Vorteile und Risiken bezüglich der Sicherheit gelegt. 4.1 Vorteile von Cross-domain Identity Management Einer der zentralen Vorteile von CIM ist das Verschieben der Nutzerauthentifizierung in die Domäne der Datenquelle. Somit benötigt der Nutzer lediglich einen einzigen Satz von Zugangsdaten, um sich bei vielen Diensteanbietern unabhängig voneinander einzuloggen. In der Praxis kann dies dazu führen, dass

8 8 der Nutzer ein sichereres Passwort für die Authentifizierung bei der Datenquelle wählen kann und die Gefahr, dass er es verliert oder vergisst, sinkt. Gleichzeitig entsteht durch CIM nicht das Risiko, dass eine Sicherheitslücke bei einem Diensteanbieter auch die Zugangsdaten aller anderen Anbieter kompromittiert, wie es beispielsweise bei einer gemeinsamen Domäne oder der Wahl der gleichen Zugangsdaten für mehrere Dienste der Fall wäre. Stattdessen wären beim Auftreten einer Sicherheitslücke grundsätzlich nur die an den unsicheren Dienst freigegebenen Daten offengelegt. Der automatisierte Austausch von Daten mit neuen Diensten erhöht generell den Komfort für den Nutzer, da auch größere Datenmengen wie Adressbücher oder Bildergalerien schnell und ohne manuelles Eingreifen übertragen werden können. Die hohe Automatisierung der Datenübertragung hat außerdem den Vorteil, dass typische Fehlerquellen menschlicher Interaktionen (z. B. Tippfehler oder auch bewusste Datenmanipulation)vermieden werden. Ein weiterer Vorteil von CIM ist die automatische Synchronisierung von Datenänderungen zwischen Datenquelle und Diensteanbietern. Dies kann sich sowohl hinsichtlich Funktionalität oder Nutzerkomfort als auch im Hinblick auf sicherheitsrelevante Aspekte vorteilhaft für den Nutzer auswirken. So kann beispielsweise eine Änderung an den Berechtigungen oder dem Status des Benutzeraccounts umgehend an alle davon betroffenen Dienste weitergeleitet werden, ohne dass durch manuelles Eingreifen zeitliche Verzögerungen entstehen. 4.2 Probleme und Risiken von Cross-domain Identity Management Einige der Vorteile von CIM bringen auch neue Risiken mit sich. So senkt die Nutzerauthentifizierung gegenüber der Datenquelle zwar prinzipiell die Gefahr, die von Sicherheitslücken bei den Diensteanbietern ausgeht, gleichzeitig wird aber das Ausmaß der Schädigungen, die Sicherheitslücken bei der Datenquelle mit sich bringen können, deutlich erhöht. Kann sich beispielsweise ein Angreifer Zugriff auf das Benutzerkonto bei der Datenquelle verschaffen, kann er auf diese Weise auch in alle Benutzerkonten bei angebundenen Diensten eindringen. Die Datenquelle wird so auch zu einem lohnenswerten Ziel für Attacken gegen den Nutzer, wie beispielsweise Phishing. Insbesondere bei einem nicht verantwortungsvollen Umgang des Nutzers mit seinen Zugangsdaten bei der Datenquelle steigt für ihn folglich das Risiko, durch einen Fehler gleich eine Vielzahl von Benutzerkonten zu gefährden. Doch auch ohne Angriffe von außen kann ein Sicherheitsrisiko entstehen, wenn beispielsweise die Datenquelle ihren Dienst einstellt. Da die Diensteanbieter in der Regel keine lokalen Zugangsdaten mit dem Nutzer ausgehandelt haben, ist dann eine Authentifizierung ohne Unterstützung der Datenquelle nicht mehr möglich. Dabei ist nicht einmal zwingend ein dauerhafter Ausfall der Datenquelle erforderlich. Bereits temporäre Probleme beeinträchtigen automatisch die Verfügbarkeit aller verbundenen Dienste. Somit ist sowohl seitens des Nutzers als auch seitens des Diensteanbieters eine hohe Abhängigkeit von der Datenquelle gegeben.

9 9 Ein weiterer Aspekt, der Risiken beinhaltet, ist der Komfort für den Nutzer. Da die Datenübertragung automatisch im Hintergrund abläuft, kann der Nutzer leicht den Überblick darüber verlieren, welche Daten tatsächlich an den Diensteanbieter gesendet werden. In der Praxis ist die Autorisierung des Datenzugriffs nicht immer transparent gestaltet, sodass Nutzer unbewusst viele Daten mit Anbietern teilen können, ohne dies wirklich zu beabsichtigen. Zuletzt sei auch noch angemerkt, dass durch CIM eine zusätzliche Komplexität entsteht. Für jeden der in Abschnitt 1.1 erwähnten Schritte (Authentifizierung, Autorisierung, Datenübertragung, Protokollierung) sind ein Entwurf und eine Implementation von Protokollen und Verfahren erforderlich, die alle für sich das Risiko von Fehlern oder Sicherheitslücken mit sich bringen. 4.3 Vorteile und Herausforderungen von SCIM Im Vergleich zu den proprietären Protkollen, die vor der Einführung von SCIM verbreitet waren, liegt ein Vorteil von SCIM in der öffentlichen Zugänglichkeit und Einheitlichkeit. Dies ist besonders für Diensteanbieter, die mehrere Datenquellen parallel unterstützen möchten, eine große Erleichterung. So genügt es nun, die Unterstützung für SCIM zu implementieren, um anschließend auf alle Datenquellen, die SCIM unterstützen zugreifen zu können. Dass SCIM sich dabei ausschließlich auf die Datenübertragung beschränkt, hat den Vorteil, dass die sicherheitsrelevanten Protokolle zur Authentifizierung oder Autorisierung, die meist schnelleren Entwicklungszyklen unterliegenden, unabhängig von SCIM verändert oder aktualisiert werden können. Gerade durch den Fokus auf die Datenübertragung ergibt sich jedoch das folgende Problem: Da neben SCIM auch noch Authentifizierung und Autorisierung berücksichtigt werden müssen, für die es zwar weitverbreitete Lösungen, aber keinen einheitlichen Standard gibt, wird die Grundidee, ein einheitliches Protokoll zu schaffen, aufgeweicht. Ein weiteres Problem von SCIM ist das in Abschnitt 2.3 erläuterte Konzept der Erweiterbarkeit: So ist es zwar grundsätzlich möglich, SCIM um neue Datenschlüssel zu erweitern, doch geht hierdurch auch die Einheitlichkeit des Protokolls verloren, da nicht garantiert werden kann, dass alle Datenquellen die gleichen Erweiterungen verwenden und unterstützen. Eine technische Stärke von SCIM ist die Nutzung von HTTP zur Datenübertragung. Dies ermöglicht eine Datenübertragung auch in stark abgesicherten Netzen, da keine speziellen Ports für eine Verbindung benötigt werden. Außerdem hat SCIM, vor allem wenn es zusammen mit JSON verwendet wird, ein sehr effizientes Datenformat mit einer hohen Dichte an Nutzerdaten. Aus Sicherheitsgründen ist die Nutzung von HTTPS, d. h. verschlüsseltem HTTP, unter der Verwendung von Transport Layer Security (TLS) in SCIM verpflichtend vorgeschrieben. Dies ist insbesondere im Hinblick auf die in der Regel bestehende Vertraulichkeit der übertragenen Daten eine sehr sinnvolle Einschränkung. Da TLS bereits seit mehreren Jahrzehnten existiert und heute weitverbreitet genutzt wird, ist hier nicht mit Kompatibilitätsproblemen zu rechnen. SCIM macht aus Gründen der Auf- und Abwärtskompatibilität ausdrücklich keine Vorgaben hinsichtlich der verwendeten Version von TLS, sodass

10 10 die Anbieter in der Pflicht sind, eine aktuelle Version des Protokolls zu verwenden. Die größte Herausforderung von SCIM liegt derzeit darin, den Standard tatsächlich in der Praxis zu etablieren. Wird keine flächendeckende Unterstützung von SCIM durch alle großen Diensteanbieter erreicht, stellt es lediglich ein weiteres Verfahren unter vielen dar, das eher zur Diversifizierung statt zur Standardisierung beiträgt. 5 SCIM in der Praxis und zukünftige Entwicklungen Während CIM in den letzten Jahren enorm an Verbreitung und damit auch an Bedeutung gewonnen hat, verändert sich der Markt in einem hohen Tempo weiter, sowohl in technischer Hinsicht als auch im Hinblick auf die Form der angebotenen Möglichkeiten. Im Folgenden wird auf die derzeitige Rolle von SCIM innerhalb dieses Markts eingegangen und ein Ausblick auf die Zukunft gegeben. 5.1 Verwendung von SCIM in der Praxis Bis zum Jahr 2011 haben sich bereits zahlreiche, meist proprietäre Lösungen für Identitätsmanagement auf dem Markt etabliert. Seit der Einführung von SCIM sind einige Anbieter von Lösungen auf SCIM umgestiegen oder bieten zumindest eine Unterstützung dafür an. Dennoch ist SCIM noch weit davon entfernt, den Status eines allgemeingültigen Standards erreicht zu haben. Insbesondere von sozialen Netzwerken wie Facebook, Twitter oder Google+ wird SCIM nicht unterstützt. Vor allem bei Google+ ist dies verwunderlich, da die dort genutzte proprietäre API seit dem Erscheinen von SCIM stark überarbeitet wurde und in ihrer derzeitigen Form auch deutlich an SCIM angelehnt (wenn auch nicht kompatibel) ist. Einer der wesentlichen Gründe, weshalb sich SCIM im Bereich der sozialen Netzwerke nicht durchsetzen konnte, ist die Tatsache, dass SCIM die Vernetzung von Nutzern untereinander nur sehr vereinfacht darstellen kann und auch nicht darauf ausgelegt ist, umfangreiche Abfragen nach Benutzerbeziehungen zu unterstützen. Hier setzen die Betreiber der Netzwerke vor allem auf komplexe Graphenstrukturen, die die Verbindungen von Nutzern erfassen und zugänglich machen sollen. Inwiefern hier Potenzial besteht, SCIM in späteren Versionen entsprechend zu erweitern, ist noch nicht absehbar. [6] Tatsächlich zum praktischen Einsatz kommt SCIM vor allem im Business- Bereich, in dem Softwarelösungen für firmeninternes Identitätsmanagement SCIM mehrheitlich unterstützen oder angegeben wird, in zukünftigen Versionen eine Unterstützung einführen zu wollen. Hier ist auch eine deutlich bessere Kompatibilität mit der Struktur von SCIM gegeben, da meist eine kleinere Zahl von Nutzern vorliegt, bei denen der Fokus stärker auf den eigenen Daten und Informationen als auf ihren Beziehungen untereinander liegt.

11 SCIM 2.0 und zukünftige Entwicklungen Von der IETF wird derzeit an einer neuen Version von SCIM unter dem Namen SCIM 2.0 gearbeitet. Diese befindet sich aktuell noch in der Entwurfsphase, eine Veröffentlichung ist aber für 2014 geplant. Bei SCIM 2.0 wurden gegenüber SCIM einige Änderungen durchgeführt, die jedoch eher im Detail zu finden sind. Bei der API besteht der wesentliche Unterschied zur aktuellen Version darin, dass weniger Abweichungen toleriert werden und viele Details des API- Verhaltens nun genauer beschrieben sind. So sind unter anderem die URLs, unter denen Benutzer und Gruppen abgefragt werden können, genau festgelegt und nicht mehr wie zuvor nur als Empfehlung vorgesehen. Zudem sind Rückmeldungen bei Fehlern klarer definiert, und die Möglichkeiten beim Suchen von Nutzern wurden erweitert. [7] Beim Datenformat ist das Mitsenden von Metadaten, z. B. wann ein Benutzer oder eine Gruppe erstellt und zuletzt verändert wurde, nun zwingend vorgeschrieben. Außerdem wurden einige Schlüsselwörter hinzugefügt, die vor allem auf die Kompatibilität mit sozialen Netzwerken abzielen. Unter anderem können jetzt auch Profilfotos des Nutzers übertragen werden. [8] SCIM 2.0 ist durch die genauere Spezifikation vieler Details nicht abwärtskompatibel. Allerdings kann ein Server durch das Mitsenden der Versionsnummer bei Anfragen grundsätzlich zu allen SCIM-Versionen gleichzeitig kompatibel sein. Da die Änderungen nur geringfügig sind, ist ein schneller Umstieg von bestehenden SCIM-Anbietern auf SCIM 2.0 abzusehen, sobald die Spezifikation final verfügbar ist. Die Änderungen am Standard sind jedoch nicht erheblich genug, um einen großen Einfluss auf die Verbreitung von SCIM zu erzielen. Die im vorherigen Abschnitt beschriebenen Probleme, die viele Anbieter von einer Nutzung abhalten, bestehen auch weiterhin. 6 Fazit In einer modernen, vernetzten Welt ist ein flexibles, den Bedürfnissen seiner Benutzer angepasstes Identitätsmanagement von zentraler Bedeutung und gleichzeitig eine große Herausforderung. Cross-domain Identity Management ist ein möglicher Ansatz, sich dieser Herausforderung durch eine Vernetzung verschiedener Interessenparteien zu stellen. Eines der Kernprobleme von CIM, die Schaffung von einheitlichen Standards und Schnittstellen, versucht das Protokoll SCIM zu lösen. SCIM versucht dabei, möglichst gut mit anderen Protokollen im Einklang zu arbeiten, und konzentriert sich auschließlich auf die Datenübertragung. Es versucht, diese zu vereinheitlichen und dennoch ein Mindestmaß an Flexibilität zu wahren. Hierzu setzt es auf weitverbreitete Standards wie HTTP und JSON und auf die Prinzipien von REST, die eine effiziente, intuitive Nutzung sichern sollen. SCIM kann sowohl Datensätze von Nutzern lesen als auch verändern oder neu erstellen. Zudem besitzt es viele weitere Möglichkeiten zur Nutzerfilterung und -verwaltung.

12 12 Sowohl CIM als auch SCIM haben zwar viele Vorteile, bringen aber auch ganz eigene Probleme mit sich. CIM erleichtert insbesondere die Synchronisierung von Datensätzen und kann zusätzlichen Komfort für den Nutzer schaffen. Dabei sorgt es aber auch für eine Zentralisierung der Datenverwaltung, die zu einer Abhängigkeit von den Anbietern und einem erhöhten Sicherheitsrisiko führen kann. SCIM versucht, dieser Abhängigkeit entgegenzuwirken, indem es die Interoperabilität zwischen verschiedenen Anbietern erhöht, kann das Problem jedoch nicht alleine lösen und belässt besonders beim Thema Sicherheit die Verantwortung bei den Anbietern. Während CIM immer mehr Verbreitung findet, ist SCIM noch sehr neu auf dem Markt und findet derzeit noch kaum praktische Anwendung. Zwar gibt es bereits eine Vielzahl an Implementierungen von SCIM auf freier und kommerzieller Basis, dennoch schrecken gerade größere Anbieter vor einer Implementierung zurück. Vor allem die Untersützung durch die IETF könnte SCIM in Zukunft einen stärkeren Zugang zum Massenmarkt und der Verwendung durch Branchengrößen ermöglichen. Insbesondere hinsichtlich der fragwürdigen Skalierbarkeit und der starken Konkurrenzsituation durch proprietäre Alternativen bleibt es allerdings abzuwarten, ob SCIM in absehbarer Zeit ein Durchbruch gelingt. Literatur 1. Ping Identity Corporation: Simple Cloud Identity Management (SCIM), 2011, mf/white paper/simple-cloud-identity-management-scim.pdf, Stand: TechCrunch: OpenID Welcomes Microsoft, Google, Verisign and IBM, 2011, Stand: IBM developerworks: RESTful Web services: The basics, 2011, Stand: IETF Network Working Group: System for Cross-Domain Identity Management: Protocol 1.1, 2013, 01.html, Stand: IETF Network Working Group: System for Cross-Domain Identity Management: Core Schema 1.1, 2013, 01.html, Stand: Kim Cameron: Yes to SCIM. Yes to Graph., 2013, Stand: IETF Network Working Group: System for Cross-Domain Identity Management: Protocol 2.0, 2013, Stand: IETF Network Working Group: System for Cross-Domain Identity Management: Core Schema 2.0, 2013, Stand:

13 13 Anhang Anhang A: Beispiel für eine Änderung von Benutzerdaten via PATCH-Kommando Entnommen und gekürzt aus der Spezifikation des SCIM Protocol [4] Anmerkung: Der Befehl If-Match in Zeile 5 stellt sicher, dass seit dem letzten Abruf des Benutzers keine Änderungen von Dritten vorgenommen wurden. PATCH /Users/2819c223-7f76-453a-919d Host: example.com Accept: application/json Content-Type: application/json If-Match: W/"a330bc54f0671c9" "schemas": ["urn:scim:schemas:core:1.0"], " s": [ "value": "bjensen@example.com", "primary": true ] Anhang B: Beispiel für eine Suchabfrage über die Anzeigenamen aller Benutzer, deren Benutzername mit b anfängt Entnommen und gekürzt aus der Spezifikation des SCIM Protocol [4] Anmerkung: Der Ausdruck username sw "b" steht für die Filterung nach Benutzernamen, die mit einem b anfangen. GET /Users?attributes=displayName&filter=userName sw "b" Host: example.com Accept: application/json Antwort des Servers: "totalresults":1, "schemas":["urn:scim:schemas:core:1.0"], "Resources":[ "displayname":"babs Jensen" ]

14 14 Anhang C: Beispiel für einen vollständigen Benutzerdatensatz mit Erweiterung für geschäftliche Daten Entnommen und gekürzt aus der Spezifikation des SCIM Core Schema [5] "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:enterprise:1.0"], "id": "2819c223-7f76-453a-919d ", "username": "displayname": "Babs Jensen", " s": [ "value": "bjensen@example.com", "type": "work", "primary": true ], "addresses": [ "streetaddress": "100 Universal City Plaza", "locality": "Hollywood", "country": "USA", "formatted": "100 Universal City Plaza\nHollywood, USA", "type": "work", "primary": true ], "usertype": "Employee", "title": "Tour Guide", "preferredlanguage":"en_us", "locale": "en_us", "active":true, "groups": [ "value": "e9e30dba-f08f d5c6a331660a", "display": "Tour Guides", "value": "fc348aa eb-a20b-c726e15c55b5", "display": "Employees" ], "urn:scim:schemas:extension:enterprise:1.0": "employeenumber": "701984", "costcenter": "4130", "organization": "Universal Studios",

15 15 "division": "Theme Park", "manager": "managerid": " e4-49d8ca9f808d", "displayname": "John Smith", "meta": "created": " T04:56:22Z", "lastmodified": " T04:42:34Z"