Autorisierung bezeichnet den Prozess, jemandem den Zugriff auf eine Ressource zu ermöglichen.

Natürlich ist diese Beschreibung eher vage, doch man kann sie anhand von Beispielen aus dem realen Leben veranschaulichen und das Konzept dann auf die Computerwelt übertragen.

Ein gutes Beispiel ist der Besitz eines Hauses. Der Hausbesitzer hat die vollständigen Zugriffsrechte auf die Immobilie (d. h. die Ressource), kann jedoch auch anderen Personen den Zugang dazu erteilen. Das heißt, der Besitzer autorisiert Personen zum Zugriff darauf. Anhand dieses einfachen Beispiels lassen sich einige Konzepte im Kontext der Autorisierung erläutern.

Beispielsweise ist der Zugang zum Haus eine Berechtigung, d. h. etwas, das man im Zusammenhang mit der Ressource tun darf. Andere Dinge, für die man im Zusammenhang mit dem Haus eine Berechtigung erhalten könnte, sind vielleicht die Möblierung, Reinigung, Reparatur usw.

Eine Berechtigung wird zum Privileg (oder Recht), wenn sie jemandem erteilt wird. Wenn Sie Ihrem Innenarchitekten also die Berechtigung erteilen, Ihr Haus einzurichten, erteilen Sie ihm dieses Privileg.

Andererseits kann der Innenarchitekt Sie auch um die Genehmigung bitten, das Haus einrichten zu dürfen. In diesem Fall ist die angefragte Berechtigung ein Scope, das heißt, eine bestimmte Aktion, die der Innenarchitekt in Ihrem Haus ausführen möchte.

Zuweilen hängt die Autorisierung in gewissem Maße auch mit der Identität zusammen. Stellen Sie sich vor, Sie möchten mit dem Flugzeug reisen. Auf Ihrer Bordkarte steht, dass Sie autorisiert sind, an Bord des Flugzeugs zu gehen. Das reicht dem Mitarbeiter am Flugsteig aber nicht, um Sie an Bord zu lassen. Sie müssen Ihre Identität mithilfe Ihres Passes nachweisen. In diesem Fall vergleicht der Mitarbeiter am Flugsteig den Namen im Pass mit dem Namen auf der Bordkarte und lässt Sie nur dann an Bord, wenn beide übereinstimmen.

Im Kontext der Autorisierung ist Ihr Name ein Attribut Ihrer Identität. Andere Attribute sind beispielsweise Ihr Alter, Ihre Sprache, Ihre Kreditkarte und alles, was in einem bestimmten Szenario sonst noch relevant ist.

Ihr im Pass angegebener Name ist ein Claim, das heißt eine Erklärung, die besagt, dass Sie dieses Attribut besitzen. Jemand, der Ihren Namen in Ihrem Pass liest, kann sich darauf verlassen, dass der Name stimmt, weil er der Regierung vertraut, die den Pass ausgestellt hat.

Die Bordkarte stellt zusammen mit dem Identitätsnachweis eine Art von Eintrittskarte, oder auch „Zugriffstoken“ dar, das Ihnen das Recht erteilt, das Flugzeug zu betreten.

In den oben beschriebenen Szenarien sehen Sie, dass der Autorisierungsprozess jemanden dazu befugt, Dinge zu tun, die andere nicht tun dürfen.

Computersysteme, die mit Autorisierung arbeiten, funktionieren ähnlich.

In Computersystemen gehören Autorisierungsregeln zu einem IT-Bereich, der als Identitäts- und Zugriffsmanagement (IAM) bezeichnet wird. Beim IAM können Autorisierung und Authentifizierung Systemmanagern dabei helfen, zu regulieren, wer Zugriff auf Systeme hat, und Client-Privilegien festzulegen. In IT-Systemen läuft die Autorisierung dabei ähnlich wie die Zugangskontrolle im realen Leben ab.

Stellen Sie sich ein Tool für die Zusammenarbeit wie Google Docs vor.

Die Anwendung ermöglicht Ihnen, Dokumente zu erstellen und mit anderen zu teilen. Andere Berechtigungen erteilen die Erlaubnis, ein Dokument zu aktualisieren, zu löschen oder zu kommentieren. Als Besitzer eines Dokuments können Sie es mit anderen teilen und eine oder mehr Zugriffsrichtlinien definieren. Sie können Ihr Dokument beispielsweise mit jemandem teilen, der nur Kommentare hinzufügen darf.

_In diesem Szenario gilt Folgendes:

Ressource ist das Dokument.

Ressourcenbesitzer ist der Nutzer, der das Dokument erstellt, d. h. der es besitzt

Autorisierter Nutzer ist der Nutzer, dem der Ressourcenbesitzer das Recht erteilt hat, das Dokument zu kommentieren.

