Fein-granulare Autorisierung – warum der Hype?

Identifikation – Authentisierung – Autorisierung?

Die Zentralisierung der Identifikation des Benutzers und dessen Authentisierung an einem Identity Provider kann als gelöst betrachtet werden – denn sowohl OAuth als auch SAML bieten hierfür jeweils für verschiedene Szenarien passende Lösungen und eine Vielzahl an kommerziellen und kostengünstigen Open Source Lösungen sind verfügbar. Was die zentrale Autorisierung angeht, stehen seit kurzem eine Reihe von neuen Technologien und Beschreibungssprachen zur Verfügung, die wir im kommenden Abschnitt beleuchten wollen. Da sich in deren Kontext vielfältige neue Akronyme etabliert haben, sollten wir diese zunächst einführen und erklären.

Aus dem seit den 90er bekannten Rollenmodell (RBAC – Role Based Access Control) wurden über die Zeit auch „Attribute-„ und „Context Based“ Varianten entwickelt (ABAC und CBAC), wie sie sehr anschaulich im „Conditional Access“ in Microsofts Azure Cloud (und an vielen anderen Stellen) zum Einsatz kommen. Hierbei ist nicht nur die Rolle der zugreifenden Entität wichtig (etwa Anwender oder Admin in der Applikation oder Einkäufer bzw. Controller auf Ebene der Job-Bezeichnung, bzw. als Business Rolle), sondern auch deren Eigenschaften („ist Mitarbeiter“, „hat Freigabelevel SENIOR“, „ist Mitglied der Gruppe ADMINISTRATOREN“) bzw. der aktive Kontext („ist angemeldet am AD“, „benutzt ein Firmengerät“, „befindet sich im Firmen-Netzwerk“). Neuere Varianten wie ReBAC (Relationship Based…) und PBAC (Policy Based…) runden das Bild ab, spezifizieren im Grunde jedoch nur die Art, wie Zugriffsrechte modelliert bzw. vergeben werden (mehr dazu weiter unten).

Um diesen Kontext und die Eigenschaften jedoch dynamisch in Zugriffsentscheidungen einbeziehen zu können, benötigen wir eine angepasste Architektur der Applikationen als auch der Infrastruktur. Diese lassen sich am besten herleiten, wenn die Komponenten nach einer bekannten Nomenklatur benannt und deren Eigenschaften beschrieben werden. Landläufig haben sich hierfür die folgenden Begriffe etabliert:

• PEP – Policy Enforcement Point: Die Komponente, welche eine Zugriffsentscheidung schlussendlich umsetzt. In der Regel ist dies eine Anwendung.
• PDP – Policy Decision Point: Fällt anhand von Regeln und Kontext-Informationen Zugriffsentscheidungen für den Enforcement Point
• PAP – Policy Administration Point: Zentrale Management-Komponente zur Verwaltung von Policies, Monitoring und Protokollierung von Entscheidungen des PDPs
• PIP – Policy Information Point: Stellt bei Bedarf einem PDP zusätzliche (Meta-) Informationen über Benutzer und Ressourcen zur Verfügung

Bild 2: Policy Enforcement Komponenten (CREATIVE COMMONS Lizenz, Wikipedia)

In einer klassischen monolithischen Applikation sind alle Komponenten innerhalb der Applikation abgebildet, so dass sowohl ein lokales Benutzerkonto, lokales Passwort als auch lokal zugewiesene Berechtigungen in der Applikation verortet sind. Die Nachteile dieses Ansatzes liegen auf der Hand: Benutzerkonten (und Kennwörter) werden redundant in applikationseigenen „Silos“ verwaltet, die Steuerung und Durchsetzung von Berechtigungen erfolgt ebenfalls innerhalb des Silos der Applikation und nicht geschäftsprozessübergreifend.

Die erste Stufe zu einer modernen Anwendungsarchitektur stellt das „Outsourcing“ der Benutzerverwaltung (nebst Identifizierung und Authentisierung) und die Einführung von Single-Sign-On dar: Die hierzu erforderlichen Anpassungen am Anwendungs-Code und der Berechtigungslogik lassen sich in zwei Teilaspekte unterteilen:

