Política para firmar y cifrar

Question

Necesito implementar un cliente jax-ws.

Esto es lo que la documentación del proveedor dicen acerca de la seguridad

Actualmente, se utiliza la versión de la especificación de SOAP Message Security 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, una "Referencia de SecurityToken" usando una "referencia" directa que especifica "URI" y "valueType" de X509 es obligatoria. Para el cifrado, también lo recomendamos, pero también admitimos en orden de preferencia una referencia a un keyIdentifier, un X509IssuerSerial o un keyName.

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

Recomendamos utilizar: "rsa-sha1" para la firma, "rsa-1_5" para clave de encriptación y "tripledes-cbc" para encriptar el cuerpo.

Así que se me ocurrió la siguiente política (generada a partir de netbeans). Pero ... no me parece correcto. Todavía no se puede acceder al servicio web, pero no estoy seguro de que coincidan las versiones de las especificaciones. Leo 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> 

EDIT: no podía conseguirlo para enviar el mensaje esperado con wsit-todavía. Como ejemplo, al usar el asistente de Netbeans, no pude obtener un encabezado cifrado sin usar el direccionamiento. Se supone que es posible?

He pirateado algo con una antigua clase axis 1 y wss4j, funciona pero es feo y prefiero usar algo más a prueba de futuro.

Answer 1

¿Quizás quieras probar con CXF en lugar de WSIT? http://cxf.apache.org/docs/ws-security.html

Answer 2

Parece confuso. En general, debe tener una sola política. En su caso, corre el riesgo de aceptar llamadas no seguras del servicio web porque tiene una política que define el enlace de transporte (https), mientras que la otra no lo es.

Además, dado que tiene un enlace de transporte, eso significa que todo el cuerpo será encriptado por el protocolo de transporte (https). No es necesario especificar el cifrado del cuerpo de forma explícita. 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 propia encuadernación simétrica o asimétrica según sus necesidades. Asymetric es más complejo porque requiere un certificado en ambos lados, mientras que el asimétrico solo requiere un certificado de servidor (acepta clientes anónimos). Las uniones asimétricas y simétricas requieren cuidado. Están diseñados para ser altamente flexibles y le permitirán diseñar cualquier política, incluso si es vulnerable a ciertos ataques.

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

sp:EncryptedParts/sp:Body 

O traducido a XML:

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

Del mismo modo, si desea que el cuerpo para ser firmado:

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

hay más opciones para especificar la firma/orden de cifrado, ya sea para encriptar la firma o no, etc.

Como su nombre lo indica, policie s como sp: EndorsingSupportingToken se aplica a los tokens de apoyo. El tipo con el que estoy familiarizado es el token de nombre de usuario que puede incluir dentro de las solicitudes de servicios web.

El WS-SecurityPolicy specification es el documento más útil que he leído para comprender las políticas. Debe tomarse un tiempo para 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.

Configura un cliente y servidor de servicio web y escribe pruebas sencillas. Especialmente si es nuevo en los servicios web.

Una herramienta que lo ayudará a formular políticas rápidamente es SoapUI. No era compatible exactamente con 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 compile algunos, luego desconéctelos con la ayuda de la especificación.

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