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.
Fachartikel
Zugriffsrechte verwalten mit UMA 2.0
Im digitalen Ökosystem hat jeder Mensch und jedes Ding eine digitale Identität. Sie ermöglicht es Systemen, Diensten und Anwendungen zu wissen, mit wem sie interagieren. Für ein zukunftsfähiges Identitätsmanagement kommen bestimmte Architekturen zur Anwendung, etwa die Spezifikation User-Managed Access (UMA) 2.0. Im Fachbeitrag beleuchten wir die verschiedenen Rollen, die Architektur und inwiefern UMA 2.0 eine vertrauenswürdige Umgebung für die gemeinsame Nutzung von Ressourcen zwischen Personen erlaubt.
 |
|
UMA will den Benutzern und im Unternehmen die volle Kontrolle über Ressourcen und Daten ermöglichen.
|
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:
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.
Die Basis der UMA-2.0-Architektur bildet ein klar definiertes Rollenkonzept.
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:
- Kontaktieren des Authorization-Servers, um die Ressource einer anderen Person anzufordern
- Kontaktieren des Authorization-Servers, um ihre Identität anzugeben und eine Autorisierung zu erhalten
- die Ressource vom Resource-Server erhalten
- 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
Nachrichten
Der richtige Messenger: Tipps für die sichere Kommunikation unterwegs [26.01.2021]
Mit der letzten Aktualisierung seiner Nutzungsbedingungen hat WhatsApp eine Welle der Empörung bei vielen Nutzern ausgelöst. Infolgedessen haben sich etliche von ihnen nach Alternativen umgeschaut. Aber worin unterscheiden sich die Messenger überhaupt? Adolf Streda, Malware Researcher bei Avast, beleuchtet die Unterschiede und worauf es bei sicheren Messengern ankommt. [mehr]
SAP und Microsoft machen gemeinsame Sache [25.01.2021]
SAP und Microsoft planen, Microsoft Teams mit den Angboten von SAP zu integrieren. Zudem arbeiten beide Unternehmen daran, die bestehende Partnerschaft zur beschleunigten Einführung von SAP S/4HANA auf Azure auszuweiten. Die Kooperation beruht auf dem Vorhaben beider Unternehmen, den Umstieg in die Cloud für Kunden zu vereinfachen und zu verbessern. [mehr]
DDoS-Erpresser fassen nach [25.01.2021]
Cyberattacke bedroht Linux-Systeme [25.01.2021]
Tipps & Tools
Download der Woche: MaxLauncher [27.01.2021]
Für das zügige Arbeiten am Rechner haben sich Hotkeys bewährt. Die Standardkombinationen sind bekannt – wenn Sie die komplette Tastatur ausnutzen wollen, sollten Sie einen Blick auf das Tool "MaxLauncher" werfen. Damit lässt sich fast jeder Taste auf dem Keyboard eine Funktion zuweisen, etwa ein Programm, eine Datei oder einen Ordner zu öffnen. [mehr]
Mehrere Schwachstellen in dnsmasq entdeckt [26.01.2021]
Sicherheitsforscher haben sieben Schwachstellen in dnsmasq gefunden, einem beliebten Open-Source-DNS/DHCP-Server. Die sogenannten DNSpooq-Schwachstellen ermöglichen DNS Cache Poisoning sowie Remote-Code-Ausführung durch einen Pufferüberlauf. Betroffen seien mehr als 40 Unternehmen – neben Google auch Cisco und Redhat. [mehr]
