von Redaktion IT-A…
Lesezeit
2 Minuten
Seite 2 - Zugriffsrechte verwalten mit UMA 2.0
Zentrale Stelle: Der Authorization-Server
Der Authorization-Server ist die zentrale Rolle der UMA-2.0-Architektur: Er schützt die Ressourcen auf dem Resource-Server. Ein UMA-2.0-Authorization-Server bietet eine vertrauenswürdige Freigabelösung, die zum einen das Oauth-2.0-Standardprotokoll wirksam einsetzt, zum anderen befähigt sie den Resource-Server, Berechtigungen für Zugriffsanfragen von Clientanwendungen zu erteilen. Darüber hinaus ermöglicht es der Authorization-Server einem Resource Owner, eine Vertrauensbeziehung zwischen ihm und einem oder mehreren Resource-Servern herzustellen, wodurch der Resource-Owner die gemeinsame Nutzung mehrerer Ressourcensätze, die an mehreren Standorten gehostet werden, von einer einzigen zentralen Schnittstelle aus steuern kann.
Außerdem kann der Authorization-Server sogenannte "Resource Access Tokens" für eine bestimmte Requesting Party, aus einer spezifischen Clientanwendung, für einen bestimmten Bereich ausgeben und Dienste zur Validierung der Access Tokens bereitstellen. Das bedeutet, dass der Client und die Requesting Party ebenfalls teilweises Vertrauen gewinnen. Zuletzt verwaltet der Authorization-Server Zugriffsanfragen, von der Einreichung durch die Requesting Party bis zur Genehmigung oder Ablehnung durch den Resource Owner.
Verwaltung und Zugriff auf Ressourcen
Der Resource Owner ist dazu berechtigt, seine eigenen Ressourcen zu verwalten, beispielsweise diese zu erstellen, zu aktualisieren oder zu entfernen. Der Eigentümer, der bei einem Authorization-Server authentifiziert ist, nutzt die Resource-Server-Schnittstellen (im Normalfall über eine Anwendung), um seine Ressourcen zu verwalten. Der Authorization-Server vertraut hierbei dem Resource-Server, da dieser über OAuth 2.0 als Client authentifiziert ist.
Resource-Server können dem Authorization-Server über den UMA-2.0-Registrierungsprozess eine Ressource hinzufügen. Sobald eine Ressource registriert ist, kann der Resource Owner eine Richtlinie hinzufügen, die festlegt, wer auf eine Ressource für bestimmte Bereiche zugreifen kann. Normalerweise verwendet der Resource Owner die Nutzeroberfläche oder APIs des Authorization-Servers, um diese Policies zu verwalten.
Das hat zur Folge, dass die Requesting Party nun auf die registrierten Ressourcen zugreifen kann. Nachdem der von der Requesting Party verwendete Client vom Resource-Server die Erlaubnis zum Zugriff auf eine Ressource erhalten hat, kontaktiert er den Authorization-Server, um ein Access Token zugeteilt zu bekommen. Mit einem gültigen Access Token kann die Requesting Party oder der Client die Ressource erhalten. Der Resource-Server validiert das Access Token und gibt Informationen zurück. Diese Informationen können Metadaten über die Ressource enthalten und/oder externe digitale Inhalte, die mit der Ressource verknüpft sind.
Eine Organisation kann UMA 2.0 verwenden, um Funktionalität zu bestehenden Diensten oder neuen Person-to-Person-Diensten hinzuzufügen. Anwendungen, die vom Resource Owner und der Requesting Party verwendet werden, lassen sich erweitern, um sichere Protokolle zu unterstützen. Die Funktionalität des Resource-Servers lässt sich einem bestehenden Dienst hinzufügen, der die Ressourcenverwaltung übernimmt. Alternativ könnte ein Resource-Server als Front-End zu älteren Ressourcenverwaltungssystemen dienen.
Fazit
Bei der UMA-2.0-Architektur geht es darum, den Benutzern und dem Unternehmen die volle Kontrolle über ihre Ressourcen und Daten zu ermöglichen. Der Resource Owner selbst verwaltet das Freigabewerkzeug, was bedeutet, dass die Organisation keine Helpdesk-Mitarbeiter zur Bearbeitung von Zugriffsanfragen benötigt. Der Anspruch der UMA-Arbeitsgruppe innerhalb der Kantara Initiative ist es, dass UMA es jedem Einzelnen ermöglicht, die Zugriffs- und Nutzungsrechte in Bezug auf persönliche digitale Vermögenswerte zentral zu verwalten, indem Access Tokens in maschinenlesbare Lizenzen umgewandelt werden. Die Gruppe arbeitet aktuell an einem Dokument, das einen größeren geschäftsrechtlichen Rahmen für eine Vielzahl von Anwendungsfällen der UMA-Technologie skizziert.
Denn Organisationen haben jetzt mehr Gründe denn je zuvor, Einzelpersonen in den Austausch mit persönlichen Daten einzubeziehen. Drei Faktoren tragen zu diesem Trend in besonderer Weise bei: Erstens die verschärften Datenschutzbestimmungen aufgrund der DSGVO, zweitens das Wissen der Verbraucher um mangelnde Sicherheit und Vertrauenswürdigkeit von Organisationen, und drittens sind es die Use Cases – insbesondere im Gesundheitswesen, bei Finanzdienstleistungen und im Internet der Dinge – die einen positiven Datenaustausch benötigen. UMA 2.0 geht auf diese Schlüsselanforderungen ein, und macht es so einfach, eine Zustimmung zum Datentausch zurückzuziehen, wie es ist, sie zu erteilen.
ln/Eve Maler, CTO ForgeRock sowie Gründerin und Leiterin der UMA-Arbeitsgruppe und Scott Fehrmann, Principal Systems Engineer bei ForgeRock
Der Authorization-Server ist die zentrale Rolle der UMA-2.0-Architektur: Er schützt die Ressourcen auf dem Resource-Server. Ein UMA-2.0-Authorization-Server bietet eine vertrauenswürdige Freigabelösung, die zum einen das Oauth-2.0-Standardprotokoll wirksam einsetzt, zum anderen befähigt sie den Resource-Server, Berechtigungen für Zugriffsanfragen von Clientanwendungen zu erteilen. Darüber hinaus ermöglicht es der Authorization-Server einem Resource Owner, eine Vertrauensbeziehung zwischen ihm und einem oder mehreren Resource-Servern herzustellen, wodurch der Resource-Owner die gemeinsame Nutzung mehrerer Ressourcensätze, die an mehreren Standorten gehostet werden, von einer einzigen zentralen Schnittstelle aus steuern kann.
Außerdem kann der Authorization-Server sogenannte "Resource Access Tokens" für eine bestimmte Requesting Party, aus einer spezifischen Clientanwendung, für einen bestimmten Bereich ausgeben und Dienste zur Validierung der Access Tokens bereitstellen. Das bedeutet, dass der Client und die Requesting Party ebenfalls teilweises Vertrauen gewinnen. Zuletzt verwaltet der Authorization-Server Zugriffsanfragen, von der Einreichung durch die Requesting Party bis zur Genehmigung oder Ablehnung durch den Resource Owner.
Verwaltung und Zugriff auf Ressourcen
Der Resource Owner ist dazu berechtigt, seine eigenen Ressourcen zu verwalten, beispielsweise diese zu erstellen, zu aktualisieren oder zu entfernen. Der Eigentümer, der bei einem Authorization-Server authentifiziert ist, nutzt die Resource-Server-Schnittstellen (im Normalfall über eine Anwendung), um seine Ressourcen zu verwalten. Der Authorization-Server vertraut hierbei dem Resource-Server, da dieser über OAuth 2.0 als Client authentifiziert ist.
Resource-Server können dem Authorization-Server über den UMA-2.0-Registrierungsprozess eine Ressource hinzufügen. Sobald eine Ressource registriert ist, kann der Resource Owner eine Richtlinie hinzufügen, die festlegt, wer auf eine Ressource für bestimmte Bereiche zugreifen kann. Normalerweise verwendet der Resource Owner die Nutzeroberfläche oder APIs des Authorization-Servers, um diese Policies zu verwalten.
Das hat zur Folge, dass die Requesting Party nun auf die registrierten Ressourcen zugreifen kann. Nachdem der von der Requesting Party verwendete Client vom Resource-Server die Erlaubnis zum Zugriff auf eine Ressource erhalten hat, kontaktiert er den Authorization-Server, um ein Access Token zugeteilt zu bekommen. Mit einem gültigen Access Token kann die Requesting Party oder der Client die Ressource erhalten. Der Resource-Server validiert das Access Token und gibt Informationen zurück. Diese Informationen können Metadaten über die Ressource enthalten und/oder externe digitale Inhalte, die mit der Ressource verknüpft sind.
Eine Organisation kann UMA 2.0 verwenden, um Funktionalität zu bestehenden Diensten oder neuen Person-to-Person-Diensten hinzuzufügen. Anwendungen, die vom Resource Owner und der Requesting Party verwendet werden, lassen sich erweitern, um sichere Protokolle zu unterstützen. Die Funktionalität des Resource-Servers lässt sich einem bestehenden Dienst hinzufügen, der die Ressourcenverwaltung übernimmt. Alternativ könnte ein Resource-Server als Front-End zu älteren Ressourcenverwaltungssystemen dienen.
Fazit
Bei der UMA-2.0-Architektur geht es darum, den Benutzern und dem Unternehmen die volle Kontrolle über ihre Ressourcen und Daten zu ermöglichen. Der Resource Owner selbst verwaltet das Freigabewerkzeug, was bedeutet, dass die Organisation keine Helpdesk-Mitarbeiter zur Bearbeitung von Zugriffsanfragen benötigt. Der Anspruch der UMA-Arbeitsgruppe innerhalb der Kantara Initiative ist es, dass UMA es jedem Einzelnen ermöglicht, die Zugriffs- und Nutzungsrechte in Bezug auf persönliche digitale Vermögenswerte zentral zu verwalten, indem Access Tokens in maschinenlesbare Lizenzen umgewandelt werden. Die Gruppe arbeitet aktuell an einem Dokument, das einen größeren geschäftsrechtlichen Rahmen für eine Vielzahl von Anwendungsfällen der UMA-Technologie skizziert.
Denn Organisationen haben jetzt mehr Gründe denn je zuvor, Einzelpersonen in den Austausch mit persönlichen Daten einzubeziehen. Drei Faktoren tragen zu diesem Trend in besonderer Weise bei: Erstens die verschärften Datenschutzbestimmungen aufgrund der DSGVO, zweitens das Wissen der Verbraucher um mangelnde Sicherheit und Vertrauenswürdigkeit von Organisationen, und drittens sind es die Use Cases – insbesondere im Gesundheitswesen, bei Finanzdienstleistungen und im Internet der Dinge – die einen positiven Datenaustausch benötigen. UMA 2.0 geht auf diese Schlüsselanforderungen ein, und macht es so einfach, eine Zustimmung zum Datentausch zurückzuziehen, wie es ist, sie zu erteilen.
ln/Eve Maler, CTO ForgeRock sowie Gründerin und Leiterin der UMA-Arbeitsgruppe und Scott Fehrmann, Principal Systems Engineer bei ForgeRock
