Funktionale Erweiterungen von Web Services Security

WebSphere Application Server umfasst eine Reihe funktionaler Erweiterungen zur Sicherung von Web-Services. Beispielsweise werden in WebSphere Application Server Version 6.1 Feature Pack for Web Services und höher Richtliniensätze unterstützt, um die Sicherheitskonfiguration für Web-Services zu vereinfachen.

Erstellung Ihrer Anwendungen

Die Laufzeitimplementierung von Web Services Security, die in WebSphere Application Server Version 8 verwendet wird, basiert auf dem Programmiermodell Java™ API for XML Web Services (JAX-WS). Die JAX-WS-Laufzeitumgebung basiert auf Apache Open Source Axis2, und das Datenmodell ist AXIOM. Anstelle von Implementierungsdeskriptoren und Bindungen wird für die Konfiguration ein Richtliniensatz verwendet. Sie können die Anwendungsbindungsdateien, die den Richtliniensätzen zugeordnet sind, mit der Administrationskonsole von WebSphere Application Server editieren. Die JAX-WS-Laufzeit wird für WebSphere Application Server Version 6.1 Feature Pack for Web Services und höher unterstützt.

Das Programmiermodell JAX-RPC, das Implementierungsdeskriptoren und Bindungen verwendet, wird weiterhin unterstützt. Weitere Informationen finden Sie im Artikel JAX-RPC-Web-Services durch Sicherheit auf Nachrichtenebene schützen.

Richtliniensätze verwenden

Mit Hilfe von Richtliniensätzen können Sie die Konfiguration Ihrer Web-Service-Servicequalität vereinfachen.

Anmerkung: Richtliniensätze können nur für JAX-WS-Anwendungen in WebSphere Application Server Version 6.1 Feature Pack for Web Services und höher verwendet werden. Für JAX-RPC-Anwendungen können keine Richtliniensätze verwendet werden.

Richtliniensätze sind eine Kombination von Konfigurationseinstellungen, einschließlich der Konfigurationseinstellungen für die Transport- und Nachrichtenebene, wie z. B. Web Services Addressing (WS-Addressing), Web Services Reliable Messaging (WS-ReliableMessaging), und Web Services Security (WS-Security), die Secure Conversation (WS-SecureConversation) enthält.

Trust-Richtlinien verwalten

Web Services Security Trust (WS-Trust) bietet einem Endpunkt die Möglichkeit, ein Sicherheitskontexttoken für Web Services Secure Conversation (WS-SecureConversation) auszustellen. Die Unterstützung für das Ausstellen von Token ist auf das Sicherheitskontexttoken beschränkt. Bei der Verwaltung von Trust-Richtlinien wird für jede Trust-Service-Operation, wie z. B. das Ausstellen, das Stornieren, das Validieren und das Erneuern eines Tokens, eine Richtlinie definiert. Die Bootstraprichtlinien eines Clients müssen den Trust-Service-Richtlinien von WebSphere Application Server entsprechen.

Sitzungsbasierte Nachrichten sichern

Web Services Secure Conversation (WS-SecureConversation) unterstützt eine gesicherte Sitzung für einen Dauernachrichtenaustausch und die Nutzung des symmetrischen Verschlüsselungsalgorithmus. WS-SecureConversation bietet die Basissicherheit für das Sichern sitzungsbasierter Nachrichtenaustauschmuster, wie z. B. Web Services Security Reliable Messaging (WS-ReliableMessaging).

Sicherheit auf Nachrichtenebene aktualisieren

Web Services Security (WS-Security) Version 1.1 unterstützt folgende Funktionen, die die Sicherheit auf Nachrichtenebene aktualisieren.
  • Signaturbestätigung
  • Verschlüsselte Header

Die Signaturbestätigung verbessert die Sicherheit durch digitale XML-Signatur. Das Element <SignatureConfirmation> gibt an, dass der Responder die Signatur in der Anforderung verarbeitet hat. Die Signaturbestätigung stellt sicher, dass die Signatur auch wirklich vom beabsichtigten Empfänger verarbeitet wurde. Damit die Bestätigung der Signatur ordnungsgemäß verarbeitet wird, muss der Initiator selbst bei der statusunabhängigen Charakteristik der Web-Services und den unterschiedlichen Nachrichtenaustauschmustern die Signaturen während der Anforderungsgenerierungsverarbeitung beibehalten und die Signaturen später für Bestätigungsprüfungen abrufen. Sie aktivieren die Signaturbestätigung durch Konfigurieren der Richtlinie.

