Transformation des assertions de règles et de liaisons pour WSDL

Web Services Security ne prend pas encore entièrement en charge la norme OASIS WS-SecurityPolicy 1.2. Cependant, plusieurs assertions de règles et de liaisons prises en charge par WebSphere Application Server peuvent être transformées et représentées en tant qu'assertions WS-SecurityPolicy 1.2. Les assertions prises en charge sont transformées lorsqu'une demande WSDL (Web Services Description Language) ou WS-MEX (Web Services Metadata) est reçue dans un message et lorsqu'un client reçoit une règle contenant des assertions WS-SecurityPolicy 1.2.

Lorsque WebSphere Application Server reçoit une demande WSDL ou WS-MEX, certaines assertions de règles et de liaisons sont transformées en assertions standard et incluses dans la règle intégrée à WSDL. De plus, lorsque le client reçoit une règle contenant ces assertions WS-SecurityPolicy, il les retransforme en assertions spécifiques au produit, de façon que l'environnement d'exécution WebSphere Application Server puisse les traiter. Cette transformation garantit l'interopérabilité entre WebSphere Application Serveur et d'autres systèmes prenant en charge la norme WS-SecurityPolicy 1.2.

Les assertions WS-SecurityPolicy 1.2 suivantes peuvent être représentées dans la règle renvoyée via WSDL ou via une demande WS-MEX.

EncryptSignature
Assertion représentée dans le produit via des expressions XPath dans des éléments chiffrés.
EncryptBeforeSigning
L'attribut d'ordre des éléments encryptionInfo et signingInfo sur la section sortante des liaisons détermine l'ordre selon lequel la transformation s'effectue et si l'assertion est définie. Par défaut, la signature est effectuée avant le chiffrement.
ContentEncryptedElements
Cette assertion est représentée via des expressions XPath se terminant par /node() dans les éléments chiffrés. WebSphere Application Server peut consommer cette assertion de règle, mais les expressions XPath existantes se terminant par /node() ne sont pas transformées.
KerberosToken
Cette assertion est représentée via le jeton personnalisé dans la règle et les liaisons. L'assertion de jeton personnalisé Kerberos indique un nom local correspondant à http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ ou http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ, selon le type de jeton Kerberos souhaité. De plus, les liaisons comprennent une propriété personnalisée appelée com.ibm.wsspi.wssecurity.krbtoken.requireDerivedKey, qui définit l'utilisation de clés dérivées pour Kerberos. En ayant recours au nom local du jeton personnalisé et à la propriété personnalisée de la clé dérivée fournie par la représentation du produit, vous pouvez créer une représentation version 1.2 équivalente.
Require<variable>Reference, où <variable> est l'un des éléments suivants : KeyIdentifier, IssuerSerial, EmbeddedToken ou Thumbprint
Dans les liaisons, cette assertion est représentée via l'attribut de type dans keyInfo.
MustSupportRef<variable>, où <variable> et l'un des éléments suivants : KeyIdentifier, IssuerSerial, EmbeddedToken ou Thumbprint
Cette assertion n'est pas représentée dans les règles WebSphere Application Server, mais le produit prend en charge l es quatre types de références.
Protection de l'élément SignatureConfirmation
L'élément SignatureConfirmation est signé et chiffré de manière implicite. Cependant, si aucun élément n'est chiffré dans la réponse, l'élément SignatureConfirmation n'est pas chiffré ; si aucun élément n'est signé dans la réponse, l'élément SignatureConfirmation n'est pas signé. Toutes les expressions XPath représentant la signature ou le chiffrement de l'élément SignatureConfirmation sont supprimées de la règle lors de la transformation. L'attribut explicitlyProtectSignatureConfirmation dans la liaison de sécurité des services Web est fourni pour désactiver le chiffrement et la signature implicites de l'élément SignatureConfirmation dans les messages de réponse. Cela permet une interopérabilité avec WebSphere Application Server Version 6.1.x. Pour ajouter cet attribut, cochez l'option Désactiver la protection implicite pour la confirmation de signature correspondant aux liaisons de l'ensemble de règles par défaut, dans le panneau Authentification et protection. Si l'attribut explicitlyProtectSignatureConfirmation est présent dans la liaison, aucune des expressions XPath représentant la signature ou le chiffrement de l'élément SignatureConfirmation n'est modifiée lors de la transformation.
SC13SecurityContextToken
La version 1.3 du jeton du contexte de sécurité est prise en charge via la spécification du nom local http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 dans la liaison correspondant au jeton en question.
RequireImpliedDerivedKeys
Cette assertion est prise en charge via l'ajout d'une propriété personnalisée appelée com.ibm.ws.wssecurity.token.generateImpliedDerivedKey dans les liaisons du générateur de jetons.
ExactlyOne
Cette assertion est transformée lors de l'utilisation d'appelants. Ces derniers identifient le jeton à utiliser pour l'authentification. L'assertion ExactlyOne transmet les jetons des appelants attendus par le service. Toutes les options des appelants sont incluses dans l'assertion <ExactlyOne> ; chacune d'elle est insérée dans une assertion <wsp:All>. Grâce à cette assertion, dont le nom est explicite, le client n'envoie qu'un seul type de jeton. Par exemple, dans les liaisons côté serveur, les options d'appelant suivantes sont indiquées via la représentation du produit :
 <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>
Cette assertion indique qu'un jeton UsernameToken ou LTPA est utilisé en tant qu'appelant. L'obligation d'utiliser l'un de ces deux types de jeton est transmise au client dans la règle transformée (voir ci-après) :
<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>

Les assertions de règles spécifiques au produit appelées LTPAToken et LTPAPropagationToken ne sont pas modifiées lors de la transformation. Si elles apparaissent dans la règle en cours de transformation, elles sont incluses dans la règle imbriquée dans le document WSDL. Cela permet à un client WebSphere Application Server et au fournisseur de services WebSphere Application Server d'interopérer.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_transformassertions
Nom du fichier : cwbs_transformassertions.html