WS-Federation ist die fünfte von insgesamt sieben geplanten Spezifikationen, mit denen sich eine durchgängige Sicherheitsarchitektur für Web-Services aufbauen lassen soll.
Der Entwurf geht auf Arbeiten eines Firmenkonsortiums aus IBM, Microsoft, Bea Systems, RSA Security und Verisign zurück und hat zum Ziel, Mechanismen zu entwickeln, mit denen sich Benutzer- und Systemidentitäten, Konten und die Benutzerauthorisierung über einzelne Sicherheitsumgebungen hinweg definieren lassen. Die Spezifikationen könnten damit einen zentralen Bestandteil künftiger Single-Sign-on-Lösungen stellen.
Rad neu erfunden?
Allerdings arbeitet die von Sun Microsystems initiierte Liberty Alliance, in der sich rund 170 Hersteller und Großunternehmen zusammengefunden haben, seit gut zwei Jahren an vergleichbaren Standards für Single-Sign-on- Funktionen und eine unternehmensübergreifende Zusammenfassung von Benutzerkonten. Marktbeobachter befürchten daher, dass durch die Pläne von IBM und Microsoft, die nicht der Liberty Alliance angehören, eine parallele Entwicklung von Sicherheitskonzepten beginnt, die eine Standardisierung auf lange Sicht verhindern könnte.
Bei der Vorstellung von WS-Federation spielten Vertreter beider Hersteller diese Gefahr jedoch herunter und warben damit, dass sich ihre Spezifikationen künftig problemlos in das Liberty-Konzept einbringen lassen würden, zumal es schon heute Gemeinsamkeiten bei der technischen Implementierung gebe. So nutzen beide Konsortien das Sicherheitsmodell "WS-Security", das die Basis für die angestrebte Sicherheitsarchitektur für Web-Services stellt und das Simple Object Access Protocol (Soap) erweitert.
WS-Security als Basis
Es beschreibt den Austausch von digitalen Zertifikaten, um die Integrität einer Nachricht überprüfen zu könnnen sowie die Vertraulichkeit einer Nachricht zu sichern. WS-Security erlaubt es, gängige Sicherheitstechniken wie X.509-Zertifikate oder Kerberos-Tickets speziell in Soap-Nachrichten einzusetzen sowie Content mit Hilfe von "XML Encryption" und "XML Signature" zu verschlüsseln und zu unterzeichnen. Zudem legt es einen Mechanismus fest, mit dem sich Benutzeranmeldeinformationen übermitteln lassen.
Ebenso verwenden beide Projekte das XML-Framework "Security Assertions Markup Language" (SAML). Mit ihrer Hilfe lassen sich Benutzernamen und Passwörter an die Authentifizierungsinstanz übermitteln. Letztere überprüft die Daten und generiert die Authentifizierung sowie sicherheitsbezogene Informationen (Assertions), die in einem SAML-Token zusammengefasst werden. Mit dem Token kann der Anwender dann auf einen gesicherten Bereich zugreifen.
WS-Security und SAML sind zudem von der Organization for the Advancement of Structured Information Standards (Oasis), die auch Liberty als Anlaufstelle nutzt, als Standards verabschiedet worden.
Abgrenzungsversuche
Trotzdem sorgte die Vorstellung von WS-Federation für Verärgerung bei Liberty. So wies man die Behauptung von Microsoft zurück, dass das Liberty-Konzept monolithisch und unflexibel sei und Softwarehäuser und Anwender für jede Sicherheitstechnik wie Kerberos-Tickets, digitale Zertifikate oder Passwörter eigene SAML-Assertions entwickeln müssten, während WS-Federation mehrere Assertions gleichzeitig unterstützte. Ebenso treffe es nicht zu, dass Liberty nur das Soap-Transportprotokoll unterstütze.
Bob Blakley, Cheftechnologe der IBM-Tivoli-Division, räumte ein, dass die eigenen Spezifikationen für Web-Services derzeit noch nicht ausreichend sind, Liberty sei aber überspezifiziert, sprich: zu kompliziert. Slava Kasvan, Vice President Engineering bei RSA Security, schlug deshalb vor, die beiden Lager an einen Tisch zu bringen, da eine Konvergenz beider Aktivitäten allen nützen würde. Eric Norlin, Vice President Marketing bei Ping Identity und Liberty-Mitglied, konterte, dass es eine solche Konvergenz etwa bei WS-Security bereits gebe und Liberty auch künftig "relevante" Bestandteile übernehmen wird, sobald die Vorschläge standardisiert sind.
Trustbridge wird überholt
Version 1.0 von WS-Federation, das auf WS-Security basiert, ist bei Microsoft einzusehen ( http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-federation.asp) und soll voraussichtlich zusammen mit den übrigen Sicherheitsspezifikationen für WS-Security "WS-Policy", "WS-Trust" und "WS Secure Conversation" an Oasis übergeben werden. Die noch fehlenden Vorschläge "WS-Privacy" und "WS-Authorization" sollen zum Jahresende folgen. Microsoft hat zudem angekündigt, die Spezifikationen in seiner bisher erfolglosen Authentifizierungstechnologie "Trustbridge" zu implementieren und 2005 oder 2006 ein entsprechendes Produkt zusammen mit der nächsten Windows-Version, Codename "Longhorn", auf den Markt zu bringen. Außerdem kündigten die Redmonder das Toolkit "Web Services Enhancements" (WSE) in Version 2.0 an, das die Einsatzmöglichkeiten der XML-Technik in der Entwicklungsumgebung "Visual Studio .NET" erweitert und unter anderem einen ersten Einblick in die genannten Spezifikationen verschafft. Zudem lassen sich jetzt mit WSE diverse Transportprotokolle wie HTTP oder TCP nutzen.
Derweil arbeitet Liberty, dessen Spezifikationen bereits von rund 15 Produkten genutzt werden, seit einigen Monaten an der nächsten Generation seiner Plattform. In diesem Zusammenhang wurden jetzt eine Reihe von Richtlinien veröffentlicht, die Unternehmen bei der Implementierung von föderierten Identitätslösungen helfen sollen. Behandelt werden zunächst Themen wie "Mutual Confidence", "Risk Management", "Liability Assessment" und "Compliance". Simon Nicholson, Chair der Liberty Alliance Business and Marketing Expert Group, sieht in solchen Vorgaben einen Unterschied zu WS-Federation: "Föderierte Identitäten brauchen mehr als technische Spezifikationen. Anwender müssen auch die Anforderungen, Firmenpolitik und rechtliche Aspekte kennen, die eine vertauensvolle Geschäftsbeziehung ausmachen."
Abb: Erweiterung des Soap-Protokolls
Die Sicherheitsarchitektur, wie sie IBM und Microsoft vorschlagen, erweitert das Soap-Protokoll um sieben Spezifikationen. Quelle: nach Microsoft