Für ein sicheres, zukunftsfähiges Identitätsmanagement für Anfragen auf Daten, Anwendungen oder Dienste kommen bestimmte Architekturen, Standards und Technologien zur Anwendung: Die Kantara Initiative hat in diesem Bereich die Spezifikation User-Managed Access (UMA) 2.0 entwickelt, die einen offenen Standard für die gemeinsame Nutzung von Ressourcen zwischen Personen beschreibt. UMA 2.0 ist hierbei eine Erweiterung des offenen Standardprotokolls OAuth 2.0, das eine sichere API-Autorisierung ermöglicht. OAuth 2.0 konzentriert sich auf die Einfachheit für Cliententwickler und bietet gleichzeitig spezifische Autorisierungsabläufe für Web- und Desktop-Anwendungen, Mobiltelefone und Smart-Home-Geräte.

Die UMA-2.0-Architektur basiert auf zwei Spezifikationen der Kantara-Initiative: Der "Federated Authorization" und der "Grant for OAuth 2.0 Authorization". Die Federated Authorization definiert eine standardbasierte Methode zur losen Kopplung des Authorization-Servers und des Resource-Servers im Kontext des Resource Owners. Die zweite Spezifikation ist ein Weg für einen Client (beziehungsweise eine Anwendung), der eine Requesting Party repräsentiert, Zugriff auf eine Ressource zu beantragen. UMA 2.0 und OAuth 2.0 ermöglichen damit eine vertrauenswürdige Umgebung für die gemeinsame Nutzung von Ressourcen zwischen Personen (Resource Owner und Requesting Party). Auch die Transaktionen zwischen den UMA-2.0-Rollen sind als Teil der Lösung vertrauenswürdig.

Die Rollen innerhalb der UMA 2.0-Architektur
Die UMA-2.0-Architektur definiert folgende Rollen: Resource Owner, Client, Requesting Party, Resource-Server und Authorization-Server. Der Resource Owner verwaltet den Zugang zu den Ressourcen. Es kann sich dabei entweder um eine Person oder um eine Organisation handeln, die im Wesentlichen als sogenannter "Producer" der Ressourcen fungiert. Unabhängig davon, ob es sich um Person oder Organisation handelt, muss der Resource Owner gegenüber dem Authorization-Server authentifiziert werden.

Der Resource Owner ist dafür verantwortlich, Ressourcen zu erstellen und festzulegen, wann der Resource-Server sie beim Authorization-Server registriert. Diese Registrierung umfasst die Pflege von Metadaten und die Verknüpfung mit digitalen Inhalten, die sich in einem externen System befinden. Er legt die Ressourcenberechtigungen (auch bekannt als Policies) fest, die wiederum steuern, wer auf was und in welchem Umfang Zugriff hat. Er kann vom Authorization-Server gebeten werden, Anträge auf Zugang zu Ressourcen und deren Genehmigung bzw. Ablehnung zu bearbeiten.

Der Client wird von der anfragenden Partei für den Zugriff auf Ressourcen verwendet. Ein Client kann eine browserbasierte Anwendung, eine mobile Anwendung, das Armaturenbrett eines Autos oder eine Smart-Home-Systemkonsole sein. Eine Clientanwendung wird im Allgemeinen zur Unterstützung bestimmter Organisationen oder Branchen implementiert.

Die Requesting Party ist in der Regel eine Person, die Zugang zu einer Ressource haben möchte, zum Beispiel ein Familienmitglied, ein Freund, ein Kollege oder ein Arzt. Auch die Requesting Party muss gegenüber dem Authorization-Server authentifiziert sein. Wenn eine Requesting Party auf eine Ressource zugreift, führt sie den folgenden Prozess über die von ihr verwendete Client-Anwendung durch:

1. Kontaktieren des Authorization-Servers, um die Ressource einer anderen Person anzufordern
2. Kontaktieren des Authorization-Servers, um ihre Identität anzugeben und eine Autorisierung zu erhalten
3. die Ressource vom Resource-Server erhalten

Der Resource-Server hostet Ressourcen für den Resource Owner und bearbeitet Anfragen zu Ressourcen von Requesting Parties. Ein Resource-Server hat in der Regel folgende Fähigkeiten:

• Offenlegung von unternehmens- und branchenspezifischen APIs im Zusammenhang mit Ressourcen
• Erlaubnis der Resource Owners, Ressourcen zu verwalten, etwa Dateien zu erstellen und zu bearbeiten
• Ressourcen bei einem Authorization-Server registrieren
• Durchsetzung von Einschränkungen bei der Zugangsgewährung, wenn Clients Zugang zu UMA- und OAuth-geschützten Ressourcen ersuchen

Ein Resource-Server lässt sich entweder durch die Entwicklung eines neuen Systems, die Erweiterung eines bestehenden Ressourcensystems oder durch die Bereitstellung eines Proxy-Services als Front-End für ein vorhandenes Ressourcensystem implementieren. ForgeRock bietet beispielsweise auf GitHub ein Open-Source-basiertes UMA-2.0-Resource-Server-Projekt an, das sich für die Entwicklung und Implementierung als Referenz eignet.



ln/Eve Maler, CTO ForgeRock sowie Gründerin und Leiterin der UMA-Arbeitsgruppe und Scott Fehrmann, Principal Systems Engineer bei ForgeRock