Feiner Sand – warum viele CIAM-Installationen feinere Autorisierung benötigen

In den letzten Jahren haben viele Unternehmen sowohl ihre internen Access Management Systeme (AM) für Mitarbeiter und deren Zugriff aus Web-Applikationen und SaaS Dienste sowie ihre Customer Identity & Access Management (CIAM) zur Sicherung der Kundenzugriffe auf angebotene eServices und Dienstleistungen erfolgreich modernisiert. Dabei wurde die mühsame mehrfache Eingabe von Credentials wie Benutzernamen/E-Mails und Passwörtern durch Standards für Föderation und Single Sign-On (wie SAML und OpenID/OAuth) ersetzt.

Das hat bereits erhebliche Vorteile bei der Bereitstellung neuer eServices sowie der Absicherung der Cloud-Nutzung gebracht und vor allem die Benutzererfahrung für die Anwender erheblich verbessert. Die Zentralisierung der Identifikation der Anwender sowie ihrer Authentisierung ist unbestritten durch Single Sign-On (SSO) ein Meilenstein in der Nutzung solcher Infrastrukturen, aus der sich eine Reihe von Vorteilen ergeben, wie insbesondere:

• Die offene Übertragung unverschlüsselter Passwörter wird verhindert
• Anwender müssen nicht mehr für jede Anwendung neue Zugangsdaten hinterlegen
• Die User-Experience bei der Registrierung, dem Login und Kennwort-Reset wird vereinheitlicht – durch Wiedererkennungswerte und einheitliche Prozesse wird zusätzliches Vertrauen und Sicherheit geschaffen
• Angriffe auf Benutzerkonten können an zentraler Stelle am Identity-Provider erkannt und unterbunden werden.
• Durch Nutzung fertiger SaaS – CIAM Lösungen sinken die Gesamtkosten (TCO) im Vergleich zu alternativen Lösungen, die n-fach selbst entwickelt und betrieben werden müssen.

An einer Stelle kommen jedoch langsam, aber sicher die Grenzen dieser Technologien an die Oberfläche. Während sie die einfache JA/NEIN Entscheidung für den Zugriff auf Ressourcen oder Dienste wie Kundenportale, Shops oder Kollaborationsplattformen ermöglichen, bleibt eine feingranulare Unterscheidung, was der Anwender dann tun kann, häufig ungeklärt und muss im Rahmen der jeweiligen Applikation oder des Services verwaltet werden.

Im Kontext von Business-to-Business Föderationen (meist auf SAML basierend) kann und wird zwar über Gruppenzugehörigkeit und entsprechende Vermerke im Token eine weitergehende Unterscheidung ermöglicht, dies ist jedoch meist auf einige wenige Optionen begrenzt, da es ansonsten zu einer Potenzierung der Gruppen-Zugehörigkeiten auf Seiten der Kundeninfrastrukturen kommt.

Lassen sie uns jedoch zunächst noch einmal kurz die Vorteile des Einsatzes einer CIAM- Lösung, wie sie beispielsweise cidaas bietet, werfen.

Richtig geplant und umgesetzt, bietet ein CIAM weitaus mehr als reines „Access Management”, da es Funktionen für:

• das Enrollment neuer (End-)Anwender, manuell oder über Social Identity Provider
• die Validierung von Anwenderidentitäten, etwa über den „ID validator“ von cidaas
• die Identifikation und Authentisierung der Anwender während des Zugriffs, entweder lokal oder per Föderation am Identity Provider
• die Umsetzung einer einfachen JA/NEIN Entscheidung (Autorisierung) für den Zugriff

Aber was passiert dann?

Eine feinere Abgrenzung, was ein Anwender denn nun in dem Zielsystem tun und nicht tun kann, wird entweder überhaupt nicht berücksichtigt (Schlüssel zum Königreich), oder aber die feingranularen Entscheidungen über den Zugriff werden in der Zielapplikation selbst verwaltet. Dies geschieht in der Regel ohne die Möglichkeit, dies zentral zu steuern, da jede Applikation dies individuell von ihren Entwicklern programmiert bekommt. Diese sogenannte „fine grained authorization“ (FGA) bzw. deren abstrakte und zentralisierte Verwaltung wird jedoch bei komplexeren Architekturen immer relevanter und einige Hersteller wie etwa Axiomatics haben bereits vor einem Jahrzehnt mit Standards wie XACML (eXtensible Access Control Markup Language) versucht, eine solche Zentralisierung zu fördern. Obwohl XACML nicht als gänzlich gescheitert gilt, ist eine Adoption weit hinter den hohen Erwartungen zurückgeblieben.

Andere (Open Source) Projekte wie der „Open Policy Agent“ (OPA) mit seiner Beschreibungssprache „REGO“ haben seit ihrem ersten Release im Jahr 2016 erheblich mehr Aufmerksamkeit erhalten, und seit etwa zwei Jahren hat sich eine ganze Reihe von „FGA“ Projekten, Lösungen und vor allem Beschreibungssprachen (etwa CEDAR von AWS) entwickelt, die dem Thema „feingranulare Autorisierung“ dienen.