Das Element für verschlüsselte Header ist eine standardisierte Methode zum Verschlüsseln von SOAP-Headern für eine verbesserte Interoperabilität. Wie in der Spezifikation für SOAP-Nachrichtensicherheit festgelegt, legt das Element <EncryptedHeader> fest, dass ein bestimmter SOAP-Header (oder eine Gruppe von Headern) geschützt werden muss. Durch das Verschlüsseln von SOAP-Headern und -Abschnitten kann eine höhere Sicherheit auf Nachrichtenebene erreicht werden. Das Element "EncryptedHeader" gewährleistet die Konformität mit den SOAP-Verarbeitungsrichtlinien "mustUnderstand" und verhindert die Offenlegung von Informationen, die in Attributen eines SOAP-Headerblocks enthalten sind.

Identitätszusicherung verwenden

In einer geschützten Umgebung, z. B. im Intranet, über eine SSL-Verbindung oder über ein virtuelles privates Netz (VPN), ist es sinnvoll, die Requester-Identität ohne Berechtigungsnachweise, wie z. B. ein Kennwort, zusammen mit gesicherten Berechtigungsnachweisen, z. B. der Serveridentität, zu senden. WebSphere Application Server unterstützt die folgenden Typen von Identitätszusicherung:
  • Benutzernamenstoken ohne ein Kennwort
  • X.509-Token für ein X.509-Zertifikat

Nähere Informationen zur Zusicherung der Identität finden Sie im Artikel über den Trusted-ID-Evaluator.

Signieren oder Verschlüsseln von Daten mit einem angepassten Token

Für das Programmiermodell JAX-RPC wurde der Key-Locator oder die Java-Schnittstelle "com.ibm.wsspi.wssecurity.keyinfo.KeyLocator" erweitert, um die Flexibilität der Spezifikation zu unterstützen. Der Key-Locator ist zuständig für die Lokalisierung des Schlüssels. Das lokale JAAS-Subjekt wird an die Methode KeyLocator.getKey() im Kontext übergeben. Die Key-Locator-Implementierung kann den Schlüssel aus dem Token ableiten, das vom Tokengenerator oder vom Tokenkonsumenten erstellt wird, um eine Nachricht zu signieren, die Signatur in einer Nachricht zu verifizieren, eine Nachricht zu verschlüsseln oder eine Nachricht zu entschlüsseln. Die Java-Schnittstelle "com.ibm.wsspi.wssecurity.keyinfo.KeyLocator" unterscheidet sich von der Version in WebSphere Application Server Version 5.x. Die Schnittstelle "com.ibm.wsspi.wssecurity.config.KeyLocator" der Version 5.x ist veraltet. Eine automatische Migration des Key-Locators von Version 5.x auf Version 6 oder höher existiert nicht. Sie müssen den Quellcode der Key-Locator-Implementierung der Version 5.x auf das Key-Locator-Programmiermodell für Version 6 und höher migrieren.

Für das Programmiermodell JAX-WS verwendet das Plug-in-Token-Framework dassselbe Framework aus der WSS API. Für die WS-Security-Laufzeit und die WSS-API-Anwendung kann dieselbe Implementierung für das Erstellen und Validieren von Sicherheitstoken verwendet werden. Dadurch wird das Programmiermodell SPI vereinfacht, und neue oder angepasste Sicherheitstokentypen können auf einfache Art und Weise hingefügt werden. Die überarbeitete SPI besteht aus folgenden Schnittstellen:
  • Der JAAS-Callback-Handler und das JAAS-Anmeldemodul erstellen Sicherheitstoken auf der Generatorseite und validieren oder authentifizieren Sicherheitstoken auf der Konsumentenseite.
  • Die Sicherheitstokenschnittstelle, "com.ibm.websphere.wssecurity.wssapi.token.SecurityToken", stellt das Sicherheitstoken dar, das Methoden für das Abrufen der Identität, des XML-Formats und der Chiffrierschlüssel enthält.
Bei Verwendung von JAX-WS sind die folgenden Schnittstellen nicht mehr erforderlich:
  • Tokengenerator (com.ibm.wsspi.wssecurity.token.TokenGeneratorComponent)
  • Tokenkonsument (com.ibm.wsspi.wssecurity.token.TokenConsumerComponent)
  • Key-Locator (com.ibm.wsspi.wssecurity.keyinfo.KeyLocator)
Weitere Informationen zu angepassten Sicherheitstoken finden Sie in den folgenden Artikeln auf der Website zu IBM® developerWorks:

Signieren oder Verschlüsseln eines XML-Elements

