Spezifikation "Web Services Security" - eine Chronologie

Die Entwicklung der Spezifikation "Web Services Security" umfasst Informationen der von OASIS (Organization for the Advancement of Structured Information Standards) entwickelten Spezifikation "Web Services Security". Die Spezifikation "Web Services Security" von OASIS dient als Basis zur Sicherung von Web-Services in WebSphere Application Server.

Bewährte Verfahren: IBM® WebSphere Application Server unterstützt das Programmiermodell Java™ API for XML-Based Web Services (JAX-WS) und das Programmiermodell Java API for XML-based RPC (JAX-RPC). JAX-WS ist das Web-Service-Programmiermodell der nächsten Generation, das die vom Programmiermodell JAX-RPC bereitgestellte Grundlage erweitert. Durch die Verwendung des strategischen Programmiermodells JAX-WS, das ein auf Standards basierendes Annotationsmodell unterstützt, vereinfacht sich die Entwicklung von Web-Services und -Clients. Obwohl das Programmiermodell JAX-RPC und JAX-RPC-Anwendungen weiterhin unterstützt werden, sollten Sie das einfach zu implementierende Programmiermodell JAX-WS für die Entwicklung neuer Web-Service-Anwendungen und -Clients nutzen.
Die Verwendung des Programmiermodells JAX-WS in WebSphere Application Server hat folgende Vorteile:
  • Die Konfiguration der Servicequalität wird bei Verwendung von Richtliniensätzen vereinfacht. Richtliniensätze sind eine Kombination von Konfigurationseinstellungen, einschließlich der Einstellungen für die Konfiguration auf Transport- und Nachrichtenebene. Richtliniensätze und allgemeine Bindungen können anwendungsübergreifend verwendet werden, sodass die Web-Service-Servicequalität besser konsumierbar ist.
  • WS-Security for JAX-WS wird sowohl in einer verwalteten Umgebung, z. B. in einem Java-EE-Container, als auch in nicht verwalteten Umgebungen wie Java Platform, Standard Edition (Java SE 6) unterstützt. Außerdem wird eine API bereitgestellt, mit der WS-Security im JAX-WS-Client aktiviert werden kann.

Aktivitäten außerhalb von OASIS

Web-Services werden in wachsendem Maße als funktionsfähige Technologie für Interoperabilität und Integration akzeptiert. Allerdings ist die Sicherheit von Web-Services eine der wichtigsten Servicequalitäten, die die Übernahme von Web-Services als branchenspezifische und kommerzielle Lösung für Unternehmen attraktiv macht. IBM und Microsoft haben gemeinsam ein White Paper zur Sicherheit in Web-Services mit dem Titel Security in a Web Services World: A Proposed Architecture and Roadmap veröffentlicht. Dieses White Paper erläutert die folgenden ursprünglichen Spezifikationen und nachfolgenden Spezifikationen in der vorgeschlagenen WS-Security-Roadmap:
Web Services Security
Diese Spezifikation definiert, wie eine digitale Signatur angehängt, die Verschlüsselung verwendet und Sicherheitstoken in SOAP-Nachrichten (Simple Object Access Protocol) eingesetzt werden.
WS-Policy
Diese Spezifikation definiert die Sprache, die zur Beschreibung der Sicherheitsvorgaben und der Richtlinie von Zwischenstationen oder Endpunkten verwendet wird.
WS-Trust
Diese Spezifikation legt die Rahmendefinition für Trustmodelle fest, mit denen Vertrauen (Trust) zwischen Web-Services hergestellt wird.
WS-Privacy
Diese Spezifikation definiert in einem Modell, wie eine private Richtlinie für einen Web-Service und einen Requester ausgedrückt wird.
WS-SecureConversation
Diese Spezifikation definiert Austausch und Aufbau eines sicheren Kontextes, der Sitzungsschlüssel aus Web-Services ableitet.
WS-Authorization

