# User-Managed Access

User Managed Access (UMA) ist ein OAuth-basiertes Protokoll zur Verwaltung von Zugriffsrechten (engl.: „access management protocol“). Das Protokoll wird zurzeit in einem Entwurf für die Version 1.0 definiert. Diese Spezifikation definiert die rechtsverbindlichen Pflichten der Parteien, die an UMA-konformen Interaktionen teilnehmen. Die Entwicklung von UMA als Web-Standard findet in der Kantara-Initiative statt.

## Grundsätzliches

UMA basiert auf mehreren Hypothesen. Eine davon ist, dass eine Einwilligung (engl. „consent“) wenig komfortabel und nur eine schwache Zustimmung für die Ausübung der Kontrolle der Nutzer über die Weitergabe von vertraulichen Informationen ist. Ein weiterer Grund ist, dass die Verwaltung der zugestimmten Datenzugriffe einer Client-Anwendung zu einem Server nicht gut „skaliert“ (d. h. überproportional langsamer wird), wenn man viele Anwendungen nutzt. Ein anderer Grund ist, dass Autonomie und die Privatsphäre des Einzelnen Kontrolle und Transparenz erfordern, um Überblick in die mit einer Vielzahl von Parteien gemeinsam genutzten Daten zu bewahren, und das nicht nur zu Anwendungen, die der Benutzer selbst nutzt.
Dementsprechend konzentriert sich das Design von UMA darauf, wie ein Web-Benutzer die Autorisierungs-Server (AS) genannte Web-Anwendung nutzt. Mit dem AS werden die gemeinsam genutzten Web-Ressourcen (d. h. letztlich Daten und Informationen) geschützt. Diese Web-Ressourcen könnten sich auf einer beliebigen Anzahl von Servern befinden, die in UMA als „Resource Servers“ (RS) bezeichnet werden. Anwendungen, die die ursprüngliche Ermächtigung der Anwender sowie andere Personen oder Organisationen haben, können auf die geschützten Ressourcen durch anfordernde Client-Anwendungen zugreifen, solange diese mit den entsprechenden Benutzer-Richtlinien am AS konform sind (d. h. der Zugriff erlaubt ist). Diese Richtlinien oder das Regelwerk wird im Englischen als „policy“ bezeichnet.

## Geschichte und Hintergrund

Die Kantara-Initiative UMA Work Group hielt ihre erste Sitzung am 6. August 2009 ab. UMA-Design-Prinzipien und technische Auslegung wurden von früheren Arbeiten von Sun-Microsystems-Mitarbeitern im März 2008 begonnen, die ein Protokoll namens ProtectServe entwickelten. ProtectServe wurde von den Zielen der [Vendor Relationship Management] (VRM)-Bewegung und -Anstrengung ein Ableger namens „Feeds-basiertes VRM“ beeinflusst.
ProtectServe und die früheren Versionen von UMA nutzten das OAuth-1.0-Protokoll. Als OAuth durch die Veröffentlichung der WRAP-Spezifikation geändert wurde, wurden die Entwürfe für die UMA-Spezifikation angepasst.
UMA ist nicht von OpenID 2.0 abhängig. Allerdings verwendet es optional das OAuth-basierte OpenID-Connect-Protokoll zur Authentifizierung.
UMA hat auch keine Abhängigkeit von XACML als Mittel zur Beschreibung der Benutzerregeln und die Einholung der Richtlinien-Entscheidungen. UMA schreibt kein Format für das Regelwerk vor. Allerdings haben UMA und XACML einige Gemeinsamkeiten bei den Protokollflüssen.

## Aktueller Stand der Normung

Die UMA-WG-Charta richtet sich an die Internet Engineering Task Force (IETF) als eine mögliche Heimat für die UMA-Normungsarbeit. Zu diesem Zweck hat die Arbeitsgruppe mehrere Rohfassungen (engl. „internet draft“) der IETF zur Prüfung übergeben. Einer von ihnen, eine Spezifikation für „Dynamische Kundenregistrierung“, ist bereits als Arbeitspunkt für die „OAuth Working Group“ akzeptiert worden.

## Aktuelle Abwicklung und Akzeptanz-Status

Die UMA-Protokoll hat mehrere Implementierungen. Forgerock bietet eine erste Open-Source-Implementierung unter OpenUMA. Eine erste Implementierung des Autorisierungsservers ist mit OpenAM im nightly build zu testen. Gluu hat UMA zur Sicherung und Verwaltung des Zugriffs auf APIs umgesetzt. Cloud Identity Limited hat eine vollständige UMA-Implementierung für die Sicherung und Verwaltung des Zugriffs auf persönliche Informationen sowie Web-APIs. Einige andere haben gegenüber der Arbeitsgruppe Interesse an Implementierung und Interoperabilitätstests gezeigt.