|
Mein Kollege Craig Burton hat vor einigen Wochen auf einer Konferenz die provokante Aussage „SAML is dead“ gemacht und damit für viel Aufsehen gesorgt. Diese Aussage ist natürlich nur die verkürzte Fassung einer differenzierten Analyse. Im Kern lässt sich festhalten aussagt, dass SAML alleine nicht mehr ausreicht, um die Anforderungen im Bereich Federation zu lösen.
SAML wird wichtig bleiben, aber andere Standards werden immer wichtiger werden. Diese Aussage kam für manche überraschend, weil SAML 2.0 sich eigentlich erst so langsam als der gemeinsame Nenner für Federation etabliert. Hinzu kommt, dass OAuth 2.0 als eines der Protokolle, das als eine der möglichen Alternativen gehandelt wird, in die Diskussion geraten ist.
Immerhin hatte eine der führenden Personen hinter dem neuen Protokoll kurz vor dessen Veröffentlichung erklärt, das Ergebnis nicht mittragen zu können. Allerdings mag das auch seinen Grund darin haben, dass sich OAuth 2.0 an komplexeren Anforderungen von Unternehmen orientiert, nicht mehr nur an wenigen reduzierten Anwendungsfällen.
Was SAML nicht leisten kann
Klar ist: Die Anforderungen an Federation verändern sich. SAML ist primär auf gerichtete, strukturierte Beziehungen zwischen einem Identity Provider (IdP) und einem oder mehreren Service Providern (SPs) oder mehreren SPs und einem IdP ausgerichtet. Es wird in der Praxis häufig nur für bidirektionale Beziehungen genutzt.
Komplexere Herausforderungen zeigen aber Grenzen auf. Man stelle sich ein Szenario vor, in denen mehrere Unternehmen Dokumente über einen SP austauschen möchten und jeweils ihre eigenen Benutzer authentifizieren und damit als IdP agieren. Wenn jedes Unternehmen die Zugriffssteuerung für eigens bereitgestellte Dokumente übernehmen soll, gleichzeitig aber möglichst wenige Informationen zwischen dieser Firma, den anderen IdPs und dem SP synchronisiert werden sollen, kann der SP nicht über die Autorisierung entscheiden.
Anforderungen nehmen stetig zu
Über SAML kann man zwar Informationen zur Autorisierungsentscheidung übermitteln, aber nur indirekt über XACML. Die eigentliche SAML-Spezifikation lässt diesen Punkt offen. Ein anderer Bereich, in dem SAML an seine Grenzen stößt, ist im Zusammenspiel mit dem immer wichtiger werdenden Thema IdMaaS, also Identity Management as a Service.
Wenn man sich in einem Umfeld mit internen und externen Identity Providern und vielen Cloud-Diensten bewegt, ist SAML doch eher unflexibel in seiner Konfiguration und Nutzung. Andere Standards wie eben OAuth und OpenID Connect kommen damit ins Spiel.
Ohne die technischen Aspekte nun in jedem Detail behandeln zu wollen: Unternehmen brauchen einerseits Federation-Mechanismen. Der Druck auch aus dem Business für eine schnellere Zusammenarbeit mit Geschäftspartnern, für einen sicheren und einfachen Zugriff auf Cloud-Dienste, für die Nutzung von IdMaaS und für andere Anforderungen wächst – und er wächst meist schneller als die IT reagieren kann.
Auf der anderen Seite ist nur SAML heute wirklich etabliert, auch wenn immer mehr Federation-Server auch andere Protokolle unterstützen. Das bedeutet für Kunden, dass sie einerseits verstehen müssen, wie sich Federation für sie in Zukunft darstellen wird. Andererseits müssen sie heute beginnen, die Business-Anforderungen umzusetzen. Das erfordert zunächst einmal eine Vision für Access Management und Federation.
Gleichzeitig bedarf es eines Stufenkonzepts, um sich schrittweise über einfache, schnelle Lösungen heute hin zu einer Architektur zu bewegen, die es ermöglicht, dass man mit seinen Geschäftspartnern, Cloud-Diensten etc. sicher und flexibel zusammenarbeiten kann. Nur dann wird man in der Lage sein, die Forderung des Business nach einer „agilen“ Lösung für das „Extended Enterprise“ umzusetzen und auf die Herausforderungen durch Cloud Computing, Mobile Computing und Social Computing zu reagieren.
Created: 31.10.12, modified: 31.10.12
|
