SAML 101

WHITE PAPER

SAML 101WHITE PAPER

2

INHALTSÜBERSICHT

ZUSAMMENFASSUNG

EINLEITUNG

DIE SICHERHEIT IN EINER ZUNEHMEND VERNETZTEN WELT

FEDERATED IDENTITY

Große Unternehmen

Kleine und mittlere Unternehmen (KMUs)

Serviceprovider

Standardisierung der Federated Identity

ANWENDUNGSBEISPIELE FÜR SAML-IDENTITY-FEDERATION

SAML ODER WS-FEDERATION?

SAML UND WEITERE IDENTITÄTSPROTOKOLLE

FAZIT

03

04

05

06

08

10

11

12

SAML 101WHITE PAPER

3

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 für den Austausch von Benutzeridentitäten bereit und macht so die Pflege separater Benutzerprofile für jede Unternehmensanwendung überflüssig..

Der Identity-Federation-Standard Security Assertion Markup Language (SAML) unterstützt Single-Sign-on (SSO) und kann in

Unternehmen, Behörden und Non-Profit-Organisationen sowie bei Serviceprovidern 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 OpenID Connect, das auf der

OAuth-Spezifikation aufbaut, wurden entwickelt, um diese Anforderungen 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.

ZUSAMMENFASSUNG

SAML 101WHITE PAPER

4

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.

EINLEITUNG

SAML 101WHITE PAPER

5

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.

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.

DIE SICHERHEIT IN EINER ZUNEHMEND VERNETZTEN WELT

SAML 101WHITE PAPER

6

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.

STANDARDISIERUNG DER FEDERATED IDENTITY 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.

FEDERATED IDENTITY

SAML 101WHITE PAPER

7

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.

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.

NUTZER UND DEVICES

APPLIKATION

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 101WHITE PAPER

8

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.

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.

GROSSE UNTERNEHMENDie 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:

• 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

ANWENDUNGSBEISPIELE FÜR SAML-IDENTITY-FEDERATION

SAML 101WHITE PAPER

9

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.

SERVICEPROVIDERViele Serviceprovider haben erkannt, dass Federated Identity ein Business-Enabler ist – sei es als Mehrwertdienst oder als Antwort auf die

Nachfrage nach Internet-SSO.

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

SAML 101WHITE PAPER

10

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.

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.

SAML ODER WS-FEDERATION?

SAML 101WHITE PAPER

11

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 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.

SAML UND WEITERE IDENTITÄTSPROTOKOLLE

#3042_DE | 1.17 | v00v2

ABOUT PING IDENTITY: Über Ping Identity: Ping Identity ermöglicht Benutzern einen nahtlosen und sicheren Zugriff auf beliebige Anwendungen im hypervernetzten, offenen digitalen Unternehmen und leitet so eine neue Ära digitaler Freiräume ein. Mehr als eine Milliarde Identitäten weltweit werden von Ping Identity geschützt. Über die Hälfte der Fortune-100-Unternehmen, darunter Boeing, Cisco, Disney, GE, Kraft Foods, TIAA-CREF und Walgreens, setzt auf Ping Identity, um neue Problemstellungen rund um das Thema Sicherheit zu lösen, die aus der Nutzung mobiler, Cloud-, API- und IoT-Technologien entstanden sind. Weitere Informationen erhalten Sie auf pingidentity.com.

12

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.

FAZIT