imported>Aka: typografische Anführungszeichen

2024-09-04T19:58:28Z

typografische Anführungszeichen

Neue Seite

'''User Managed Access''' (UMA) ist ein [[OAuth#OAuth 2.0 und OpenID Connect|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''<ref>[https://kantara.atlassian.net/wiki/spaces/uma/overview UMA-Arbeitsgruppen-Wiki]</ref> hielt ihre erste Sitzung<ref>[https://kantara.atlassian.net/wiki/spaces/uma/pages/4857529/UMA+telecon+2009-08-06 UMA workgroup meeting minutes] </ref> 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 [[Web Resource Authorization-Protokoll|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 [[eXtensible Access Control Markup Language|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“<ref>https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dyn-reg Internet Draft: OAuth 2.0 Dynamic Client Registration Core Protocol</ref>, 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.<ref>https://forgerock.org/openuma/ OpenUMA</ref> Eine erste Implementierung des Autorisierungsservers<ref>https://forgerock.org/openam/ Autorisierungsservers</ref> ist mit OpenAM im ''nightly build'' zu testen.
Gluu hat UMA zur Sicherung und Verwaltung des Zugriffs auf APIs umgesetzt.<ref>{{Webarchiv|url=http://www.gluu.org/open-source/open-source-vs-on-demand/ |wayback=20140209133913 |text=Archivierte Kopie |archiv-bot=2019-05-20 18:22:13 InternetArchiveBot }} Gluu OSS implementation of UMA</ref> ''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.

== Einzelnachweise ==
<references />

== Weblinks ==
* [https://kantara.atlassian.net/wiki/spaces/uma/pages/4850556/UMA+FAQ UMA FAQ]
* [https://datatracker.ietf.org/doc/html/draft-hardjono-oauth-umacore Latest UMA Core Protocol Internet Draft]
* [https://kantara.atlassian.net/wiki/spaces/uma/pages/4857595/UMA+Trust+Model Latest UMA Binding Obligations spec]
* [https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ Final UMA dynamic client registration spec akzeptiert als OAuth Internet Draft]
* [https://kantara.atlassian.net/wiki/spaces/uma/pages/4849710/UMA+Implementations UMA Implementierungen]

[[Kategorie:Identifikationstechnik]]

User-Managed Access - Versionsgeschichte

imported>Aka: typografische Anführungszeichen