Umwandlung von Richtlinien- und Bindungszusicherungen für WSDL
Web Services Security bietet keine vollständige Unterstützung des OASIS-Standards WS-SecurityPolicy Version 1.2. Allerdings können einige von WebSphere Application Server unterstützte Richtlinien- und Bindungszusicherungen umgewandelt und als Zusicherungen von WS-SecurityPolicy Version 1.2 dargestellt werden. Die unterstützten Zusicherungen werden umgewandelt, wenn eine WSDL- (Web Services Description Language) oder WS-MEX-Anforderung (Web Services Metadata Exchange) in einer Nachricht empfangen wird und wenn der Client eine Richtlinie empfängt, die Zusicherungen von WS-SecurityPolicy 1.2 empfängt.
Wenn WebSphere Application Server eine WSDL- oder WS-MEX-Anforderung empfängt, werden einige Richtlinien- und Bindungszusicherungen in Standardzusicherungen umgewandelt und in die Richtlinie eingefügt, die in der WSDL enthalten ist. Wenn der Client eine Richtlinie empfängt, die diese WS-SecurityPolicy-Zusicherungen enthält, werden die Zusicherungen außerdem wieder in produktspezifische Zusicherungen umgewandelt, damit sie in der Laufzeit des Anwendungsservers verarbeitet werden können. Diese Umwandlung ermöglicht Interoperabilität zwischen Application Server und anderen Systemen, die den Standard WS-SecurityPolicy Version 1.2 unterstützen.
Folgende Zusicherungen gemäß WS-SecurityPolicy 1.2 können in der in WSDL oder einer WS-MEX-Anforderung zurückgegebenen Richtlinie dargestellt werden.
- EncryptSignature
- Wird im Produkt mittels XPath-Ausdrücken in den verschlüsselten Elementen dargestellt.
- EncryptBeforeSigning
- Das Attribut für Reihenfolge der Elemente "encryptionInfo" und "signingInfo" im Abschnitt "Abgehend" der Bindungen legt die Reihenfolge fest, in der die Umwandlung stattfindet und gibt an, ob diese Zusicherung festgelegt ist. Standardmäßig wird vor der Verschlüsselung signiert.
- ContentEncryptedElements
- Wird mittels XPath-Ausdrücken in den verschlüsselten Elementen dargestellt, die auf "/node()" enden. Application Server kann diese Richtlinienzusicherung lesen, aber vorhandene XPath-Ausdrücke, die auf "/node()" enden, werden nicht umgewandelt.
- KerberosToken
- Wird unter Verwendung des angepassten Tokens in der Richtlinie und den Bindungen dargestellt. Die angepasste Kerberos-Tokenzusicherung gibt abhängig vom Kerberos-Tokentyp den lokalen Namen "http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ" oder "http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ" an. Außerdem ist in den Bindungen die angepasste Eigenschaft "com.ibm.wsspi.wssecurity.krbtoken.requireDerivedKey" enthalten, die die Verwendung abgeleiteter Schlüssel für Kerberos festlegt. Wenn der lokale Namen des angepassten Tokens zusammen mit der angepassten Eigenschaft für abgeleiteten Schlüssel aus der Produktdarstellung verwendet wird, kann eine äquivalente Darstellung für Version 1.2 erstellt werden.
- Require<Variable>Reference, wobei <Variable> für eines der folgenden Elemente steht: KeyIdentifier, IssuerSerial, EmbeddedToken, Thumbprint
- Wird mit dem Typattribut in keyInfo in den Bindungen dargestellt.
- MustSupportRef<variable>, wobe <Variable> für eines der folgenden Elemente steht: KeyIdentifier, IssuerSerial, EmbeddedToken, Thumbprint
- Diese Zusicherung wird in den Richtlinien von WebSphere Application Server nicht dargestellt, aber das Produkt unterstützt alle vier Referenzarten.
- Schutz des Elements "SignatureConfirmation"
- Das Element SignatureConfirmation wird implizit signiert und verschlüsselt. Wenn die Antwort jedoch nicht verschlüsselt ist, wird das Element "SignatureConfirmation" nicht verschlüsselt, und wenn die Antwort keine Signatur enthält, wird das Element "SignatureConfirmation" nicht signiert. Alle XPath-Ausdrücke zur Darstellung der Signatur oder Verschlüsselung des Elements "SignatureConfirmation" werden während der Umwandlung aus der Richtlinie entfernt. Das Attribut "explicitlyProtectSignatureConfirmation" in der Web-Services-Security-Bindung wird bereitgestellt, um die implizite Signatur und Verschlüsselung des Elements "SignatureConfirmation" in der Antwortnachricht zu inaktivieren. Dies ermöglicht die Interoperabilität mit WebSphere Application Server 6.1.x. Wenn das Attribut hinzugefügt werden soll, aktivieren Sie die Option Impliziten Schutz für Signaturbestätigung inaktivieren in der Anzeige "Authentifizierung und Zugriffsschutz" für die Standardrichtliniensatzbindungen. Wenn das Attribut "explicitlyProtectSignatureConfirmation" in der Bindung vorhanden ist, bleiben alle XPath-Ausdrücke zur Darstellung der Signatur oder Verschlüsselung des Elements "SignatureConfirmation" während der Umwandlung unverändert.
- SC13SecurityContextToken
- Version 1.3 des Sicherheitskontexttokens (Security Context Token) wird unterstützt, wenn sie den lokalen Namen "http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" in der Bindung für das Sicherheitskontexttoken angeben.
- RequireImpliedDerivedKeys
- Dies wird unterstützt, wenn die angepasste Eigenschaft "com.ibm.ws.wssecurity.token.generateImpliedDerivedKey" in die Bindungen des Tokengenerators aufgenommen wird.
- ExactlyOne
- Diese Zusicherung wird umgewandelt, wenn Caller verwendet werden.
Die Callers geben an, welches Token für die Authentifizierung verwendet werden soll.
Die Zusicherung "ExactlyOne" teilt den Caller-Token mit, dass der Service genau einen Tokentyp erwartet.
Alle Caller-Optionen sind in der
Zusicherung <ExactlyOne> enthalten, und jede Option wird in die Zusicherung <wsp:All>
aufgenommen.
Wie der Name angibt, sendet der Client nur einen Tokentyp.
Beispielsweise können in den Bindungen auf der Serverseite unter Verwendung
der Produktdarstellung folgende Caller-Optionen
angegeben werden:
<caller order="1"> <jAASConfig configName="system.wss.caller"/> <callerIdentity uri="" localName="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#UsernameToken"/> </caller> <caller order="2"> <jAASConfig configName="system.wss.caller"/> <callerIdentity localName="LTPA" uri="http://www.ibm.com/websphere/appserver/tokentype/5.0.2" /> </caller>
Diese Zusicherung zeigt, dass ein UsernameToken-Token oder ein LTPA-Token als Caller verwendet wird. Die Bedingung, dass einer dieser beiden Tokentypen verwendet werden muss, wird dem Client wie im folgenden Beispiel in der umgewandelten Richtlinie mitgeteilt:<sp:ExactlyOne> <wsp:All> <sp:SupportingTokens> <wsp:Policy wsu:Id="request:token_auth"> <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <sp:WssUsernameToken10 /> </wsp:Policy> </sp:UsernameToken> </wsp:Policy> </sp:SupportingTokens> </wsp:All> <wsp:All> <sp:SupportingTokens> <wsp:Policy wsu:Id="request:token_auth"> <spe:LTPAToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/AlwaysToRecipient" /> </wsp:Policy> </sp:SupportingTokens> <wsp:All> </sp:ExactlyOne>
Die produktspezifischen Richtlinienzusicherungen LTPAToken und LTPAPropagationToken werden während der Umwandlung nicht geändert. Diese Zusicherungen werden in die in der WSDL integrierte Richtlinie aufgenommen, wenn sie bei der Umwandlung der Richtlinie vorhanden sind. Auf diese Weise können ein Client von WebSphere Application Server und ein Service-Provider von WebSphere Application Server miteinander interagieren.