Immer häufiger kommen Kunden mit federierten SAML 2.0 Ansätzen auf uns zu und fragen, warum man neben SAML 2.0 und einer Infrastruktur für das reine Access Control eben doch noch eine Identity-Management-Lösung für die zentrale Rechtevergabe benötigt? Vielfach besteht die Meinung, man könne ja alle notwendigen Rollen-Informationen auch einfach über ein Attribut im SAML-Ticket mitsenden. Diese sogenannte «Just In Time Provisionierung» von Identitäten und deren Rechte birgt jedoch eine Reihe an Hürden, welche sich mittels eines zentralen Identity-Managers lösen lassen.
Aber nun mal der Reihe nach.
Was ist SAML 2.0 ?
SAML 2.0 deckt das ab, was in einem modernen IT-Umfeld unbedingt benötigt wird: Es schafft die Möglichkeit Authentisierungen über Identity-Domains hinweg zu bewerkstelligen und den Zugriff auf Services auf Basis eines Identity-Providers zuzulassen, welcher nicht unbedingt in meinem Einflussbereich steht.
Kurzum: Ein ideales Konstrukt, das Vertrauen zu anderen Organisationen virtuell abzubilden, Partner-Zugriffe auf Services zu realisieren und dennoch die Identitäts-Hoheit bei der jeweiligen Organisation zu belassen.
Gerade im Behördenbereich ist SAML 2.0 sehr beliebt, da so die Benutzer sich mit ihren «lokalen» Credential am IDP ihrer Organisation anmelden können um so recht einfach ein Single Sign-on sogar auf «organisationsfremde» Anwendungen sichergestellt werden kann (vgl. Referenzarchitektur IAM von eCH, ggf. weitere Blog-Beiträge zu dem Thema).
Ganz ursprünglich wurde SAML 2.0 für den Use Case entwickelt, wo ich mich an einer Web-Anwendung angemeldet habe und mich an einer anderen Web-Anwendung mit derselben Authentisierung ebenfalls anmelden möchte.
Nun ja, wie es mit solchen Protokollen so ist, verbreitet sich der Kreis an möglichen Use Cases und was wir heute antreffen ist häufig die Situation, wo man mit SAML 2.0 die Authentisierung an einer Vielzahl unterschiedlichster Anwendungen über mehrere Identitäts-Domänen hinweg. Um sogenannte Cross Domain Zugriffe zu ermöglichen, wird zentral mittels einem Identity-Providers oder mittels eines Konstrukts auf Basis von SAML 2.0 eine Federation mit unterschiedlichen IDPs und einem zentralen Federation Providers (FP) konstruiert. Der Federation Provider stellt die Authentisierung auf Basis der IDPs einer Organisation (Identitäts Domäne) mittels der Credentials eines Users innerhalb dieser Organisation sicher.
SAML 2.0 lässt sich zum Bau eines Federation-Konstrukts sehr gut ineinander verschachteln: Dabei wird ein SAML 2.0 Identity Provider zu einem Service Provider eines «übergeordneten» Identity Providers.
Die Herausforderung der Rechte-Vergabe
In einer solchen Situation stellt sich jedoch nicht nur das Problem der Authentisierung, sondern auch die der Autorisierung, also der Rechtevergabe bei den einzelnen Service Providern.
Für die Rechteverteilung bestehen grundsätzlich zwei Integrationsmuster:
1) IDP einer Organisation verwaltet die Rechte
In diesem Fall werden die Rechte beim IDP einer Organisation durch die Organisation selbst verwaltet. Um die Rechte dem Service Provider mitzuteilen werden die Rechte oder auch Rollen-Informationen als Attribut in einem SAML-Ticket mitgesendet. Daraus ergibt sich die sogenannte «Just in Time Provisionierung». «Just in Time», weil dem Service Provider die Rechte nur zum Zeitpunkt der Autorisierung des Users mittels eines gültigen SAML-Tickets bekannt ist. In SAML 2.0 ist grundsätzlich keine Abfrage von Identitätsdaten am Identity-Provider vorgesehen.
2) Der Federation Provider verwaltet die Rechte und Rollen
Bei dieser Variante gibt es beim Federation Provider einen zentralen Identity Manager welcher die Rechteverwaltung zentral sicherstellt. Hierfür wird ein zentrales Directory mit allen Identitäten und deren Rechte bereitgestellt.
Bei der Umsetzung von Federation-Konstrukten zeigt sich in der Praxis nun immer mehr, dass sich Möglichkeit 2) bewährt und immer häufiger zur Anwendung kommt. Es gibt gute Gründe, warum sich «Just In Time Provisionierung» (Möglichkeit 1) in einem Federation Konstrukt bisher wenig durchsetzt. Und zwar liegen diese Gründe bei den Service Providern sprich den Anwendungen und der Entwicklung dieser Anwendungen.
Die Welt aus Sicht der Anwendungen
Jede Applikation bringt ihr eigenes Universum an Rollen, Rechte und Access-Control-Mechanismen mit. Diese zu harmonisieren ist ein Ding der Unmöglichkeit. Es ist denkbar, mittels SAML 2.0 Tickets, Rechte und Rollen-Informationen dem einzelnen Service zu übermitteln. Doch: Wer gibt das Naming dieser Rechte und Rollen vor? Der IDP oder der Service Provider sprich die Applikation? Sobald wir uns in einem federierten Konstrukt mit mehreren Identity Providers bewegen, wird es ein erheblicher betrieblicher Aufwand sämtliche Rollen und Rechte zentral auf einem IDP vorzugeben resp. ein Mapping zwischen all den Applikations-Rollen- und Rechten zu machen und akkurat zu halten.
Fähigkeit von Anwendungen SAML 2.0 umzusetzen
Eine weitere Herausforderung stellt die direkte Integration von SAML 2.0 in die Anwendungen dar. Nicht jede Anwendung und die dahinterstehende Entwicklungsfirma, bietet von Haus auf SAML 2.0 in ihrer Anwendung an. Nach Jahren von LDAPS-Integrationen und Kerberos-/AD-Integrationen, herrscht im Entwicklungsmarkt eine gewisse Skepsis gegenüber SAML 2.0 oder auch anderen Authentisierungsprotokollen wie OpenID. In der IT-Branche hat man sich ganz generell zwischenzeitlich gut daran gewöhnt, mittels einer LDAP-Abfrage an einem zentralen Directory Rechte und Rollen zu ermitteln. Im Falle eines komplexeren Federation-Konstrukts, wird seitens Anwendungsentwickler oft erwartet, dies auch weiterhin an einem zentralen Dienst tun zu können. Ob es LDAP sein muss sei einmal dahingestellt, RESTAPIs scheinen ein weiterer de-fakto-Standard in der Anwendungsentwicklung geworden zu sein.
Zu guter Letzt: Die gute alte Access Governance
Einer der wichtigsten Aspekte der in der Diskussion um die «Just In Time Provisionierung» mittels SAML 2.0 oft vergessen geht, ist die gute alte Access Governance.
Im Falle von «Just in Time Provisionierung» in einem federierten Umfeld, kann durch keine Instanz, zweifelsfrei festgestellt werden, ob die Rechtmässigkeit der Rechtezuweisung effektiv gegeben ist oder nicht. Will heissen: Falls ein User bei einer Organisation mit einem IDP Rechte erhalten hat, die er nicht besitzen dürfte und bei dieser Organisation fehlt die Nachvollziehbarkeit der Rechtevergabe, so kann unter Umständen nicht zweifelsfrei nachgewiesen werden, wer/wann/warum/durch wen ein User die Rechte erhalten hat.
Die sogenannte Access Governance ist in einem federierten Konstrukt mit Sicherheit nur dann gewährleistet, wenn die Access Governance aller Identity-Providers effektiv funktioniert (was notabene in der Praxis selten der Fall ist) oder aber ein zentrales Identity Management System zur Rechtevergabe mit Access Governance bereitsteht.
Der SES unterstützt beide Integrationsmuster
Mit der Erweiterung des USP SES IDENTITY Moduls, unterstütz der SES die Umsetzung beider Integrationsmuster aus einer Hand. Mittels SES IDENTITY besteht die Möglichkeit den IDP um die Rechte- und Rollenverwaltung zu erweitern und die in SES IDENTITY gepflegten Identitäten mit ihren Rechten z.B. in ein zentrales Benutzerverzeichnis zu synchronisieren. Von dort aus können die Applikationen mittels LDAPS Abfragen zu Rechte- und Rolleninformationen machen. Dadurch bietet sich der Vorteil, dass zentral die Access Governance von gemeinsam genutzten Services sichergestellt werden kann. Durch die Mandantenfähigkeit von SES IDENTITY besteht die Möglichkeit, den unterschiedlichen Partnern die Identitäts- und/oder die Rechteverwaltung zu delegieren. Neben der «Just In Time Provisionierung», welche der SES bereits mit den bestehenden Komponenten unterstützt, steht so ein weiteres, enorm mächtiges Integrationsmuster zur Verfügung.
Gerne unterstützten wir Sie bei der Wahl der nachhaltigen Architektur für Ihr Vorhaben. Zögern Sie nicht uns zu kontaktieren.