Das folgende Diagramm zeigt die Autorisierung zum Zugriff auf die Ressource:

Es gibt verschiedene Autorisierungsstrategien, die Computer bei der Bereitstellung von Anwendungen einsetzen. Am gängigsten sind die rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) und die attributbasierte Zugriffskontrolle (Attribute-Based Access Control, ABAC). In letzter Zeit hat Auth0 auch die beziehungsbasierte Zugriffskontrolle (Relationship Based Access Control, ReBAC) näher untersucht. Es gibt noch weitere Alternativen wie z. B. die graphbasierte Zugriffskontrolle (Graph-Based Access Control, GBAC) und die benutzerbestimmbare Zugriffskontrolle (Discretionary Access Control, DAC). Jede dieser Strategien hilft Anwendungsentwicklern dabei, unterschiedliche Autorisierungsanforderungen und Autorisierungsdienste zu handhaben.

Ein Computersystem, das ABAC nutzt, definiert damit, ob ein Nutzer ausreichend Zugriffsprivilegien besitzt, um eine bestimmte Aktion auszuführen, basierend auf einem mit diesem Nutzer verknüpften Merkmal (Attribut oder Claim). Ein Beispiel für diesen Autorisierungsprozess wäre ein Online-Store, der alkoholische Getränke verkauft. Ein Nutzer muss sich im Online-Store registrieren und sein Alter nachweisen. Im Kontext der Autorisierung lässt sich dieses Szenario wie folgt beschreiben:

• Der Online-Store ist der Ressourcenbesitzer.

• Die alkoholischen Getränke sind die Ressource.

• Das bei der Registrierung validierte Alter des Verbrauchers ist ein Claim, d. h. der Nachweis für das Alter des Nutzers (Attribut).

Die Vorlage des Claims ermöglicht dem Store, die Zutrittsanfrage zum Kauf alkoholischer Getränke zu verarbeiten. In diesem Fall wird die Entscheidung, dem Nutzer Zugriff auf die Ressource zu erteilen, auf der Grundlage eines Nutzerattributs getroffen.

Bei der RBAC wird die Autorisierung wiederum als Berechtigung behandelt, die mit Rollen verbunden ist, nicht direkt mit Nutzern. Eine Rolle ist nichts weiter als ein Katalog von Berechtigungen. Stellen Sie sich vor, Sie arbeiten als Abteilungsleiter in einem Unternehmen. In dieser Funktion sollten Sie Berechtigungen haben, die Ihrer Rolle entsprechen, beispielsweise die Fähigkeit, Urlaubsanträge und Spesenanforderungen zu genehmigen, Aufgaben zuzuweisen usw. Um Ihnen diese Berechtigungen zu erteilen, würde ein Systemmanager zunächst eine Rolle namens „Abteilungsleiter“ (oder ähnlich) anlegen. Dieser Rolle würde er dann die entsprechenden Berechtigungen erteilen und Ihnen anschließend die „Abteilungsleiter“-Rolle zuweisen. Auch anderen Nutzern, die den gleichen Berechtigungskatalog benötigen, kann diese Rolle zugewiesen werden.

Der Vorteil der RBAC besteht darin, dass sie die Verwaltung der Autorisierungsprivilegien vereinfacht, da Systemmanager Nutzer und Berechtigung gebündelt anstatt einzeln bearbeiten können.

Die ReBAC untersucht die folgende Frage in Bezug auf die Autorisierung: „Hat dieser Nutzer eine ausreichende Beziehung zum Objekt bzw. zur Aktion, um den Zugriff darauf zu erhalten?“ Die Beziehung kann über ein Nutzerattribut gebildet werden, z. B. Mitglied einer mit dem Objekt zusammenhängenden Rollengruppe zu sein. Es kann sich aber auch um eine direkte Beziehung handeln, indem beispielsweise ein Dokument direkt mit einem Nutzer geteilt wird. Zuweilen müssen bei der Beteiligung unterschiedlicher Gruppen, Rollen, Organisationen und Objekte viele Knoten untersucht werden, um die Beziehung zwischen einem Nutzer und der versuchten Aktion zu etablieren. Welche Beziehungen kritisch für den Zugriff sind und mit welchen Berechtigungen diese Beziehungen verbunden sind, ist Sache desjenigen, der das ReBAC-System implementiert.

Auth0 hat vor Kurzem für die Developer Community eine Vorschau unserer in Entwicklung befindlichen „Auth0 Fine Grained Authorization“-Lösung auf Basis der ReBAC herausgegeben. Auf unserer Vorschauseite für Entwickler erfahren Sie mehr über unsere Fine Grained Authorization.

Lesen Sie unsere Einführung in IAM, um sich über weitere Themen rund um das Identitäts- und Zugriffsmanagement zu informieren.