Ein XPath-Ausdruck wird verwendet, mit dem das XML-Element ausgewählt wird, das signiert oder verschlüsselt werden soll. Wenn Sie den SOAP-Envelope, den SOAP-Header oder den WS-Security-Header signieren, wird jedoch eine Envelope-Signatur verwendet. In JAX-RPC-Web-Services wird der XPath-Ausdruck im Anwendungsimplementierungsdeskriptor angegeben. In JAX-WS-Web-Service wird der XPath-Ausdruck in der WS-Security-Richtlinie des Richtliniensatzes angegeben.

Das Programmiermodell JAX-WS verwendet Richtliniensätze, um die Nachrichtenabschnitte festzulegen, die gesichert werden sollen. Beispielsweise wird die Zusicherung <Body> verwendet, um anzugeben, dass der Hauptteil ("body") der SOAP-Nachricht signiert oder verschlüsselt ist. Ein weiteres Beispiel ist die Zusicherung <Header>, in der der QName des SOAP-Headers angegeben ist, der signiert oder verschlüsselt werden soll.

Signieren oder Verschlüsseln von SOAP-Headern

Die Unterstützung für OASIS Web Services Security (WS-Security) Version 1.1 bietet eine standardisierte Methode für das Verschlüsseln und Signieren von SOAP-Headern. Zum Signieren oder Verschlüsseln von SOAP-Nachrichten geben Sie den QName an, um Headerelemente im SOAP-Header der SOAP-Nachricht auszuwählen.

Sie können Richtliniensätze für das Signieren oder Verschlüsseln über die Administrationskonsole oder die APIs von Web Services Security APIs (WSS-APIs) konfigurieren. Nähere Einzelheiten finden Sie im Artikel über das Sichern von Nachrichtenabschnitten über die Administrationskonsole.

Geben Sie Folgendes für die Signatur an:
Name
Dieses optionale Attribut gibt den lokalen Namen des SOAP-Headers an, dessen Integrität geschützt werden soll. Wenn dieses Attribut nicht angegeben wird, müssen alle SOAP-Header geschützt werden, deren Namespaces mit dem Attribut "Namespace" übereinstimmen.
Namespace
Dieses erforderliche Attribut gibt den Namespace der SOAP-Header an, deren Integrität geschützt werden soll.
Geben Sie Folgendes für die Verschlüsselung an:
Name
Dieses optionale Attribut gibt den lokalen Namen des SOAP-Headers an, dessen Vertraulichkeit geschützt werden soll. Wenn dieses Attribut nicht angegeben wird, müssen alle SOAP-Header geschützt werden, deren Namespaces mit dem Attribut "Namespace" übereinstimmen.
Namespace
Dieses erforderliche Attribut gibt den Namespace der SOAP-Header an, deren Vertraulichkeit geschützt werden soll.
Dies ergibt ein Element des Typs <EncryptedHeader>, das das Element <EncryptedData> enthält.

Geben Sie für das Verhalten von Web Services Security Version 1.0 die Eigenschaft "com.ibm.wsspi.wssecurity.encryptedHeader.generate.WSS1.0" mit dem Wert true im Element "EncryptionInfo" in den Bindungen an. Wenn Sie diese Eigenschaft angeben, wird ein Element des Typs <EncryptedData> erstellt.

Wenn sich Web Services Security Version 1.1 wie in den Versionen von WebSphere Application Server vor Version 7.0 verhalten soll, geben Sie die Eigenschaft com.ibm.wsspi.wssecurity.encryptedHeader.generate.WSS1.1.pre.V7 mit dem Wert true im Element <encryptionInfo> der Bindung an. Wenn diese Eigenschaft angegeben wird, enthält das Element <EncryptedHeader> einen Parameter des Typs "wsu:Id", während der "Id"-Parameter im Element <EncryptedData> nicht angegeben ist. Diese Eigenschaft sollte nur dann verwendet werden, wenn keine Konformität mit "Basic Security Profile 1.1" erforderlich ist und Elemente des Typs <EncryptedHeader> an einen Client oder einen Server mit WebSphere Application Server Version 5.1 Feature Pack for Web Services gesendet werden müssen.

Unterstützung von LTPA

Lightweight Third Party Authentication (LTPA) wird als binäres Sicherheitstoken in Web Services Security unterstützt. Web Services Security unterstützt sowohl Token der LTPA Version 1 als auch Token der LTPA Version 2. Das Token der LTPA Version 2, das eine höhere Sicherheit bietet als Version 1, wird in WebSphere Application Server Version 7.0 und höher unterstützt.

Erweiterte Unterstützung für Zeitmarken

Sie können während des Signierprozesses eine Zeitmarke auch in andere Elemente als den WS-Security-Header einfügen. Diese Zeitmarke ist ein Mechanismus für das Hinzufügen eines Zeitlimits zu einem Element. Diese Unterstützung ist eine Erweiterung für WebSphere Application Server. Die Implementierungen anderer Anbieter haben möglicherweise nicht die Möglichkeit, eine Nachricht zu verarbeiten, die mit einer zusätzlich eingefügten Zeitmarke generiert wurde.

