java - sustitucion - Política de firma y encriptación.

encriptar y desencriptar sha1 java

Question

Necesito implementar un cliente jax-ws.

Esto es lo que los documentos del proveedor dicen acerca de la seguridad

Actualmente, utilizamos la especificación SOAP Message Security versión 1.0 en http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Este estándar utiliza otros dos de la norma W3C:
XMLENC ( http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/ )
y XMLDSIG ( http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ )

Para la firma, es obligatorio un "SecurityTokenReference" usando una "referencia" directa que especifique "URI" y "valueType" de X509. Para el cifrado, lo recomendamos también, pero también admitimos, por orden de preferencia, una referencia a un identificador de claves, un X509IssuerSerial o un nombre de clave.

El bloque cifrado y firmado debe ser la etiqueta "cuerpo".

Recomendamos utilizar: "rsa-sha1" para la firma, "rsa-1_5" para la clave de cifrado y "tripledes-cbc" para el cuerpo del cifrado.

Así que se me ocurrió la siguiente política (generada a partir de netbeans). Pero ... no me parece bien. El servicio web aún no está disponible, pero no estoy seguro de que las versiones de las especificaciones coincidan. Leí mucho sobre el tema, pero todavía estoy algo confundido. ¿Esta política se ve bien?

<wsp1:Policy wsu:Id="ListeOperationsPeriodeSoapBindingSoapPolicy">
<wsp1:ExactlyOne>
<wsp1:All>
<sp:TransportBinding>
<wsp1:Policy>
<sp:TransportToken>
<wsp1:Policy>
<sp:HttpsToken RequireClientCertificate="false"/>
</wsp1:Policy>
</sp:TransportToken>
<sp:Layout>
<wsp1:Policy>
<sp:Lax/>
</wsp1:Policy>
</sp:Layout>
<sp:AlgorithmSuite>
<wsp1:Policy>
<sp:TripleDesRsa15/>
</wsp1:Policy>
</sp:AlgorithmSuite>
</wsp1:Policy>
</sp:TransportBinding>
<sp:Wss10/>
<sp:EndorsingSupportingTokens>
<wsp1:Policy>
<sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp1:Policy>
<sp:WssX509V3Token10/>
</wsp1:Policy>
</sp:X509Token>
</wsp1:Policy>
</sp:EndorsingSupportingTokens>
</wsp1:All>
</wsp1:ExactlyOne>
</wsp1:Policy>
<wsp:Policy wsu:Id="ListeOperationsPeriodeSoapBindingSoap_perform_Input_Policy">
<wsp:ExactlyOne>
<wsp:All>
<sp1:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp1:X509Token sp1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp1:WssX509V3Token10/>
</wsp:Policy>
</sp1:X509Token>
</wsp:Policy>
</sp1:SignedEncryptedSupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>

EDITAR: No pude enviar el mensaje esperado con wsit-yet. Como ejemplo, al usar el asistente de Netbeans, no pude obtener un encabezado cifrado sin usar el direccionamiento. ¿Se supone que es posible?

Hacké algo con una vieja clase de eje 1 y wss4j, funciona pero es feo y prefiero usar algo más a prueba de futuro.

Answer 1

Pareces confundido por cierto. En general debes tener una sola política. En su caso, se arriesga a aceptar llamadas de servicio web no seguras porque tiene una política que define el enlace de transporte (https), mientras que la otra no lo es.

Además, como tiene un enlace de transporte, eso significa que todo el cuerpo estará cifrado por el protocolo de transporte (https). No es necesario especificar explícitamente el cifrado del cuerpo. De hecho, este enlace cifrará todo excepto el encabezado http.

El enlace de transporte realmente es la forma más fácil de obtener servicios web seguros. Si desea un control total, debe escribir su propio enlace simétrico o asimétrico según sus necesidades. Asymetric es más complejo porque requiere un certificado en ambos lados, mientras que asymetric requiere solo un certificado de servidor (acepta clientes anónimos). Los enlaces asimétricos y simétricos requieren cuidado. Están diseñados para ser altamente flexibles y le permitirán diseñar cualquier política, incluso si son vulnerables a ciertos ataques.

Cuando no utilice el enlace de transporte, debe especificar que el cuerpo debe estar cifrado. Como se indica en las especificaciones:

sp:EncryptedParts/sp:Body

O traducido a xml:

<sp:EncryptedParts>
<sp:Body/>
</sp:EncryptedParts>

Del mismo modo, si quieres que el cuerpo esté firmado:

<sp:SignedParts>
<sp:Body/>
</sp:SignedParts>

Hay más opciones para especificar el orden de firma / cifrado, ya sea para cifrar la firma o no, etc.

Como su nombre lo indica, las políticas como sp: EndorsingSupportingToken se aplican a los tokens de soporte. El tipo con el que estoy familiarizado es el token de nombre de usuario que puede incluir dentro de las solicitudes de servicios web.

La especificación WS-SecurityPolicy es el documento más útil que he leído para comprender las políticas. Deberías tomarte el tiempo de leer esto a fondo. Detalla las cosas bastante bien y contiene ejemplos útiles. Es bueno leer diferentes versiones de los documentos, ya que algunos aspectos estarán mejor documentados en versiones más recientes. Tenga en cuenta que he vinculado v1.3.

Configure un cliente y servidor de servicios web y escriba pruebas simples. Especialmente si eres nuevo en servicios web.

Una herramienta que le ayudará a formular políticas rápidamente es SoapUI . No apoyaba exactamente lo que necesitaba, pero me ayudó a aprender un par de cosas. Tiene una gran interfaz de usuario y no es muy difícil de usar.

Obtenga algunos ejemplos o genere algunos, luego deconstrúyalos con la ayuda de la especificación.

He encontrado que las políticas son bastante complejas. ¡Prepárate para absorber muchos conceptos!

Answer 2

Tal vez quieres probar con CXF en lugar de WSIT? http://cxf.apache.org/docs/ws-security.html