Diese Spezifikation definiert die Autorisierungsrichtlinie für einen Web-Service. Die Spezifikation WS-Authorization wurde jedoch nicht veröffentlicht. Die vorhandene Implementierung von Web Services Security basiert auf der Spezifikation Web Services for Java Platform, Enterprise Edition (Java EE) oder auf der Spezifikation Java Specification Requirements (JSR) 109. Die Implementierung von Web Services Security nutzt die rollenbasierten Java-EE-Berechtigungsprüfungen. Informationen zu Konzepten finden Sie in der Dokumentation zur rollenbasierten Berechtigung. Wenn Sie einen Web-Service entwickeln, der Berechtigungsprüfungen auf Methodenebene erfordert, müssen Sie zum Implementieren des Web-Service Stateless-Session-Beans verwenden. Weitere Informationen finden Sie in der Dokumentation zum Sichern von Enterprise-Bean-Anwendungen.

Wenn Sie einen Web-Service entwickeln, der als Servlet implementiert wird, können Sie eine allgemein definierte oder URL-basierte Autorisierung im Web-Container verwenden. In diesem Fall ist es jedoch nicht möglich, die Identität von Web Services Security für Berechtigungsprüfungen zu verwenden. Stattdessen kann die Identität aus dem Transport verwendet werden. Bei Verwendung von SOAP over HTTP ist die Identität dann im HTTP-Transport.

Die folgende Abbildung zeigt die Beziehung zwischen diesen Spezifikationen:

Beziehung zwischen den verschiedenen Spezifikationen

Im April 2002 stellten IBM, Microsoft und VeriSign auf ihren jeweiligen Websites die Spezifikation Web Services Security (WS-Security) vor (siehe grünes Kästchen im Bild weiter oben). Diese Spezifikation enthielt die grundlegenden Konzepte eines Sicherheitstoken, einer digitalen XML-Signatur und einer XML-Verschlüsselung. Die Spezifikation definierte auch das Format für Benutzernamenstoken und verschlüsselte binäre Sicherheitstoken. Nachdem einigen Diskussionen geführt und ein Interoperabilitätstest basierend auf der Spezifikation durchgeführt worden war, wurden die folgenden Punkte festgehalten:
  • Die Spezifikation setzt voraus, dass der Prozessor für Web Services Security das Schema richtig versteht, damit er zwischen den ID-Attributen für die digitale XML-Signatur und die XML-Verschlüsselung unterscheiden kann.
  • Die Aktualität der Nachricht, d. h. Angaben dazu, ob die Nachricht mit vordefinierten Zeitbeschränkungen übereinstimmt, kann nicht bestimmt werden.
  • Verarbeitete Kennwortzeichenfolgen erhöhen die Sicherheit nicht.
Im August 2002 veröffentlichten IBM, Microsoft und VeriSign das Web Services Security Addendum, mit dem die zuvor aufgelisteten Probleme gelöst werden sollten. Folgende Lösungsstrategien wurden in das Zusatzdokument aufgenommen:
  • Ein globales ID-Attribut für XML-Signatur und XML-Verschlüsselung ist erforderlich.
  • Es müssen Zeitmarkenheaderelemente verwendet werden, die Erstellungszeit, Empfang oder Verfallsdatum der Nachricht anzeigen.
  • Es müssen Kennwortzeichenfolgen verwendet werden, die mit einer Zeitmarke und Nonce, einem nach dem Zufallsprinzip generierten Token, verarbeitet werden.

Die Spezifikationen in den blauen Kästchen der Abbildung weiter oben wurden von verschiedenen branchenspezifischen Herstellern vorgeschlagen, und diese Hersteller haben verschiedene Interoperabilitätsprüfungen durchgeführt, um die vorgeschlagenen Spezifikationen zu verifizieren und zu optimieren.

OASIS-Aktivitäten

