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.
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
- 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
- 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.
- 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.
- Tokengenerator (com.ibm.wsspi.wssecurity.token.TokenGeneratorComponent)
- Tokenkonsument (com.ibm.wsspi.wssecurity.token.TokenConsumerComponent)
- Key-Locator (com.ibm.wsspi.wssecurity.keyinfo.KeyLocator)
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.
- 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.
- 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.
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.
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:
- 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.
- 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.