Bekannte Probleme und Problemumgehungen bei WS-Security
Folgende Probleme können in der WS-Security-Implementierung im Open-Source-Services-Framework von Apache CXF auftreten.
- Wenn das SupportingToken verschlüsselt ist, obwohl Sie keine Angaben verschlüsseln möchten, versuchen Sie, alle Tokenzusicherungen, die im Zusammenhang mit der Verschlüsselung stehen, zu entfernen, um das Problem zu beheben. Wenn eine asymmetrische Bindung (AsymmetricBinding) mit SupportingToken-Zusicherung keine verschlüsselten Teile (EncryptedParts) und keine verschlüsselten Elemente (EncryptedElements) enthält, wurde das Unterstützungstoken (SupportingToken) unerwartet verschlüsselt.
- XML-Signatur mit Enveloped Signature Transformation funktioniert nicht. Es gibt keine Problemumgehung.
- Obwohl die Richtlinienreferenz (PolicyReference) in <wsdl:output> berücksichtigt wird, wird PolicyReference in <wsdl:input> ignoriert. Wenn bei der Richtlinienreferenz (PolicyReference) zwischen Eingang und Ausgang unterschieden werden muss, können Sie als Problemumgehung PolicyReference auf der Bindungsebene zuordnen, und anschließend PolicyReference in <wsdl:output> überschreiben.
- Die Richtlinienzusicherung sp:requireEmbeddedTokenReference wird nicht unterstützt.
- Wenn die Eigenschaften org.apache.ws.security.crypto.merlin.truststore.* im Element signatureProperties und die Eigenschaften org.apache.ws.security.crypto.merlin.keystore.* im Element encrytpionProperties im Abschnitt wsSecurityProvider oder wsSecurityClient der Datei server.xml vorhanden sind, überschreiben die Werte von org.apache.ws.security.crypto.merlin.keystore.* im Element encrytpionProperties die Eigenschaften org.apache.ws.security.crypto.merlin.truststore.* im Element signatureProperties. Dieses Verhalten hat zur Folge, dass Ihr Keystore für Chiffrierschlüssel als Signaturtruststore verwendet wird. Als Problemumgehung können Sie sowohl für den Verschlüsselungstruststore als auch für den Signaturtruststore denselben Keystore verwenden. Es ist nicht möglich, getrennte Keystores zu verwenden.
- Die Tokentypen X509PKIPathv1 und PKCS#7 werden nicht unterstützt.
- In der WS-Security-Richtlinie werden Zusicherungen des Typs Require* in der X509Token-Zusicherung nur beim Generieren eines X509-Tokens verwendet. Beim Konsumieren eines X509-Tokens werden sie nicht durchgesetzt. Diese Zusicherungen beinhalten unter anderem RequireKeyIdentifierReference, RequireIssuerSerialReference und RequireThumbprintReference.
- in der Zusicherung SymmetricBinding kann weder die Zusicherung SignatureToken noch die Zusicherung EncryptionToken angegeben werden. Die einzige unterstützte Zusicherung, die in einer SymmetricBinding-Zusicherung verwendet werden kann, ist die Zusicherung ProtectionToken. Das angegebene Schutztoken (ProtectionToken) wird sowohl für die Signatur als auch für die Verschlüsselung verwendet.
- Die Zusicherung ProtectTokens in der WS-Security-Richtlinie wird nicht unterstützt und wird ignoriert.
- Die Zusicherung KeyValueToken in der WS-Security-Richtlinie wird nicht unterstützt.
- X509Token innerhalb von EndorsingEncryptedSupportingTokens oder SignedEndorsingEncryptedSupportingTokens wird nicht unterstützt.
- WS-Security in Liberty unterstützt die Spezifikation der Version 1.1, die kompatibel ist mit der Spezifikation der früheren Version, Version 1.0. Dies bedeutet, dass URIs und Schema-Elemente, die in 1.0 definiert wurden, unverändert bleiben, während
neue Schema-Elemente und Konstanten mit Namespaces und URIs der Version
1.1 definiert werden.
WS-Security-Optionen und -Eigenschaften in der WS-Security-Richtlinie sind mit der wss10-Zusicherung oder der wss11-Zusicherung definiert. Wenn Sie die Richtlinie für die Unterstützung der Eigenschaften von WS-Security 1.1 konfigurieren müssen, dann müssen Sie nur die wss11-Richtlinienzusicherung konfigurieren, die bereits die wss10-Zusicherung enthält. Es ist nicht erforderlich, sowohl die wss11- als auch die wss10-Richtlinienzusicherung zu konfigurieren.
Beispiele für wss11-Richtlinienzusicherungen, die die wss10-Zusicherung enthalten, sind unter anderem RequireSignatureConfirmation, MustSupportRefKeyIdentifier und MustSupportRefIssuerSerial.
- WS-Security und MTOM können derzeit nicht zusammen für denselben Service konfiguriert werden. Wenn MTOM verwendet wird und WS-Security ebenfalls konfiguriert ist, wird die SOAP-Nachricht nicht ordnungsgemäß gesendet. Der Benutzer muss sich zwischen der Verwendung von MTOM und der Konfiguration von WS-Security entscheiden. Muss MTOM verwendet werden, müssen Sie die WS-Security-Richtlinie aus der WSDL-Datei entfernen, um WS-Security zu inaktivieren.
- Wenn Sie einen Liberty-Client und einen WebSphere Application Server Traditional-Provider verwenden und vom Provider die Antwort CWWSS6001E: Das Schlüsselobjekt wurde nicht abgerufen. empfangen, kann dieses Problem möglicherweise mit dem APAR PM88011 von WebSphere Application Server Traditional behoben werden. Dieses Problem steht speziell mit Konfigurationen im Zusammenhang, die sowohl die asymmetrische digitale Signatur als auch die Verschlüsselung des Hauptteils (Body) umfassen.