Im Juni 2002 erhielt OASIS (Organization for the Advancement of Structured Information Standards) von IBM, Microsoft und VeriSign den Vorschlag einer Web Services Security-Spezifikation. Bald nach der Einsendung des Vorschlags wurde bei OASIS das WSS TC (Web Services Security Technical Committee) ins Leben gerufen. An diesem Ausschuss waren viele Unternehmen beteiligt, einschließlich IBM, Microsoft VeriSign, Sun Microsystems und BEA Systems.

Im September 2002 veröffentlichte das WSS TC seine erste Spezifikation "Web Services Security Core Specification, Working Draft 01". Diese Spezifikation umfasste den Inhalt der ursprünglichen Spezifikation "Web Services Security" und sowie das Zusatzdokument.

Im weiteren Verlauf der Diskussion deckte der Ausschuss einen immer größeren Bereich ab. Da die Spezifikation "Web Services Security Core Specification" willkürliche Typen von Sicherheitstoken zulässt, wurden Vorschläge als Profile veröffentlicht. Die Profile beschrieben die Methode für das Einbetten von Token, einschließlich der in WS-Security-Nachrichten eingebetteten SAML-Token (Security Assertion Markup Language) und Kerberos-Token. Daraufhin wurden die Definitionen für die Verwendung von Benutzernamenstoken und binären X.509-Sicherheitstoken, die in der ursprünglichen Web Services Security-Spezifikation definiert waren, in die Profile unterteilt.

WebSphere Application Server Version 5.0.2, 5.1 und 5.1.1 unterstützen die folgenden Spezifikationen:
  • Web Services Security: SOAP Message Security Draft 13 (vorher Web Services Security Core Specification)
  • Web Services Security: Username Token Profile Draft 2
Im April 2004 wurde die Spezifikation "Web Services Security" (die offiziell den Namen Web Services Security: SOAP Message Security Version 1.0 hat) zum OASIS-Standard Version 1.0. Das Benutzernamenstokenprofil und das X.509-Tokenprofil sind ebenfalls Spezifikationen der Version 1.0. WebSphere Application Server Version 6 und höher unterstützt die folgenden Spezifikationen "Web Services Security" von OASIS:
Im Februar 2006 wurde die Basisspezifikation von Web Services Security aktualisiert und zum OASIS-Standard der Version 1.1. Außerdem wurden das Benutzernamenstoken, das X.509-Tokenprofil und das Kerberos-Tokenprofil auf Spezifikationen der Version 1.1 aktualisiert. Teile der folgenden WS-Security-Spezifikationen von OASIS werden in WebSphere Application Server unterstützt, insbesondere Signaturbestätigung, verschlüsselte Header und Fingerabdrucksreferenzen:

die folgende Spezifikation beschreibt die Verwendung von Kerberos-Token für Spezifikationen der WS-Security-Nachrichtensicherheit. Diese Spezifikation definiert, wie ein Kerberos-Token zur Unterstützung von Authentifizierung und Nachrichtenschutz verwendet werden kann: OASIS: Web Services Security Kerberos Token Profile 1.1 OASIS Standard Specification, 1 February 2006.

Im Jahr 2007 hat das OASIS Web Services Secure Exchange Technical Committee (WS-SX) folgende Spezifikationen definiert und genehmigt. Teile dieser Spezifikationen werden von WebSphere Application Server Version 7 und höher unterstützt.

Die folgende Abbildung zeigt die verschiedenen Spezifikationen im Zusammenhang mit Web Services Security.

OASIS-Spezifikationen

WebSphere Application Server stellt außerdem eine Plug-in-Funktionalität bereit, damit Sicherheitsprovider die Laufzeitfunktionalität erweitern und in den WS-Security-Stack einige Spezifikationen der höheren Ebene implementieren können. Die Plug-in-Punkte werden als Service Provider Programming Interfaces (SPI) dargestellt. Nähere Informationen zu diesen SPIs finden Sie im Artikel Standardimplementierungen der Programmierschnittstellen des Service-Providers von Web Services Security.

Entwicklung der Spezifikation "Web Services Security 1.0"

Die OASIS-Spezifikation "Web Services Security" basiert auf den folgenden Spezifikationen des World Wide Web Consortium (W3C). Die meisten W3C-Spezifikationen sind derzeit als Empfehlungen eingestuft.

