Fein-granulare Autorisierung – warum der Hype?

Neben Themen wie „Self-Sovereign Identity“ (SSI) und der neuen EU-Verordnung eIDAS 2.0 rund um Wallets, Vertrauensdienste und Interoperabilität beschäftigt die Identity Management Experten kaum ein Konzept mehr, als fein-granulare Autorisierung (FGA).

Das von Google im Jahre 2019 auf der USENIX Konferenz vorgestellte „Zanzibar“ Konzept für ein globales Autorisierungssystem wurde nur von wenigen Spezialisten wahrgenommen, aber dafür umso intensiver betrachtet. Das Vorhaben, neben der Identifikation und Authentisierung von Anwendern (etwa über die Nutzung von Kerberos in den Grenzen der eigenen Active Directory Domäne, oder per SAML 2.0 im Internet) auch die Autorisierung zu zentralisieren, ist keinesfalls neu: bereits in den frühen 2000er Jahren entstand bei der OASIS der XACML Standard, der zuletzt in 2013 mit Version 3.0 aktualisiert wurde. Das Konzept der Entkoppelung fein-granularer Autorisierungsentscheidungen und der Zentralisierung der Verwaltung der Regeln und Policies hierfür ist also bekannt – konnte sich jedoch nie richtig etablieren.

Altlasten und Beweggründe

Zwar waren die Gründe für den ausbleibenden, durchschlagenden Erfolg vielfältig – aber auch heute gilt XACML nicht als „vollkommen gescheitert“. Lediglich die eher komplexe Umsetzung des Standards in reale Produkte und Lösungen und die fehlende Agilität der Software-Entwicklung haben die Adaption erschwert und viele Unternehmen scheuten den Aufwand des notwendigen Refactoring, um ihre Bestands-Software auf das neue Paradigma umzustellen. Ein Grund, warum auch im Jahre 2023 noch Anwendungen mit komplett interner Benutzerverwaltung existieren und Microsoft erheblichen Aufwand betreibt, Altlasten wie das unsichere NTLM endlich aus dem Verkehr zu ziehen und Unternehmen auf die Vorteile moderner Authentisierungs- und Autorisierungsverfahren hinzuweisen. Auch die anstehende oder bereits in Umsetzung befindliche Migration etablierter on-premise Anwendungen in die Cloud bringt Unternehmen von sich aus in Zugzwang, alte Zöpfe abzuschneiden und den Mehrwert in die Jahre gekommener Software zu bewerten. Hierbei ist die Betrachtung der Benutzer- und Rechteverwaltung ein wichtiger Aspekt für die Beurteilung der Migrationsfähigkeit von Altbestand, bzw. zur Bewertung des Aufwandes für ein Refactoring.

Bisherige Entwicklung

Bereits in den frühen 2000er Jahren hatten die erhebliche Verbreitung von Web-Anwendungen sowie der sanfte Niedergang der (teilweise mit Kerberos integrierten) Three-Tier Applikationsarchitektur mit Fat Client GUIs zu einem Wildwuchs an Benutzerkonten und dedizierten Passworten in Web-Apps geführt, dem die Unternehmen mit Web-SSO Systemen entgegenwirken wollten. Die Nutzung von Skript-basierten Methoden zum Scraping der Credentials und deren automatisierten Einfügen in die Webmasken waren jedoch – neben der teilweise unverschlüsselten Übertragung per http – unschöne Begleiterscheinungen, so dass die (aus dem AD mit Kerberos bekannte) Nutzung von Token statt der Eingabe von Credentials bevorzugt wurde. Leider standen viele der Web-Applikationen aber gar nicht im eigenen RZ bzw. in „line of sight“ zum eigenen AD-Controller, so dass besagtes Kerberos keine direkte Option war. Neben dem von Microsoft geförderten WS-* Standard konnte sich in den folgenden Jahren das breit unterstützte SAML (Security Assertion Markup Language) Protokoll für Föderation etablieren, dessen Erfolg durch die Adaption der Version 2.0 in Microsofts eigenem Active Directory Federation Server 2.0 bekräftigt wurde. Seither erfreut sich SAML 2.0 für jegliche Form von Web-Anwendungen stabiler Unterstützung – der Erfolg der mobilen Geräte und der damit einhergehenden Verbreitung von Mobile Apps setzten dem Siegeszug jedoch Grenzen, da sowohl die verwendeten Cookies als auch die recht hohen Ressourcenanforderungen des Protokolls und seiner Sicherheitsmechanismen die Nutzung auf Mobilgeräten erschwerten.

Ja/Nein Entscheidung

Dazu kam, dass man zwar mit SAML eine lokale Anmeldung an der Applikation durch eine Anmeldung am eigenen Identity Provider (IdP) ersetzen kann und somit nur Token ausgetauscht werden, statt dem potenziell unsicheren Übertragen von Nutzername und Passwort über das Internet – eine über das einfache „Ja/Nein“ zum Zugriff hinaus gehende Verwaltung feiner abgestufter Berechtigungen ist jedoch im SAML-Protokoll nicht vorgesehen. Damit eignen sich SAML-basierte Föderationen zwar als Gatekeeper, komplexere Abfragen zum „wer darf hier warum was wo und wie machen“ sind jedoch nicht ohne Umstände abbildbar.

Bild 1: Auslagerung von Benutzerinformationen in einen IdP

Die Problemstellung der Mobil-Apps wurde zeitnah durch die Etablierung neuer Protokolle wie OAuth 2.0 und Open ID Connect (OIDC) angegangen, die auch die Herausforderung der immer wiederkehrenden Registrierung an neuen Services deutlich entschärfen konnten (wer kennt ihn nicht, den berühmten „oder registrieren Sie mich mit Google/Facebook/LinkedIn“ Knopf auf den Websites neuerer Dienste). Ein weiterer Vorteil der neueren Protokolle ist deren flexiblere Nutzung über die verschiedenen Flows (oder „Grants“), die (fehlende) Eigenschaften der beteiligten Parteien berücksichtigen (etwa der „Implicit Flow“, der die Authentifizierung des Clients durch den Authorization Server entfallen lässt, da sogenannte „Public Clients“ keine Möglichkeit zur sicheren Speicherung von Client Zugangsdaten aufweisen).