Transformación de las aserciones de enlace y política para WSDL

La seguridad de servicios web no tiene soporte completo para el estándar OASIS WS-SecurityPolicy versión 1.2. No obstante, algunas aserciones de enlaces y políticas con soporte en WebSphere Application Server se pueden transformar y representar como aserciones de WS-SecurityPolicy versión 1.2. Las aserciones con soporte se transforman cuando en un mensaje se recibe una petición de Web Services Description Language (WSDL) o Web Services Metadata (WS-MEX), y también cuando el cliente recibe una política que contiene aserciones WS-SecurityPolicy 1.2.

Cuando WebSphere Application Server recibe una petición WSDL o WS-MEX, algunas aserciones de enlaces y política se transforman en aserciones estándar y se incluyen en la política que está incluida en el lenguaje WSDL. Además, cuando el cliente recibe una política que contiene esas aserciones WS-SecurityPolicy, las aserciones se vuelven a transformar en aserciones específicas del producto, de forma que el tiempo de ejecución del servidor de aplicaciones las puede procesar. Esta transformación proporciona interoperatividad entre el servidor de aplicaciones y otros sistemas con soporte para WS-SecurityPolicy versión 1.2.

Las aserciones WS-SecurityPolicy 1.2 siguientes se pueden representar en la política devuelta en una petición WSDL o WS-MEX.

EncryptSignature
Se representa en el producto utilizando expresiones XPath en los elementos cifrados.
EncryptBeforeSigning
El atributo de orden de los elementos encryptionInfo y signingInfo en la sección de salida de los enlaces determina el orden en el que tiene lugar la transformación, y si esta aserción se establece. El comportamiento por omisión es firmar antes de cifrar.
ContentEncryptedElements
Se representa utilizando expresiones XPath que terminan con /node() en los elementos cifrados. El servidor de aplicaciones puede consumir esta aserción de política, pero las expresiones XPath que terminan en /node() no se transforman.
KerberosToken
Se representa utilizando la señal personalizada en la política y enlaces. La aserción de señal personalizada de Kerberos especifica un nombre local de http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#GSS_Kerberosv5_AP_REQ, o http://docs.oasis-open.org/wss/oasis-wss-kerberos-token-profile-1.1#Kerberosv5_AP_REQ, según el tipo de señal Kerberos deseado. Además, hay una propiedad personalizada en los enlaces, com.ibm.wsspi.wssecurity.krbtoken.requireDerivedKey, que especifica el uso de claves derivadas para Kerberos. Mediante el uso del nombre local de la señal personalizada, junto con la propiedad personalizada de clave derivada desde la representación del producto, se puede crear una representación equivalente de la versión 1.2.
Require<variable>Reference, donde <variable> es una de las siguientes: KeyIdentifier, IssuerSerial, EmbeddedToken o Thumbprint
Se representa utilizando el atributo de tipo keyInfo en los enlaces.
MustSupportRef<variable>, donde <variable> es una de las siguientes: KeyIdentifier, IssuerSerial, EmbeddedToken o Thumbprint
Esta aserción no se representa en las políticas de WebSphere Application Server, pero el producto tiene soporte para los cuatro tipos de referencia.
Protección del elemento SignatureConfirmation
El elemento SignatureConfirmation está implícita firmado y cifrado. No obstante, si no se cifra nada en la respuesta, el elemento SignatureConfirmation no se cifra, y si no firma nada en la respuesta, el elemento SignatureConfirmation no está firmado. Todas las expresiones XPath que representan la firma o cifrado del elemento SignatureConfirmation se eliminan de la política durante la transformación. El atributo explicitlyProtectSignatureConfirmation en los enlaces de seguridad de servicios web se proporciona para inhabilitar la firma y cifrado implícitos del elemento SignatureConfirmation en el mensaje de respuesta. Esto permite la interoperatividad con WebSphere Application Server Version 6.1.x. Para añadir el atributo, marque la opción Inhabilitar protección implícita para la confirmación de firma en el panel Autenticación y protección para los enlaces del conjunto de políticas por omisión. Si el atributo explicitlyProtectSignatureConfirmation está presente en el enlace, todas las expresiones XPath que representan el firmado o cifrado del elemento SignatureConfirmation permanecen inalteradas durante la transformación.
SC13SecurityContextToken
La 1.3 de la Señal de contexto de seguridad tiene soporte mediante la especificación del nombre local http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512, en el enlace para la señal de contexto de seguridad.
RequireImpliedDerivedKeys
Tiene soporte mediante la adición de la propiedad personalizado com.ibm.ws.wssecurity.token.generateImpliedDerivedKey, en los enlaces del generador de señales.
ExactlyOne
Esta aserción se transforma cuando se utilizan llamadores. Los llamadores especifican la señal a utilizar para autenticación. La aserción ExactlyOne comunica las señales de llamador que el servicio espera. Todas las opciones de llamador van dentro de la aserción <ExactlyOne> y cada opción va dentro de la aserción <wsp:All>. Como el nombre indica, el cliente sólo envía uno de los tipos de señal. Por ejemplo, en los enlaces en la parte del servidor, utilizando la presentación del producto, se especifican las opciones de llamador siguientes:
 <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>
Esta aserción indica que la señal UsernameToken o la señal LTPA se utiliza como llamador. El requisito de utilizar uno de estos dos tipos de señales se comunica al cliente en la política transformada, como en el ejemplo siguiente:
<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>

Las aserciones de políticas específicas del producto, LTPAToken y LTPAPropagationToken, no se alteran durante la transformación. Estas aserciones se incorporarán en la política incluida en WSDL si están presentes en la política que se está transformando. Esto permite que un cliente de WebSphere Application Server y un proveedor de servicios de WebSphere Application Server interoperen.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_transformassertions
File name: cwbs_transformassertions.html