Diese Spezifikationen werden in WebSphere Application Server im Kontext von Web Services Security unterstützt. Beispielsweise können Sie eine SOAP-Nachricht signieren, indem Sie im Implementierungsdeskriptor die Integritätsoption (integrity) angeben. Auf der Clientseite existiert eine API (Application Programming Interface, Anwendungsprogrammierschnittstelle), mit der eine Anwendung Web Services Security für den Schutz einer SOAP-Nachricht aktivieren kann.

Die OASIS-Spezifikation "Web Services Security Version 1.0" definiert die funktionalen Erweiterungen, mit denen die Nachrichtenintegrität und -vertraulichkeit sichergestellt werden. Außerdem enthält sie eine allgemeine Rahmendefinition, die festlegt, wie die Sicherheitstoken einer SOAP-Nachricht zugeordnet werden. Die Spezifikation ist so definiert, dass sie für die Unterstützung mehrerer Sicherheitstokenformate ausgeweitet werden kann. Diese spezielle Verwendung des Sicherheitstokens wird im Sicherheitstokenprofil festgelegt.

Unterstützung von Spezifikationen und Profilen in WebSphere Application Server

OASIS kann für verschiedene Profile eingesetzt werden. Nähere Informationen hierzu finden Sie auf der Webseite Organization for the Advancement of Structured Information Standards Committees.

Die folgende Liste enthält einige der veröffentlichten Entwurfsprofile und die in der Entwicklung befindliche Arbeit des OASIS Web Services Security Technical Committee (WSS TC).

WebSphere Application Server bietet keine Unterstützung für die folgenden Profile:

  • Web Services Security: SAML Token Profile 1.0
  • Web Services Security: Rights Expression Language (REL) Token Profile 1.0
  • Web Services Security: SOAP Messages with Attachments (SwA) Profile 1.0
Anmerkung: "Web Services Security Draft 13" und "Username Token Profile Draft 2" werden in WebSphere Application Server 5.0.2, 5.1.0 and 5.1.1 nicht weiter unterstützt. Informationen zur Migration finden Sie im Artikel Für Web Services Security aktivierte JAX-RPC-Anwendungen von Java EE Version 1.3 auf Version 1.4 migrieren.

Das physische Format der SOAP-Nachricht mit Web Services Security des Standards "Web Services Security Version 1.0" wurde geändert und ist nicht kompatibel mit früheren Entwürfen der OASIS-Spezifikation Web Services Security. Die Interoperabilität zwischen "OASIS Web Services Security Version 1.0" und früheren Entwürfen für Web Services Security wird nicht unterstützt. Es ist jedoch möglich, eine Anwendung, die auf dem Entwurf "Web Services Security Draft 13" basiert, in WebSphere Application Server Version 6 und höher auszuführen. Die Anwendung kann mit einer Anwendung zusammenarbeiten, die auf "Web Services Security Draft 13" inWebSphere Application Server Version 5.0.2, 5.1 or 5.1.1 basiert.

WebSphere Application Server unterstützt sowohl den OASIS-Entwurf "Web Services Security Draft 13" als auch die OASIS-Spezifikation "Web Services Security 1.0". In WebSphere Application Server Version 6 und höher wird "OASIS Web Services Security Draft 13" jedoch nicht weiter unterstützt. Anwendungen, die mit "OASIS Web Services Security Draft 13" in WebSphere Application Server 5.0.2, 5.1.0 und 5.1.1 entwickelt wurden, können allerdings weiterhin in WebSphere Application Server Version 6 und höher ausgeführt werden. "OASIS Web Services Security Version 1.0" wird nur für Anwendungen für Java Platform, Enterprise Edition (Java EE) Version 1.4 und höher unterstützt. Das Konfigurationsformat für den Implementierungsdeskriptor und die Bindung unterscheidet sich von früheren Versionen von WebSphere Application Server. Sie müssen vorhandene Anwendungen nach Java EE 1.4 migrieren und die Konfiguration von Web Services Security auf das Format von WebSphere Application Server Version 6 umstellen.

