SAML 101 Zusammenfassung Mitarbeiter in Unternehmen nutzen heute eine wachsende Anzahl an Cloud- sowie lokal gehosteten Anwendungen für ihre tägliche Arbeit. Der Zugriff auf diese Applikationen erfolgt über Browser oder nativ von einer Vielzahl an Geräten (z. B. Desktop-PCs, Laptops, Tablets und Smartphones) aus. Zu erwarten, dass sich die Mitarbeiter für jede dieser Anwendungen ein eigenes, robustes Passwort merken, wäre schlichtweg unrealistisch. Eine Lösung bietet hier die Föderation von Identitäten. Sie stellt einen sicheren, privaten Mechanismus Der Identity-Federation-Standard Security Assertion Markup Language (SAML) unterstützt Single-Sign- dern vielfältig eingesetzt werden. Der größte Nachteil von SAML ist, dass es nie für die Unterstützung von SSO in der neuen Generation nativer mobiler Anwendungen optimiert wurde. Ebenso wenig wurde es für Anwendungen konzipiert, die Daten und Services durch API-Aufrufe verschiedener Drittquellen konsolidieren. WS-Trust (für SOAP-Services), OAuth 2.0, ein offener Standard für die Autorisierung, und zu erfüllen und den Nutzern mehr Flexibilität sowie einen größeren Mehrwert zu bieten. Die Föderation von Identitäten und der Ein-Klick-Zugriff auf Webanwendungen bieten einen höheren Komfort und steigern die Benutzerakzeptanz. Mit der Föderation von Identitäten lassen sich auch die Sicherheit erhöhen, Risiken eingrenzen und die Compliance verbessern, da keine Passwörter mehr für den Zugriff auf Webanwendungen erforderlich sind. Schließlich bietet sie auch einen klaren geschäftlichen Nutzen, da sie Barrieren beseitigt, Kosten reduziert und die Produktivität im gesamten Unternehmen erhöht. 1
Inhaltsübersicht Zusammenfassung...1 einleitung...3 Die Sicherheit in einer zunehmend vernetzten Welt....3 Federated identity...4 Standardisierung der Federated identity...5 anwendungsbeispiele für SaML-identity-Federation...6 Große Unternehmen...6 Kleine und mittlere Unternehmen (KMUs)....7 Serviceprovider...7 SaML oder WS-Federation?...8 SaML und weitere identitätsprotokolle...9 Fazit...10 2
einleitung Das Web hat die Art und Weise, wie wir arbeiten und Geschäfte abwickeln, grundlegend verändert. Organisationen können jetzt über das Internet in Echtzeit miteinander kommunizieren. Dies führt zu einer höheren Produktivität und bringt neue Geschäftsmodelle hervor. Gleichzeitig migrieren Unternehmen schneller als je zuvor von herkömmlichen Mainframe- und Client/Server- Anwendungen hin zu Cloud-Applikationen. Auch die Art, wie diese Applikationen gehostet werden und wie der Zugriff darauf erfolgt, ändert sich. Früher wurden geschäftskritische Anwendungen von eigenen internen Teams erstellt, gehostet und gepflegt. Heute müssen Unternehmen einen nahtlosen und sicheren Zugriff von jedem beliebigen Ort auf die unterschiedlichsten Anwendungen ermöglichen egal wo sich diese physikalisch befinden und unabhängig vom Provider und von den BYOD- oder unternehmenseigenen Geräten, die für den Zugriff genutzt werden. Abgesehen von diesen grundlegenden Änderungen bei der Anwendungsarchitektur und den Zugriffsanforderungen geht es weiterhin vor allem darum, die Sicherheit von Anwendungen und Daten zu gewährleisten, die Benutzerakzeptanz sicherzustellen, die Produktivität der User zu erhöhen und die Kosten in Grenzen zu halten. Bei all dem müssen Anwendungen nach wie vor in der Lage sein, Benutzer zuverlässig zu identifizieren und präzise Zugriffs- und Autorisierungsentscheidungen zu treffen. Bei extern gehosteten Anwendungen benötigt jeder Benutzer normalerweise einen eigenen Benutzernamen sowie ein eigenes Passwort. Er muss sich also für jede Anwendung die Anmeldedaten merken und seine Passwörter regelmäßig aus Sicherheitsgründen ändern. Dies beeinträchtigt die Produktivität und erhöht die Sicherheitsrisiken durch Phishing und Hacking, da Benutzer generell Passwörter wählen, die leicht zu merken sind. Werden strenge Passwortregeln im Unternehmen eingeführt, neigen User dazu, sich die Passwörter auf Zetteln zu notieren, was weitere Schwachstellen verursacht. Um dieses Dilemma in den Griff zu bekommen, brauchen Unternehmen eine Methode, die SSO für Webanwendungen unterstützt, ein hohes Sicherheitsniveau garantiert und mit der sich Passwörter ganz abschaffen lassen. Eine ideale Lösung bietet hier die standardbasierte Föderation von Identitäten. In diesem Whitepaper befassen wir uns mit der Föderation von Identitäten und dem vorherrschenden Standard Security Assertion Markup Language, kurz SAML. Gleichzeitig gehen wir der Frage nach, warum Standards wie SAML erforderlich sind, um eine skalierbare und gleichzeitig sichere Federated Identity im gesamten Unternehmen zu implementieren. Darüber hinaus präsentieren wir verschiedene SAML-Anwendungsfälle für große Firmen, kleine und mittlere Unternehmen sowie Organisationen, die als Serviceprovider tätig sind. Schließlich beschäftigen wir uns auch mit Szenarien, in denen SAML mit anderen wichtigen Federation-Protokollen integriert wird, und analysieren die Vor- und Nachteile von WS-Federation und SAML. Die Sicherheit in einer zunehmend vernetzten Welt Dass sich das Internet zur bevorzugten Anwendungsplattform entwickelt hat, liegt nicht zuletzt an den einfachen und intuitiven Weboberflächen. Die Bedienung von Webseiten durch simples Anklicken steigert die Produktivität der Anwender. Da die meisten mit dieser Art von Oberflächen vertraut sind, lassen sich Schulungen und Supportprobleme auf ein Minimum reduzieren. Obwohl native mobile Applikationen auf dem Vormarsch sind, bieten Webanwendungen unbestreitbare Vorteile. So ist es z. B. nicht nötig, Anwendungen speziell für mehrere mobile Betriebssysteme zu entwickeln oder neue Versionen zu verteilen. Hinter diesen benutzerfreundlichen Webanwendungen und -services steht eine Vielzahl an Industriestandards, die eine nahtlose und sichere Interaktion gewährleisten. Die Hyper Text Markup Language (HTML) und das Hyper Text Transfer Protocol (HTTP) sind den meisten Usern noch bekannt. Doch es gibt zusätzlich ein wildes Durcheinander an anderen Protokollen, die eine mühelose Navigation zwischen mehreren Anwendungen von praktisch jedem Browser aus ermöglichen. 3
Webanwendungen können innerhalb einer Organisation oder extern gehostet, als Service bereitgestellt oder als eine Kombination dieser drei Möglichkeiten konfiguriert werden. Die Sicherheit für interne Anwendungen ist relativ leicht zu gewährleisten, sofern sich alle Benutzer und Anwendungen in derselben Sicherheitsdomäne befinden und ein zentrales Identitätsmanagementsystem die Benutzer identifiziert und authentifiziert. Dies ist nicht mehr so einfach, wenn Anwendungen außerhalb der Firewall oder einer anderen Sicherheitsdomäne ausgelagert werden (dazu gehört die Migration zu Software-as-a-Service (SaaS)- und Business-Process-Outsourcing(BPO)-Anbietern). Da diese Anwendungen keinen Zugriff auf das Identitätsmanagementsystem der Organisation haben, benötigen sie jeweils ihre eigene Benutzerdatenbank für Zugriffs- und Autorisierungszwecke. Bei jeder neuen Browsersitzung müssen sich die User mit einem eindeutigen Benutzernamen und Passwort für jede Anwendung anmelden. Das klingt zunächst nicht schlimm. Bedenkt man allerdings, wie viele Log-ins erforderlich sind, wenn Hunderte oder Tausende Mitarbeiter sich jeden Tag für verschiedene Webanwendungen anmelden, sieht die Sache anders aus. Geschäftskunden und Verbraucher sind schnell frustriert, wenn sie sich wiederholt anmelden müssen, insbesondere wenn es dabei um eine Vielzahl an Produkten oder zusammengehörigen Services geht. Angestellte haben oft Listen mit Passwörtern, die einfach verloren gehen bzw. vergessen oder gestohlen werden können. Wiederholte Log-ins wirken sich negativ auf die Mitarbeiterproduktivität aus und beeinträchtigen die Akzeptanz von Anwendungen. Sich all diese verschiedenen Benutzernamen und Passwörter zu merken, ist schwierig und aufwendig. Daher kommt es nicht selten vor, dass User für alle Anwendungen denselben Benutzernamen sowie dasselbe einfach zu merkende Passwort wählen. Erraten oder finden unbefugte Nutzer die Kombination aus Benutzernamen und Passwort heraus, können sie gegebenenfalls auf alle Anwendungen zugreifen. Hinzu kommt, dass viele ehemalige Mitarbeiter oder Partner die Zugriffsrechte für Anwendungen behalten, wenn sie das Unternehmen verlassen. Die beste Lösung wäre, alle Passwörter für Anwendungen abzuschaffen und durch sicheres, skalierbares und kostengünstiges SSO für sämtliche Webapplikationen zu ersetzen. Federated Identity wurde entwickelt, um eben diese Probleme zu lösen. Federated identity Federated Identity bietet eine sichere, einheitliche und internetfreundliche Möglichkeit, um ein und dieselbe Identität für eine Vielzahl von Organisationen und Anwendungen zu nutzen. Der User meldet sich dabei einmalig mittels eines Standard-Netzwerk-Log-in oder eines gehosteten Authentifizierungsservices an. Klickt er auf einen Webanwendungslink, wird seine Identität transparent und sicher für die Anwendung genutzt, sodass keine Anmeldung mehr erforderlich ist. Da die Organisation die Benutzer authentifiziert und der Anwendungsprovider die Authentizität der Federated Identity verifizieren kann, sind keine Passwörter erforderlich und die Benutzer profitieren von einem Click-and-work -Zugriff auf Anwendungen. Die Föderation von Identitäten bietet sowohl den Benutzern als auch der IT-Abteilung und dem Unternehmen enorme Vorteile. Benutzer schätzen die Föderation, weil sie dank Internet-SSO Webanwendungen genauso einfach nutzen können wie interne Applikationen, ohne sich unzählige Passwörter merken (und zurücksetzen) zu müssen. Die IT profitiert von der Föderation, weil sie damit die Sicherheit erhöhen und den Supportaufwand insbesondere für den Helpdesk verringern kann. Unternehmen schließlich können durch die Föderation von Identitäten Anwendungen und Daten wesentlich schneller mit Kunden, Geschäftspartnern, Lieferanten und Tochtergesellschaften teilen, Risiken minimieren und die Einhaltung gesetzlicher Vorgaben sicherstellen. 4
Standardisierung der Federated identity Föderation bedeutet sinngemäß, kleinere, definierte Einheiten innerhalb einer Gruppe zusammenzufassen. Auf eine Technologie angewendet, bedeutet dies, dass alle Beteiligten einer identischen Vorgehensweise und denselben Regeln zustimmen, um eine durchgehende Interoperabilität zu ermöglichen. Federated Identity wäre ohne Standards nicht denkbar. Jede Organisation, die sich für die gemeinsame Nutzung von Anwendungen entscheidet, müsste ein aufwendiges Design- und Entwicklungsprojekt ins Leben rufen und dabei die Punkt-zu-Punkt-Schnittstellen zwischen den speziellen Systemen der einzelnen Parteien abstimmen. Jede Verbindung müsste dabei umfassend getestet werden, da sonst Sicherheitsrisiken und Ausfälle drohen würden. Man stelle sich nur vor, man müsste für jeden neuen Geschäftspartner oder Lieferanten diesen ungeheuren Aufwand betreiben. Ohne Standards wäre der großflächige Einsatz föderierter Identitäten aufgrund der enormen Kosten und Sicherheitsrisiken sowie der längeren Time-to-Market praktisch unmöglich. Der Bedarf an einer Federated-Identity-Lösung wurde Anfang der 2000er-Jahre erkannt. Mehrere Gruppen begannen damals, an den erforderlichen Standards zu arbeiten. Allerdings sind viele Standards nicht unbedingt besser als gar keine Standards vor allem dann, wenn jede Organisation sich für einen anderen Standard entscheidet. Nach einer turbulenten Konsolidierungsphase blieben bis zum Jahr 2005 zwei Identity-Federation-Standards für Unternehmen übrig: Security Assertion Markup Language (SAML) und WS-Federation (für Verbraucher war OpenID 2.0 das standardmäßige SSO-Protokoll; derzeit wird es von den robusteren und sichereren Protokollen OAuth und OpenID Connect ersetzt). SAML hat sich inzwischen als der vorherrschende Standard etabliert, wobei man WS-Federation weiterhin in Microsoft-orientierten Organisationen findet, die Active Directory Federation Services (ADFS) nutzen (Hinweis: die neueste ADFS-Version unterstützt sowohl SAML als auch WS-Federation). Die Tatsache, dass es zwei Protokolle gibt, zeigt eindeutig: Identity-Federation-Produkte und -Services müssen mehrere Protokolle unterstützen, um alle möglichen Anwendungsfälle und Verbindungsarten abzudecken. SAML erlaubt den sicheren Austausch von Authentifizierungs- und Autorisierungsinformationen zwischen Sicherheitsdomänen (z. B. separate Organisationen) oder sogar Unternehmensabteilungen. SAML funktioniert auf der Grundlage von Assertions bzw. Aussagen seitens des Identitätsanbieters (IdP). Dieser ist zuständig für die Pflege und die Authentifizierung der Benutzeridentität mithilfe unterschiedlicher Methoden (in der Regel durch ein Identitätsmanagementsystem), einschließlich Benutzername/Passwort oder sogar durch starke Authentifizierungsmethoden wie biometrische Verfahren. Wenn ein Benutzer versucht, über einen Serviceprovider (SP) auf eine Anwendung zuzugreifen, erstellt die Federation-Software eine SAML-Authentifizierungsanfrage und sendet diese an den entsprechenden IdP des Benutzers. Sobald die IdP-Federation-Software die Authentifizierungsanfrage empfangen und validiert hat, authentifiziert der IdP den Benutzer und erstellt eine SAML- Aussage mit der Identität und den Attributen dieses Benutzers. Die Aussage wird digital signiert und verschlüsselt, um die Authentizität sicherzustellen. Optional kann sie auch andere Daten enthalten, die von der Zielanwendung benötigt werden. Die Aussage wird anschließend sicher an den SP zurückgesendet. Die Identity-Federation-Software beim SP empfängt die Aussage, verifiziert deren Authentizität, entschlüsselt den Inhalt und teilt daraufhin die in der Aussage enthaltenen Informationen (einschließlich der Identität des Benutzers) mit der Anwendung. Die Anwendung nutzt die Daten anschließend, um den Benutzer anzumelden. So wird SSO ermöglicht. Der Benutzer bekommt von diesen magischen Federated-Identity-Vorgängen nichts mit er klickt einfach nur auf den Anwendungslink und kann sofort loslegen. 5
Abbildung 1: Die Federated-Identity-Software übersetzt die lokale Identität des Benutzers in eine SAML- Aussage und ermöglicht so Internet-Single-Sign-on. SAML wird neben 70 weiteren Webstandards von OASIS (Organization for the Advancement of Structured Information Standards) gepflegt und weiterentwickelt. OASIS ist allerdings nicht die einzige Organisation, die am SAML-Standard mitgewirkt hat. Das aktuelle SAML 2.0 ist auf die Konvergenz dreier separater Standards zurückzuführen, die SAML gemeinsam zur unangefochtenen Nummer eins machen. Die SAML-Version 1.0 wurde 2002 eingeführt und ein Jahr später folgte die Version 1.1. 2005 schließlich flossen die zwei SAML 1.1-Varianten Liberty Alliance Identity Federation Framework (ID- FF) und Shibboleth zu SAML 2.0 zusammen, der neuesten und finalen Version. Die Liberty Alliance, die inzwischen in der Kantara Initiative aufgegangen ist, spielt weiterhin eine entscheidende Rolle bei der Bereitstellung von unabhängigen SAML-Interoperabilitätstests und -Zertifizierungen. Obwohl sich SAML zum Identity-Federation-Protokoll der Wahl für Business-to-Business-Interaktionen entwickelt hat, gibt es weitere Protokolle, die neben SAML für unbestimmte Zeit weiter existieren werden. Eines davon ist OpenID 2.0. Es spielt für Verbraucher eine wichtige Rolle, da es bestimmte Anforderungen rund um das benutzerorientierte Social Networking erfüllt ein Anwendungsfall, für den SAML nie konzipiert wurde. OAuth 2.0, ein weiterer Standard, stammt ursprünglich zwar aus dem Verbraucherbereich, gewinnt aber sowohl für Unternehmen als auch für die Cloud zunehmend an Bedeutung. OAuth 2.0 bietet jetzt die Grundlage für zusätzliche Funktionen in OpenID Connect, einem Standard, das OAuth um weitere Identitätsfeatures ergänzt. OpenID Connect wird eine wichtige Rolle als zentraler Standard für (native) Anwendungen auf Mobilgeräten und Tablets sowie für Machine-to-Machine-Interaktionen spielen. Zwischen solchen Standards und SAML wird eine gewisse Interoperabilität erforderlich sein eine Aufgabe, für die bereits die Multiprotokoll-Identity-Federation-Software vorgesehen ist. anwendungsbeispiele für SaML-identity-Federation In diesem Kapitel zeigen wir, wie unterschiedliche Arten von Organisationen SAML einsetzen, um einen nahtlosen und sicheren Zugriff auf Webanwendungen mittels Federated Identity zu ermöglichen. Große Unternehmen Die meisten großen Unternehmen verwenden bereits ein Identitätsmanagementsystem, um Benutzer zu authentifizieren und ihre internen Anwendungen zu schützen. Daher geht es bei der SAML-Identity-Federation in großen Unternehmen generell um die gemeinsame Nutzung von Identitäten durch ein bestehendes Identitätsmanagementsystem und Webanwendungen. Typische Anwendungsfälle in großen Unternehmen sind: 6
Internet-SSO (ausgehend) für webbasierte Cloud-, Business-Processing-Outsourcing-, Partner-, Anbieter- oder Lieferantenanwendungen Internet-SSO (eingehend), um einen sicheren Zugriff auf interne Webanwendungen für Kunden, Geschäftspartner und Zweigniederlassungen/Tochterunternehmen zu gewährleisten Internes Web-SSO, um einen zentralisierten Zugriff für die Organisation sowie Tochtergesellschaften, akquirierte Unternehmen oder Joint Ventures sicherzustellen, in denen es separate Sicherheitsdomänen, mehrere Federation-Standards oder getrennte Identitätsmanagementsysteme gibt Webservices (SOAP und RESTful) für die gemeinsame, sichere Nutzung von Identitäten mittels WS-Security und OAuth SAML bietet für diese Anwendungsfälle folgende Vorteile: Benutzerpasswörter gelangen nie über die Firewall hinaus, da die Benutzerauthentifizierung innerhalb der Firewallgrenzen stattfindet und für Webanwendungen nicht mehr verschiedene Passwörter erforderlich sind Es ist praktisch unmöglich, Webanwendungen ohne Passwörter zu hacken, da sich der Benutzer erst bei einem Enterprise-Class-Identitätsmanagementsystem authentifizieren muss, das unter anderem auch starke Authentifizierungsmechanismen umfassen kann Ein SP-initiiertes SAML-SSO ermöglicht Benutzern außerhalb der Firewallgrenzen den Zugriff auf Webanwendungen. Möchte ein externer Benutzer auf eine Webanwendung zugreifen, kann der SP den Benutzer automatisch an ein Authentifizierungsportal beim Identitätsanbieter weiterleiten. Nach der Authentifizierung erhält der Benutzer Zugriff auf die Anwendung. Benutzername und Passwort verbleiben dabei sicher innerhalb der Firewallgrenzen Die zentralisierte Föderation garantiert einen einzigen Punkt für den Zugriff auf Webanwendungen sowie für die Kontrolle und Überwachung derselben. Dies bietet eindeutige Vorteile in puncto Sicherheit, Risiko und Compliance Eine entsprechend aufgebaute Identity-Federation-Schicht, die alle oben beschriebenen Anwendungsfälle abdeckt, unterstützt verschiedene Protokolle und kann eine unternehmensweite Internet-SSO-Lösung mit einer soliden Architektur bieten. Kleine und mittlere Unternehmen (KMUs) Viele Vorteile, von denen große Firmen beim Thema Internet-SSO profitieren, treffen auch auf kleine und mittlere Unternehmen zu. KMUs haben allerdings mit zusätzlichen Herausforderungen in puncto Infrastruktur zu kämpfen. Viele KMUs haben (und wollen) kein internes Identitätsmanagementsystem. Stattdessen verlassen sie sich auf einen gehosteten Authentifizierungsservice wie Google Apps. In solchen Fällen kann ein On-Demand-Identity-Federation-Service genutzt werden, der die gehostete Identität verwendet, um Internet-SSO für On-Demand-Unternehmensanwendungen zu ermöglichen. Die meisten KMUs, die über einen Verzeichnisdienst verfügen, nutzen Microsoft Active Directory, das ohne zusätzliche Kosten in vielen Microsoft Windows Server-Produkten inbegriffen ist und nahtlos mit Microsoft Windows-PCs und deren Peripheriegeräten funktioniert. In diesem Fall kann ein Identity-Federation-Server oder On-Demand-Service Internet-SSO-Funktionen bereitstellen, die denen großer Unternehmen ähneln. Serviceprovider Viele Serviceprovider haben erkannt, dass Federated Identity ein Business-Enabler ist sei es als Mehrwertdienst oder als Antwort auf die Nachfrage nach Internet-SSO. 7
anwendungsfälle für Serviceprovider sind u. a.: Eingehende Verbindungen von Kunden, die als Identitätsanbieter agieren und ihren Nutzern, die auf Anwendungen des SPs zugreifen, Internet-SSO ermöglichen wollen Eingehende Internet-SSO-Verbindungen von gehosteten Authentikatoren wie Google Apps Ausgehende Verbindungen zu anderen SPs, wobei eine sichere, gemeinsame Verwendung der Identitäten nötig ist, um Mehrwertdienste von Drittanbietern ohne zusätzliche Anmeldungen zu nutzen Die Vorteile der SaML-basierten Federated identity für Serviceprovider umfassen: Sicheres, skalierbares und standardbasiertes Internet-SSO für Kunden, sei es als als Mehrwertdienst, Differenzierungsmerkmal, oder um die Kundenanforderungen zu erfüllen Geringerer Verwaltungsaufwand, da das Passwortmanagement im System des Serviceproviders wegfällt (der Kunde ist für das Passwortmanagement verantwortlich), sowie niedrigere Helpdesk-Kosten Zusammenschluss mit anderen Serviceprovidern und gemeinsame Nutzung der Benutzeridentitäten, um nahtlose und transparente Mehrwertdienste ohne zusätzliche Anmeldung zu ermöglichen Bei der Wahl der Identity-Federation-Plattform müssen Serviceprovider auf eine skalierbare und kosteneffektive Lösung achten, die mehrere Protokolle unterstützt und sich einfach implementieren und warten lässt. SaML oder WS-Federation? Der größte Vorteil des SAML-Standards liegt darin, dass er weit verbreitet ist und von immer mehr Organisationen genutzt wird. Er wird häufig von Unternehmen sowie deren Kunden, Geschäftspartnern und Cloud-Anbietern verwendet. Der Grund, warum sich so viele Unternehmen für SAML entscheiden, sind seine zahlreichen Vorteile. SAML seit 2002 ein OASIS-Standard sorgt in Tausenden Produktionsumgebungen auf der ganzen Welt für hohe Sicherheit, Skalierbarkeit und Zuverlässigkeit. Mit strengen Interoperabilitätszertifizierungen reduziert die Liberty Alliance Probleme, wenn z. B. mögliche Partner verschiedene Anbieterprodukte verwenden. Darüber hinaus verfügt der Markt bereits über Erfahrung mit SAML. Es gibt eine Fülle an SAML-Implementierungsoptionen, z. B. kommerzielle Identity-Federation-Softwareprodukte, Open-Source-Lösungen und kommerzielle Entwicklungsbibliotheken. WS-Federation ist Teil der Webservices- oder WS-* (ausgesprochen WS Stern )-Suite an Spezifikationen, die von Microsoft und IBM entwickelt wurden. Die WS-*Suite umfasst zahlreiche Spezifikationen zur Implementierung von Webservices für eine hohe Interoperabilität und Sicherheit. WS-Federation ist die Spezifikation der Suite für die Ausgabe von Sicherheitstoken (ähnlich einer SAML-Aussage), die alle für die Federated Identity erforderlichen Attribute enthalten. Darüber hinaus bietet WS-Federation ähnliche Funktionen wie die Internet-SSO-Features von SAML. WS-Federation wird vor allem in Microsoft Windows-Serverumgebungen eingesetzt. Anfangs war es der einzige Identity-Federation-Standard, der durch den Active Directory Federation Server (ADFS) von Microsoft, einem Teil von Microsofts Active Directory-Familie, unterstützt wurde. ADFS wurde zunächst eingesetzt, um SSO sowie weitere Arten von Federated Identity zwischen Windows-Anwendungen zu ermöglichen. Microsoft erkannte schnell die breite Marktakzeptanz von SAML und fügte im zweiten ADFS-Release Unterstützung für SAML 2.0 hinzu. Die Erweiterung von ADFS um SAML zeigt, dass sogar Microsoft die vorherrschende Stellung von SAML bei der B2B-Identity-Federation anerkennt. 8
Die National IT and Telecom Agency in Dänemark unterzog sowohl SAML als auch WS-Federation einer gründlichen Evaluierung. Dabei stellte sich heraus, dass SAML in jeder Kategorie WS-Federation überlegen war mit einer einzigen Ausnahme: Microsoft unterstützt WS-Federation, was als Vorteil eingestuft wurde. Dem Bericht zufolge unterstützen alle weiteren bedeutenden Anbieter SAML 2.0 oder planen, dies zu tun. Gleichzeitig ist davon auszugehen, dass sie alle auch WS- Federation unterstützen werden. Mit anderen Worten: Die wichtigsten Anbieter von Identity- Federation-Lösungen unterstützen in der Regel sowohl SAML als auch WS-Federation. SAML und WS-Federation schließen sich also nicht gegenseitig aus. In der Regel wird eine Organisation sehr wahrscheinlich mit Partnern zusammenarbeiten, die den einen oder anderen Standard, aber nur selten beide, unterstützen. Eine Federated-Identity-Lösung der Enterprise- und Serviceprovider-Class muss daher beide Standards unterstützen. Schließlich macht Federated Identity nur wirklich Sinn, wenn sich möglichst viele Anwendungsfälle über eine Vielzahl potenzieller Partner hinweg abdecken lassen. Um weitere mögliche Szenarien abzudecken, müssen außerdem alle drei SAML-Versionen (1.0, 1.1 und 2.0) und WS-Federation (einschließlich Generierung und Verwendung von Aussagen) unterstützt werden. SaML und weitere identitätsprotokolle SAML ist zwar ein wichtiger Teil der Federation-Architektur, doch bei weitem nicht der einzige. Daher muss sich SAML auch mit anderen Federation-Protokollen gut verstehen, z. B. mit dem relativ neuen Simple Cloud Identity Management (SCIM)-Protokoll. SCIM ist ein schlankes Provisioning-Protokoll, das insbesondere für große Unternehmen optimiert ist, die Benutzerkonten und den Zugriff für ihre Mitarbeiter bei den verschiedenen Cloud-Anbietern und Anwendungen verwalten, die sie abonniert haben. SCIM bietet eine RESTful-API, mit der große Unternehmen direkt CRUD(Create, Read, Update, Delete)-Operationen durchführen können, um ihre Mitarbeiterkonten an den Provisioning-Endpunkten von SaaS-Anbietern zu verwalten. SCIM bietet auch ein sogenanntes Just-in-Time -Provisioning-Modell. Hier werden Konten nicht beim ersten Zugriff durch einen Mitarbeiter erstellt, sondern eher indirekt über die erste SSO-Aktivität. Für dieses Szenario legt SCIM eine Verbindung mit SAML fest und bestimmt so, wie SCIM-definierte Benutzerattribute (z. B. Profildaten, Gruppen und Rollen) innerhalb der SAML-Aussage übertragen werden. OAuth 2.0 ist ein weiteres Protokoll, das noch nicht einmal angedacht war, als SAML erstmals definiert wurde. OAuth 2.0 und seit Kurzem auch OpenID Connect, das auf der OAuth 2.0-Spezifikation aufbaut konzentrierte sich zunächst auf den Verbraucherbereich mit seinen Tweets und Facebook-Fotos. Inzwischen entwickelt es sich zunehmend zu einem wichtigen Cloud-Standard, da es ein Framework für den Schutz von APIs einer wichtigen Grundlage der Cloud bietet. Ein Beispiel hierfür ist Salesforce, das OAuth künftig für sein gesamtes Repertoire an APIs einsetzen möchte. Diese APIs werden immer wichtiger und verdrängen sogar den Browser als vorherrschenden Zugriffskanal, den Salesforce seinen Kunden bietet. Besonders wichtig: OAuth kann mobile native Anwendungen gegenüber ihren RESTful-APIs authentifizieren ein Anwendungsfall, für den SAML nie optimiert war. Es gibt viele verschiedene Szenarien und Implementierungsmodelle, für die sich OAuth und SAML gewinnbringend kombinieren lassen. Z. B. lassen sich OAuth-Tokens als Parameter bei SAML-Nachrichten übertragen oder eine SAML-Aussage könnte für einen entsprechenden OAuth-Token eingetauscht werden. So kann die Kluft zwischen den SOAP-Webservices und der RESTful-Welt überwunden werden. 9
Fazit Die heutige weborientierte Anwendungslandschaft ist von einer großen Vielzahl an internen und externen Webapplikationen und -services geprägt. Federated Identity sorgt hier nicht nur für einen sicheren und nahtlosen Zugriff auf alle Anwendungen, sondern auch für eine möglichst schnelle Benutzerakzeptanz. Gleichzeitig bietet sie zuverlässige Standards eine wichtige Voraussetzung, um Internet-Single-Sign-on für mehr als ein oder zwei Partner überhaupt kosteneffektiv skalieren zu können. Aufgrund seiner zertifizierbaren Interoperabilität, seiner hohen Sicherheit und der Tausenden erfolgreichen Produktionsumgebungen hat sich SAML zum vorherrschenden Identity-Federation-Standard entwickelt. Wenn Sie SAML-Lösungen evaluieren, sollten Sie unbedingt alle relevanten Anwendungsfälle, die Integration mit Ihrer bestehenden Infrastruktur sowie sämtliche Identitätsstandards im Blick behalten. Bei den heutigen SAML-Lösungen handelt es sich um ausgereifte Produkte. Vorausgesetzt, Sie treffen die richtige Wahl, werden Sie für die Implementierung von SAML-basiertem Internet- SSO daher nur wenige Tage (manchmal sogar Minuten) benötigen. 2014 Ping Identity Corporation. Alle Rechte vorbehalten. Ping Identity, PingFederate, PingOne, PingEnable, das Logo von Ping Identity und Cloud Identity Summit sind eingetragene Handels- und Dienstleistungsmarken der Ping Identity Corporation. Alle anderen Produkt- und Dienstleistungsnamen sind Handelsmarken ihrer jeweiligen Unternehmen. 3/14.1 ping identity Die identity Security Company Identity Security-Pionier Ping Identity ist der größte unabhängige Dienstleister von modernen Identity Security-Lösungen. Über 2.000 Unternehmen, darunter die Hälfte der Fortune 100, verlassen sich auf diese Lösungen, damit sich Hunderte von Millionen Menschen sicher in der digitalen Welt bewegen und so erst deren volles Potenzial nutzen können. Ping Identity bietet Mitarbeitern in Unternehmen sowie deren Kunden und Partnern mit einem Klick sicheren Zugriff auf jede Anwendung von jedem Gerät aus. Weitere Informationen stehen auf www.pingidentity.com bereit. 10