Erweiterte Unterstützung für Nonce

Sie können einen Nonce, d. h. einen nach dem Zufallsprinzip generierten Wert, in andere Elemente außer dem Benutzernamenstoken einfügen. Der Nonce wird verwendet, um die Möglichkeit eines Angriffs durch Nachrichtenaufzeichnung und -wiederholung zu verringern. Diese Unterstützung ist eine Erweiterung für WebSphere Application Server. Die Implementierungen anderer Hersteller haben möglicherweise nicht die Möglichkeit, eine Nachricht zu verarbeiten, in denen ein Nonce in anderen Elementen als dem Benutzernamenstoken eingefügt ist.

Unterstützung des verteilten Nonce-Caching

Das verteilte Nonce-Caching ist ein neues Feature für Web-Services in WebSphere Application Server Version 6 und höher, mit dem Sie Nonce-Daten zwischen den Servern in einem Cluster replizieren können. Beispielsweise können in einem Cluster C ein Anwendungsserver A und ein Anwendungsserver B existieren. Wenn Anwendungsserver A einen Nonce mit einem Wert X akzeptiert, dann erzeugt Anwendungsserver die Ausnahme SoapSecurityException, wenn er innerhalb einer angegebenen Zeit den Nonce mit demselben Wert empfängt.

Wichtig: Das Feature für verteiltes Nonce-Caching verwendet den WebSphere Application Server Replication Service (DRS). Die Daten im lokalen Cache werden an die Caches der anderen Servern in derselben Replikationsdomäne gesendet. Die Replikation ist ein Aufruf, der außerhalb des Prozesses stattfindet, und in manchen Fällen ist dies ein ferner Aufruf. Daher ist eine zeitliche Verzögerung bei der Replikation möglich, während der Inhalt des Caches jedes Anwendungsservers im Cluster aktualisiert wird. Diese Verzögerung kann aufgrund des Datenaustausches im Netz, der Netzauslastung oder der Systemauslastung usw. entstehen. Für einen adäquaten Zugriffsschutz muss die geeignete Sicherheit für den DRS-Cache aktiviert werden. Nähere Informationen hierzu finden Sie im Artikel über die Multibroker-Replikationsdomänen.

Zwischenspeicherung des X.509-Zertifikats

WebSphere Application Server speichert die empfangenen X.509-Zertifikate standardmäßig im Cache, um ein Prüfung des Zertifikatspfads zu vermeiden und die Leistung zu verbessern. Diese Änderung kann jedoch ein Sicherheitsrisiko darstellen. Sie können die Zwischenspeicherung des X.509-Zertifikats wie folgt inaktivieren:

Auf der Zellenebene:
  • Klicken Sie auf Sicherheit > Web-Services.
  • Klicken Sie unter "Weitere Eigenschaften" auf Eigenschaften > Neu.
  • Geben Sie im Feld "Eigenschaftsname" com.ibm.ws.wssecurity.config.token.certificate.useCache ein.
  • Geben Sie im Feld "Eigenschaftswert" false ein.
Auf der Serverebene:
  • Klicken Sie auf Server > Anwendungsserver > Servername.
  • Klicken Sie unter "Sicherheit" auf Web-Services: Standardbindungen für Web Services Security.
  • Klicken Sie unter "Weitere Eigenschaften" auf Eigenschaften > Neu.
  • Geben Sie im Feld "Eigenschaftsname" com.ibm.ws.wssecurity.config.token.certificate.useCache ein.
  • Geben Sie im Feld "Eigenschaftswert" false ein.

Unterstützung einer Zertifikatswiderrufsliste

Die Zertifikatswiderrufsliste (Certificate Revocation List, CRL) in WebSphere Application Server wird für eine bessere Validierung des Zertifikatspfads verwendet. Sie können im Zertifikatssammelspeicher eine CRL zur Validierung festlegen. Sie können eine CRL außerdem mit der PKCS#7-Verschlüsselung in einem X.509-Token verschlüsseln. Die X509PKIPathv1-CRL-Verschlüsselung in einem X.509-Token wird von WebSphere Application Server Version 6 und höher jedoch nicht unterstützt.
Wichtig: Die PKCS#7-Verschlüsselung wurde nur mit dem Provider des IBM Zertifikatspfads (IBM CertPath) getestet. Für andere Provider von Zertifikatspfaden wird die Verschlüsselung nicht unterstützt.

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_wssv6enhance
Dateiname:cwbs_wssv6enhance.html