Entwicklung weiterer WS-Security-Spezifikationen

Folgende aktualisierte Versionen der WS-Security-Spezifikationen von OASIS werden in WebSphere Application Server im Kontext von Web Services Security unterstützt:
  • WS-Trust Version 1.3

    Die Spezifikation "Web Services Trust Language (WS-Trust)" verwendet sichere Messaging-Mechanismen von Web Services Security, um weitere Basiselemente und Erweiterungen für das Ausstellen, den Austausch und die Validierung von Sicherheitstoken zu definieren. WS-Trust unterstützt das Ausstellen und Verteilen von Berechtigungsnachweisen in unterschiedlichen Trustdomänen. Diese Spezifikation definiert Möglichkeiten, Vertrauensbeziehungen herzustellen, zu ermitteln und zu vermitteln.

  • WS-SecureConversation Version 1.3

    WS-SecureConversation baut auf den Modellen WS-Security und WS-Policy auf und bietet eine sichere Kommunikation zwischen Services. WS-Security konzentriert sich auf das Nachrichtenauthentifizierungsmodell, aber nicht in einem Sicherheitskontext und ist deshalb verschiedenen Formen von Sicherheitsattacken ausgesetzt. Diese Spezifikation definiert Mechanismen für das Erstellen und die gemeinsame Nutzung von Sicherheitskontexten und die Ableitung von Schlüsseln aus Sicherheitskontexten für die Unterstützung eines sicheren Dialogs. Wenn Sie das Erweiterbarkeitsmodell von SOAP verwenden, können modulare SOAP-basierte Spezifikationen zu einer reichhaltigen Messaging-Umgebung miteinander kombiniert werden.

  • WS-SecurityPolicy Version 1.2

    Web Services Security Policy (WS-Policy) ist ein Allzweckmodell und eine Allzwecksyntax für die Beschreibung und Übertragung der Richtlinien eines Web-Service. WS-Policy-Zusicherungen drücken die Leistungsmerkmale und Einschränkungen eines bestimmten Web-Service aus. WS-PolicyAttachments definiert verschiedene Methoden für die Zuordnung der WS-Policy-Ausdrücke zu Web-Services (z. B. WSDL). Die Spezifikationen für Web Services Security wurden nach der erneuten Veröffentlichung von WS-Security Policy im Juli 2005 aktualisiert, um die Einschränkungen und Leistungsmerkmale von Web-Services widerzuspiegeln, die WS-Security, WSTrust und WS-SecureConversation verwenden. WS-ReliableMessaging Policy wurde ebenfalls in 2005 erneut veröffentlicht, um die Leistungsmerkmale und Einschränkungen von Web-Services zu veranschaulichen, die WS-ReliableMessaging implementieren.

Aktivitäten der Web Services Interoperability Organization (WS-I)

Die Web Services Interoperability Organization (WS-I) unternimmt den Versuch, branchenunabhängig die Interoperabilität von Web-Services zwischen Herstellern, Plattformen, Programmiersprachen und Anwendungen zu fördern. Die Organisation ist ein Konsortium von Unternehmen aus vielen Branchen, zu dem IBM, Microsoft, Oracle, Sun, Novell, VeriSign und Daimler Chrysler gehören. WS-I hat Basic Security Profile (BSP) Version 1.0 und Version 1.1 entwickelt. Beide BSP-Versionen, 1.0 und 1.1, bestehen aus einer Reihe von nicht proprietären Web-Service-Spezifikationen, durch die die Spezifikationen zwecks besserer Interoperabilität von Web Services Security in den Implementierungen unterschiedlicher Hersteller transparenter gestaltet und erweitert werden.

WebSphere Application Server JAX-WS WS-Security unterstützt die folgenden Spezifikationen:

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_wssv6chron
Dateiname:cwbs_wssv6chron.html