Unterschiede im WS-Security-Verhalten bei WebSphere Application Server Traditional und Liberty
Die WS-Security-Beschränkungen, die einer Web-Service-Anwendung in Liberty hinzugefügt werden können, können ein anderes Verhalten aufweisen, wenn sie auf einen Service in WebSphere Application Server Traditional angewendet werden.
WS-Security aktivieren und konfigurieren
WS-Security wird in Liberty mit der WS-Security-Richtlinie (WS-SecurityPolicy) in der WSDL-Datei einer Web-Service-Anwendung konfiguriert und durch Hinzufügen des Features wsSecurity-1.1 in der Datei server.xml aktiviert. In WebSphere Application Server Traditional wird WS-Security über einen Richtliniensatz konfiguriert und durch Zuordnung eines Richtliniensatzes aktiviert. Wenn Sie eine Liberty-Web-Service-Anwendung mit aktivierter WS-Security-Implementierung in WebSphere Application Server Traditional implementieren, müssen Sie funktional entsprechende Richtliniensätze und Bindungen erstellen und zuordnen, um dieselbe Ebene an Web-Service-Sicherheit zu erreichen.
WS-Security-Richtlinie
- Namespaces
- Liberty CXF WS-Security unterstützt die folgenden Namespaces der WS-Security-Richtlinie:
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802
- Der folgende Namespace wird mit Einschränkungen ebenfalls unterstützt:
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy
- WS-Security von WebSphere Application Server Traditional unterstützt die folgenden Namespaces der WS-Security-Richtlinie:
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512
- Liberty CXF WS-Security unterstützt die folgenden Namespaces der WS-Security-Richtlinie:
- ZusicherungenLiberty unterstützt in "WS-Security Policy 1.2" eine größere Anzahl von Zusicherungen als WebSphere Application Server Traditional. In WS-Security von WebSphere Application Server Traditional werden einige Richtlinienzusicherungen über XPath oder Bindungen implementiert. Die folgende Liste enthält einige wichtige Unterschiede:
- Unterstützungstoken
Damit ein Unterstützungstoken (SupportingToken) wie z. B. ein Benutzernamenstoken (UsernameToken) in Liberty signiert oder verschlüsselt wird, ist eine Zusicherung des Tokens als SignedSupportingTokens, SignedEncryptedSupportingTokens oder EncryptedSupportingTokens erforderlich. In WebSphere Application Server Traditional müssen Sie einen XPath-Ausdruck verwenden, um ein Unterstützungstoken (SupportingToken) zu signieren oder zu verschlüsseln.
In WebSphere Application Server Traditional wird keines der Bestätigungstoken unterstützt, einschließlich EndorsingSupportingTokens, SignedEndorsingSupportingTokens, EndorsingEncryptedSupportingTokens und SignedEndorsingEncryptedSupportingTokens.
- Sicherheitsbindungszusicherung
Liberty unterstützt die Zusicherungen SymmetricBinding, AsymmetricBinding und TransportBinding. Der traditionelle Server bietet keine Unterstützung für die Zusicherung TransportBinding.
- IncludeToken-Zusicherung
Die IncludeToken-Zusicherung wird in Liberty erzwungen, in der WS-Security-Laufzeitumgebung von WebSphere Application Server Traditional jedoch ignoriert.
- UsernameToken-Zusicherung
Liberty unterstützt in der UsernameToken-Zusicherung PasswordDigest und die Schlüsselableitung. WebSphere Application Server Traditional unterstützt in einem Benutzernamenstoken (UsernameToken) nur PasswordText.
- Unterstützungstoken
Nicht erkannte Elemente in Sicherheitsheadern
- Ein nicht erkanntes Element im Sicherheitsheader wird von WebSphere Application Server Traditional zurückgewiesen, von Liberty jedoch akzeptiert.
Verschlüsselter Header
- Die Spezifikation WS-Security 1.1 empfiehlt, zum Verschlüsseln von SOAP-Headerblöcken das Element <wsse11:EncryptedHeader> zu verwenden.
- Die in Liberty verwendete CXF-WS-Security-Implementierung generiert kein Element des Typs EncryptedHeader. Stattdessen generiert CXF WS-Security ein Element des Typs <xenc:EncryptedData>. Allerdings kann die in Liberty verwendete CXF-WS-Security-Implementierung ein eingehendes Element des Typs <wsse11:EncryptedHeader> verarbeiten und konsumieren, falls mustUnderstand im <security>-Header auf 0 gesetzt ist.
- WebSphere Application Server Traditional setzt mustUnderstand im <security>-Header immer auf 1. Damit Liberty das Element EncryptedHeader erfolgreich verarbeiten kann, müssen Sie mustUnderstand explizit auf 0 setzen, indem Sie die folgende Eigenschaft in der Konfiguration der abgehenden Bindungen festlegen:
<properties name="com.ibm.wsspi.wssecurity.config.request.setMustUnderstand" value="false"/>
Nicht anerkannte Zwischenzertifikate
- Es gibt keine Möglichkeit, nicht anerkannte Zwischenzertifikate festzulegen, damit der Zertifikatspfadvalidator einen Zertifikatspfad vom eingehenden Zertifikat zu einem anerkannten Zertifikat in einem Truststore erstellen kann. Damit das Zertifikat anerkannt wird, muss entweder das eingehende Zertifikat oder aber der direkte Aussteller dieses Zertifikats im Truststore enthalten sein.
Bekannte Probleme
- In der CXF-WS-Security-Implementierung in Liberty gibt es einige bekannte Probleme. Für einige gibt es Problemumgehungen. Informationen zu bekannten Problemen und Problemumgehungen finden Sie unter Bekannte Probleme und Problemumgehungen bei WS-Security
Nicht getestete und nicht unterstützte Features
- Die WS-Security-Implementierung in Liberty umfasst den gesamten WS-Security-Laufzeitumgebungscode aus dem CXF-Projekt. Allerdings wurden nicht alle Funktionen und Features von CXF WS-Security getestet oder geprüft. Eine Liste der Spezifikationen, die nicht geprüft wurden, finden Sie unter Nicht getestete WS-Security-Spezifikationen.