Höchste Zeit also, sich dem Thema zu widmen und entsprechende Funktionen auch vom führenden europäischen Anbieter für CIAM-Werkzeuge bereitzustellen!

Was erwartet uns in den kommenden Monaten, bzw. welche Themen müssen adressiert werden:

1. Feingranularer Zugriff hängt im Bestand immer von der Applikation ab und ist kaum vereinheitlicht
2. Der Bedarf besteht nicht nur beim Anwender, sondern auch bei den Auditoren und der Revision – denn jeweils lokale Autorisierungskonzepte nachzuvollziehen und deren Logik und Logmeldungen zu durchschauen, verursacht zusätzlichen Aufwand
3. Eine nachhaltige zentralisierte oder zentralisierbare Lösung ist bislang nicht in Sicht – es geht vornehmlich um die Unterstützung von Anwendungs-Eignern, und Anwendungsentwicklern
4. Zwar stehen neue Werkzeugkomponenten wie der OPA und ähnliches zur Verfügung, dennoch müssen die Entwickler umfassendes Refactoring durchführen, um interne Autorisierungslogik auf neue Sprachen und Konzepte umzustellen
5. Erst mit Umstellung mehrerer Applikationen auf diese einheitliche Logik und Beschreibungssprache, lassen sich auch Policies und deren Verwaltung sowie das Logging und die Auditierung maßgeblich verbessern

Lohnt sich der Aufwand einer feineren Autorisierung überhaupt?

Diese Frage kann nicht generell beantwortet werden, denn es muss bei jeder Applikation, Anwendung und Dienst geprüft werden, um eine Umstellung sinnvoll erscheint. Bei neuen Softwareprojekten, eServices und Diensten sollte jedoch eine sehr wohlwollende Diskussion über die Adoption standardisierter Beschreibungssprachen geführt werden, insbesondere wenn parallel zentrale Infrastrukturen für das Policymanagement, die Policyadministration und die gemeinsame Evaluation vom CIAM-Anbieter bereitgestellt werden können. Dennoch ist zu bedenken, dass bei älteren Applikationen der Aufwand vermutlich schwer zu begründen sein wird, zumal auch auf Seiten des CIAM entsprechende Anpassungen vorgenommen werden müssen. In diesem Fall ist ein Abgleich mit der langfristigen Unternehmensstrategie ratsam, ob die Abwechslung bzw. Migration solcher „legacy“-Anwendungen geplant sind und welche Möglichkeiten sich daraus ergeben.

Klar ist nur, dass sich die Rolle und Bedeutung der CIAM- und AM-Lösungen von einem einfachen „Gatekeeper“ und JA/NEIN Entscheider hin zu einer adaptiven und dynamischen Instanz erweitern wird, die eben auch feingranulare Zugriffsrechte verwalten und deren Umsetzung und Einhaltung gewährleisten kann.

Deutlich wird auch, dass sich auf der Seite der Anwendungen viel tun wird: so wie die Funktionen für „Identifizierung“ & „Authentisierung“ mit SSO aus der Anwendung auf externe Dienste ausgelagert wurden, werden auch feingranulare Zugriffsentscheidungen zukünftig nicht mehr von der Applikation selbst entschieden, sondern an externe Dienste ausgelagert (PDP – Policy Decision Points). Die Anwendung setzt dann nur noch „stupide“ die Entscheidung des PDP um, und gewährt oder verweigert den Zugriff auf eine bestimmte Ressource.

Der Aufwand hierfür lohnt sich sicherlich nicht für jede Anwendung, sondern nur für besonders kritische Dienste mit entsprechender Restlaufzeit. Gerade neue Entwicklungsprojekte können jedoch von der zusätzlichen Modularisierung profitieren – vor allem wenn die Nutzung externer Komponenten für feingranulare Autorisierung von vornherein in der Anwendungsarchitektur mitgedacht und implementiert wird.

Die Vorteile auf Business- & Anwenderseite liegen auf der Hand:

• Zugriffsregeln (Policies) können einfacher und unabhängig von der Programmiersprache der Anwendung formuliert werden – teilweise sogar auch durch Fachanwender
• Einheitliche und zentralisier bare Protokollierung von Zugriffen
• Konsistente, auditierbare Zugriffsprüfung über die Anwendungslandschaft hinweg, aufgrund zentraler, standardisierter Policies
• Entkopplung der Anwendungslogik von der Geschäftslogik hinsichtlich feingranularer Zugriffsprüfungen

Eine zentralisierte „fine grained authorization“ ist in der Realität angekommen, und wir täten gut daran, unsere Dienste und Infrastrukturen entsprechend vorzubereiten und umzustellen.