servicio - Agregar encabezados implícitos SOAP a WSDL

requisitos de los servicios web

Question

Mi pregunta es similar a esto. Cómo pasar el encabezado de soap cuando WSDL no lo define? Pero es diferente.

Para un servicio web que uso, todos los métodos necesitan autenticación que se envía en texto claro dentro de un encabezado SOAP. Sin embargo, mi WSDL no incluye ninguna información de encabezado de soap. Tengo una herramienta de plataforma personalizada que debo usar para generar código del WSDL. Como la información del encabezado no está disponible, no puedo usar la clase generada directamente. No deseo modificar manualmente el código para acomodar el encabezado.

Intenté especificar el encabezado SOAP en el WSDL, pero no pude obtener los espacios de nombres correctos. El WSDL está aquí https://stage.totalcheck.sensis.com.au/service/webservice?wsdl y el encabezado SOAP es el siguiente:

 <soapenv:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>username</wsse:Username>
<wsse:Password>password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>

¿Alguien me puede ayudar? ¡Gracias!

Answer 1

Desde un punto de vista conceptual, WSDL no debe definir encabezados. WSDL es solo para definir los aspectos funcionales de un servicio, como operaciones, mensajes, enlace y puntos finales. Los mensajes y enlaces definen cómo se debe codificar y formatear la carga de los mensajes.

Sin embargo, los encabezados de los mensajes SOAP no pertenecen a la carga útil. Normalmente se usan para configurar propiedades no funcionales de un procesador SOAP. La seguridad es una propiedad no funcional. El aspecto funcional de la carga útil no se ve afectado. Solo se garantiza que la comunicación está asegurada y que la pila de herramientas WS, no la implementación del servicio, debería ocuparse de eso.

Entonces, la pieza faltante ahora es un estándar que permite unir algunos requisitos no funcionales a los servicios WSDL, de modo que los generadores de códigos puedan derivar automáticamente qué encabezados deben enviarse y / o comprenderse para cumplir con la propiedad no funcional como se desea: - sin tener que lidiar manualmente con los campos del encabezado. Este estándar existe y se llama WS-Policy . Una política generalmente contiene un conjunto de alternativas que exponen un conjunto de requisitos que tanto el proveedor como el consumidor deberían poder cumplir. Cuando se supone que dos servicios interactúan entre sí, se toman ambas políticas y se calcula una llamada "política efectiva". Define los requisitos comunes no funcionales. Al usar esta información, el proveedor y el consumidor pueden configurarse para agregar encabezados requeridos, como los encabezados WS-Security. WS-SecurityPolicy también define un conjunto de políticas que se pueden usar. WS-PolicyAttachment define cómo pueden adjuntarse dichas políticas a un WSDL.

Hay generadores de código que pueden tratar con WS-Policies, por ejemplo, Metro o Axis2

Answer 2

Puede agregar información de encabezado de soap a llamadas de método decorando los métodos en la clase de proxy generada desde el wsdl con el atributo SoapHeader.

Por ejemplo, wsdl.exe generará la clase proxy del cliente Reference.cs para la referencia del servicio web cuando "Agregue referencia web". En el enlace mencionado anteriormente https://stage.totalcheck.sensis.com.au/service/webservice?wsdl hay un mensaje suggestAddress que se traducirá a un método en el archivo de código de proxy proxy.cs generado cuando se agrega una web referencia de Visual Studio. De forma predeterminada, cuando se llama a este método, no habrá encabezado en el sobre del jabón. Para agregar un SoapHeader al sobre para esta solicitud, agregue un atributo [SoapHeader ("Security")] a la parte superior del método SuggestAddress en la clase generada de Reference.cs, donde "Security" es una clase que hereda de la clase base SoapHeader.

Ejemplo del Security SoapHeader requerido anteriormente crearía las siguientes clases,

public partial class Security : SoapHeader
{
public UserNameToken UserNameToken { get; set; }
}
public partial class UserNameToken
{
public string UserName { get; set; }
public string Password { get; set; }
}

Luego decoraría el método SuggestAddress en el archivo reference.cs como seguido,

[SoapHeader("Security")]
public suggestAddressesResult suggestAddresses([System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)] addressSearch search) {
object[] results = this.Invoke("suggestAddresses", new object[] {search});
return ((suggestAddressesResult)(results[0]));
}

Esto asegurará que cada sobre creado cuando se invoca el método suggestAddress contiene un encabezado de seguridad que se parece al mencionado anteriormente,

<soapenv:Header>
<wsse:Security>
<wsse:UsernameToken>
<wsse:Username>username</wsse:Username>
<wsse:Password>password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>

Answer 3

Para mí, clave en el uso de esta pregunta para ayudarme a mí mismo fue reconocer (como algunos señalaron) que los encabezados en cuestión son los del estándar WS-Security.

Si su herramienta de generación de proxy es "personalizada", parece lógico que pueda tener un interruptor para agregar automáticamente los encabezados de WS-Security. Sin embargo, si está utilizando WSDL.exe ("Agregar referencia web" en Visual Studio), considere svcutil.exe en svcutil.exe lugar ("Agregar referencia de servicio").

Si usa un proxy WCF, puede anular la configuración dada y permitir que WCF agregue los encabezados por usted:

<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>

Desde allí puede especificar la contraseña:

RemoteSvcProxy.TheirClient client = new RemoteSvcProxy.TheirClient();
client.ClientCredentials.UserName.UserName = "uname";
client.ClientCredentials.UserName.Password = "pwd";

No sé cuál es tu herramienta personalizada, pero quizás el marco en el que se basa también tenga opciones de configuración similares.