1) Der gesamte Login-Prozess der Anwendung wird per SSO ausgelagert und an einen externen Identity-Provider übertragen, welcher alle notwendigen Informationen über den gerade aktiven Benutzer zur Laufzeit bereitstellt. Der Anpassungsaufwand hierfür ist in den meisten Fällen überschaubar und lässt sich häufig durch externe Module im Webserver oder einem vorgelagerten Reverse-Proxy verhältnismäßig einfach umsetzen.

In einem idealen Szenario muss sich die Anwendung anschließend nicht mehr um die Benutzerverwaltung kümmern – die Speicherung von Benutzern, nebst Kennwörtern und Nutzerdaten (Name, Vorname, und andere Eigenschaften) entfällt und wird zentral von einem externen Identity-Provider übernommen.

2) Das Berechtigungsmodell der Anwendung kann derart angepasst werden, dass wesentliche Zugriffsentscheidungen anhand benutzerbezogener Eigenschaften ausgemacht und getroffen werden können, wie beispielsweise „Ist Mitglied der Gruppe X“ oder „hat ADMINISTRATOR-Kennzeichen gesetzt“. Da diese Benutzerattribute per SSO durch den zentralen IdP gleich mitgeliefert werden, ergibt sich indirekt eine gewisse Auslagerung der Zugriffssteuerung: Die Anwendung verwaltet nicht mehr selbst, wer „Administrator“ oder „Mitglied der Gruppe X“ ist, sondern wendet ihre Zugriffsregeln entsprechend der jeweiligen Benutzereigenschaften zur Laufzeit an.

Die Vorteile des zweiten Aspekts werden schnell offensichtlich: Berechtigungsrelevante Benutzereigenschaften die für die Berechtigungssteuerung relevant sind (wie Gruppenmitgliedschaften oder Kennzeichen), können an zentraler Stelle und für alle Benutzer einheitlich verwaltet und per SSO über den Identity-Provider der jeweiligen Anwendung zur Laufzeit bereitgestellt werden.

Wie weiter oben bereits angedeutet ist eine wirklich feingranulare Zugriffssteuerung hier jedoch nicht möglich, weil sie durch die Fähigkeiten von SAML bzw. OpenID Connect (OIDC) begrenzt sind:

• Per SSO können schwerlich alle für die Zugriffssteuerung relevanten Benutzerdaten just-in-time an die Anwendung übermittelt werden. In realen Umgebungen ist es nicht unüblich, dass ein Benutzer in dutzenden Gruppen Mitglied ist. Der zulässige Speicherplatz für SAML/OIDC-Tokens wird jedoch durch das HTTP-Protokoll begrenzt und sollte in der Praxis eine Größe von 7 kB nicht übersteigen.
• SSO bildet nur eine Seite der Medaille ab: Identitätsdaten. Die Entscheidung darüber, welche Aktionen ein Benutzer konkret an welchen Objekten ausführen darf und warum, obliegt bei diesem Ansatz weiterhin vollständig der Anwendung. Mit Single Sign-On wird also nur ein Teilaspekt ausgelagert – nämlich die Authentisierung des Benutzers. Wird die Autorisierung weiterhin innerhalb der Anwendung umgesetzt, geschieht dies häufig mit Programmlogik wie sie exemplarisch und vereinfacht in Listing 1 abgebildet ist:

Listing 1

Obwohl Softwareentwickler in realen Projekten im Regelfall deutlich flexibleren (und komplexeren) Code verwenden um Zugriffsentscheidungen zu implementieren, verbleibt die eigentlich relevante Logik im Programmcode verborgen und ist schlussendlich weiterhin (mehr oder weniger) schwer zu warten und häufig intransparent.

Wenn man den aufgezeigten Trend zur Auslagerung und Zentralisierung fortführt, sollte nur noch die reine Business-Logik in der Applikation selbst erstellt werden, und eine dedizierte (und technologisch standardisierte) lokale Komponente für die Autorisierungs-Entscheidung diese Logik ergänzen um die Zugriffsentscheidungen auf Basis zentral definierter und verwalteter Policies zu treffen.

Bild 3: Evolutionsstufen der Auslagerung von Anwendungskomponenten

In einem Gesamtschaubild könnte eine mögliche Architektur dann wie folgt aussehen:

Bild 4: Komplett reduzierter Ansatz für die Auslagerung der Autorisierung