WCF: compartición de tipos entre referencias a servicios

En una aplicación basada en capas, una situación que se puede dar de forma frecuente es que nuestra capa de servicios exponga dos o más servicios que hacen uso de un mismo tipo. Es decir, por poner un ejemplo simple, en una aplicación WCF, tendríamos dos contratos definidos con [OperationContract] en los que algunos métodos harían uso de un mismo tipo expuesto mediante [DataContract]. En principio, esto no constituye en sí mismo ningún problema, hasta que estemos codificando un cliente que referencie a los dos servicios; en ese caso en el cliente acabaremos teniendo dos referencias a servicio que contienen el mismo tipo. El problema es que aunque nosotros sepamos que es el mismo tipo, en el cliente tenemos dos tipos distintos y no podemos trabajar como si fuesen el mismo, hacer asignaciones de instancias, etc. Esto puede ser un mal menor, o puede suponernos grandes quebraderos de cabeza, dependiendo de cómo tengamos que utilizar esos tipos en el cliente, pero en cualquier caso hace que nuestro modelo en los clientes sea conceptualmente incorrecto y resulte confuso a la hora de utilizarlo desde el código. En este artículo voy a comentar cómo podemos tratar con este problema.


Antes de empezar quisiera destacar que en ocasiones el esfuerzo empleado en evitar la multiplicidad de tipos en las referencias, será mayor que el beneficio obtenido. Si el manejo de los tipos en cliente no es demasiado complejo, seguramente merecerá la pena quedarnos como estamos, que añadir más código y tareas de mantenimiento a nuestro proyecto. Probablemente éste sea el caso si tenemos clientes ligeros que acceden a la lógica de negocio a través de la capa de servicios, pero lo más recomendable es valorar cada caso antes de tomar una decisión.


Unificando los tipos en el cliente: librería de tipos


La forma de evitar la multiplicidad de tipos en las referencias del cliente, es tener en el proyecto del cliente una referencia a una librería que contenga dichos tipos, y configurar la referencia para que utilice dicha librería en lugar de usar los tipos expuestos en el servicio. En un momento hablaré de las alternativas que tenemos para construir esta librería, pero suponiendo que ya dispongamos de ella, sólo nos quedaría añadir una referencia al ensamblado desde nuestro cliente, y a la hora de añadir la referencia a cada servicio, indicar que de reutilicen los tipos presentes en un ensamblado. Para ello se usa la opción que aparece al pulsar el botón “Advanced” en la pantalla de adición de referencia a servicio:


 


referenciaServicio


 referenciaServicioConfig


Como se puede apreciar en la captura de pantalla, estamos indicando que para la referencia al servicio se reutilice el tipo “Person” que está contenido en un ensamblado referenciado por el proyecto. De este modo en el código del proxy no aparecerá la definición de este tipo, y en el código del cliente podremos utilizar un sólo tipo “Person” (el contenido en el ensamblado que tenemos referenciado).


 


Generación de la librería de tipos


Para generar la librería de tipos tenemos principalmente dos alternativas: codificarla manualmente o generarla usando svcutil. En ambos casos se suele partir de unos tipos ya presentes en el modelo de la aplicación, de los cuales vamos a crear una versión distribuible a los clientes.


 


Codificación manual de la librería de tipos: La opción más inmediata consiste en codificar una librería de tipos en la que tengamos los tipos utilizados por los servicios. Esta libréría se podría referenciar tanto en los servicios como en los clientes, teniendo en cuenta que para hacerlo en los servicios tendremos que decorarla con los atributos [DataContract] y [DataMember] en los lugares necesarios. Es necesario hacer algunas puntualizaciones para esta opción:



  • Tenemos que tener presente al codificar los tipos que no deberíamos incluir código correspondiente a nuestra lógica de negocio, ya que la librería va a ser referenciada en los clientes. Es decir, deberíamos ceñirnos al “tenet” de SOA que indica que debemos compartir contratos en lugar de código. Si nuestros tipos originales contienen métodos correspondientes a lógica de negocio, podemos apoyarnos por ejemplo en interfaces y/o en el patrón proxy [GoF] para la codificación de estos tipos destinados a ser distribuidos.

  • Si por lo explicado en el punto precedente, nos vemos obligados a mantener manualmente dos “copias” de parte del código de nuestros tipos, estaremos perjudicando la mantenibilidad del proyecto (por eso es necesario valorar si merece la pena el esfuerzo de solucionar la repetición de tipos en las referencias a servicios). Hay ocasiones en las que no es tan fácil mantener actualizado el tipo distribuible a partir del tipo original, un ejemplo podría ser si los tipos a distribuir están contenidos en un modelo EDM de Entity Framework, el cual ya tiene dificultades de mantenimiento propias (por otra parte además las entidades del EDM ya contendrían los atributos correspondientes a los contratos de datos).

  • Sin embargo, si los tipos originales no contienen demasiada lógica, y los servicios y clientes son desarrollados por un mismo equipo, ésta puede ser una forma muy cómoda de distribuir nuestros tipos y de que en todo momento (a través del control de código fuente) todos los miembros de nuestro equipo tengan la última versión de los contratos de datos, sin necesidad de actualizar las referencias a los servicios.

 


Generación de la librería de tipos usando svcutil: mediante la herramienta svcutil podemos generar fácilmente el código de los tipos, sin necesidad de escribirlo a mano. Para esta opción se aplica por lo tanto todo lo dicho unas líneas más arriba, con algunos matices:



  • En principio no tendremos que preocuparnos de que el código generado no contenga lógica de negocio, ya que svcutil sólo generará lo que tengamos marcado con [DataContract] y [DataMember]

  • La mantenibilidad del proyecto se complica igualmente, aunque en este caso, si cambiamos los tipos originales, en lugar de tocar a mano los tipos distribuibles, los vamos a regenerar con svcutil (lo cual en principio es menos trabajo)

Para que svcutil nos genere el código de los tipos, tenemos que invocarlo con la opción /dconly. Un detalle que hace que esta opción se complique un poco es que /dconly sólo funciona si lo usamos contra los metadatos del servicio, es decir, contra los ficheros .wsdl y .xsd (a pesar de que la ayuda de la herramienta muestra lo contrario en uno de los ejemplos 😉 ). Por esta razón, cada vez que tengamos que actualizar los tipos a distribuir, tendremos que pasar por dos invocaciones a svcutil, una para regenerar los metadatos y otra para obtener el código de los tipos.


Para obtener los metadatos del servicio invocaremos svcutil de la siguiente forma, sustituyendo la uri mostrada por la correspondiente a nuestro servicio:


svcutil /t:metadata http://localhost:8000


Esto generará una serie de ficheros .wsdl y .xsd que podemos utilizar para generar los tipos de la siguiente forma:


svcutil /o:types.cs /dconly *.wsdl *.xsd


En este punto tendremos un fichero types.cs que contendrá los tipos de nuestro servicio marcados con [DataContract], el cual podemos utilizar en los clientes de la forma explicada al comienzo del artículo. Para finalizar incluyo el código de la clase “Person” de ejemplo y el código del fichero types.cs generado por la herramienta. Como podéis comprobar, como es lógico en el tipo generado no se incluye el método isMinor correspondiente a la lógica de nuestro tipo “Person”:


 


Person.cs



   1: [DataContract]
   2: public class Person
   3: {
   4:     [DataMember]
   5:     public string Name { get; set; }
   6:     [DataMember]
   7:     public int Age { get; set; }
   8:  
   9:     protected bool isMinor()
  10:     {
  11:         return (Age < 18);
  12:     }
  13: }

 


types.cs



   1: //——————————————————————————
   2: // <auto-generated>
   3: //     This code was generated by a tool.
   4: //     Runtime Version:2.0.50727.1434
   5: //
   6: //     Changes to this file may cause incorrect behavior and will be lost if
   7: //     the code is regenerated.
   8: // </auto-generated>
   9: //——————————————————————————
  10:  
  11: [assembly: System.Runtime.Serialization.ContractNamespaceAttribute(“http://tempuri.org/”, ClrNamespace=“tempuri.org”)]
  12:  
  13: namespace DemoTypeLibrary
  14: {
  15:     using System.Runtime.Serialization;
  16:     
  17:     
  18:     [System.Diagnostics.DebuggerStepThroughAttribute()]
  19:     [System.CodeDom.Compiler.GeneratedCodeAttribute(“System.Runtime.Serialization”, “3.0.0.0”)]
  20:     [System.Runtime.Serialization.DataContractAttribute(Name=“Person”, Namespace=“http://schemas.datacontract.org/2004/07/DemoTypeLibrary”)]
  21:     public partial class Person : object, System.Runtime.Serialization.IExtensibleDataObject
  22:     {
  23:         
  24:         private System.Runtime.Serialization.ExtensionDataObject extensionDataField;
  25:         
  26:         private int AgeField;
  27:         
  28:         private string NameField;
  29:         
  30:         public System.Runtime.Serialization.ExtensionDataObject ExtensionData
  31:         {
  32:             get
  33:             {
  34:                 return this.extensionDataField;
  35:             }
  36:             set
  37:             {
  38:                 this.extensionDataField = value;
  39:             }
  40:         }
  41:         
  42:         [System.Runtime.Serialization.DataMemberAttribute()]
  43:         public int Age
  44:         {
  45:             get
  46:             {
  47:                 return this.AgeField;
  48:             }
  49:             set
  50:             {
  51:                 this.AgeField = value;
  52:             }
  53:         }
  54:         
  55:         [System.Runtime.Serialization.DataMemberAttribute()]
  56:         public string Name
  57:         {
  58:             get
  59:             {
  60:                 return this.NameField;
  61:             }
  62:             set
  63:             {
  64:                 this.NameField = value;
  65:             }
  66:         }
  67:     }
  68: }
  69: namespace tempuri.org
  70: {
  71:     using System.Runtime.Serialization;
  72:     
  73:     
  74:     [System.Diagnostics.DebuggerStepThroughAttribute()]
  75:     [System.CodeDom.Compiler.GeneratedCodeAttribute(“System.Runtime.Serialization”, “3.0.0.0”)]
  76:     [System.Runtime.Serialization.DataContractAttribute(Name=“greet”, Namespace=“http://tempuri.org/”)]
  77:     public partial class greet : object, System.Runtime.Serialization.IExtensibleDataObject
  78:     {
  79:         
  80:         private System.Runtime.Serialization.ExtensionDataObject extensionDataField;
  81:         
  82:         private DemoTypeLibrary.Person pField;
  83:         
  84:         public System.Runtime.Serialization.ExtensionDataObject ExtensionData
  85:         {
  86:             get
  87:             {
  88:                 return this.extensionDataField;
  89:             }
  90:             set
  91:             {
  92:                 this.extensionDataField = value;
  93:             }
  94:         }
  95:         
  96:         [System.Runtime.Serialization.DataMemberAttribute()]
  97:         public DemoTypeLibrary.Person p
  98:         {
  99:             get
 100:             {
 101:                 return this.pField;
 102:             }
 103:             set
 104:             {
 105:                 this.pField = value;
 106:             }
 107:         }
 108:     }
 109:     
 110:     [System.Diagnostics.DebuggerStepThroughAttribute()]
 111:     [System.CodeDom.Compiler.GeneratedCodeAttribute(“System.Runtime.Serialization”, “3.0.0.0”)]
 112:     [System.Runtime.Serialization.DataContractAttribute(Name=“greetResponse”, Namespace=“http://tempuri.org/”)]
 113:     public partial class greetResponse : object, System.Runtime.Serialization.IExtensibleDataObject
 114:     {
 115:         
 116:         private System.Runtime.Serialization.ExtensionDataObject extensionDataField;
 117:         
 118:         private string greetResultField;
 119:         
 120:         public System.Runtime.Serialization.ExtensionDataObject ExtensionData
 121:         {
 122:             get
 123:             {
 124:                 return this.extensionDataField;
 125:             }
 126:             set
 127:             {
 128:                 this.extensionDataField = value;
 129:             }
 130:         }
 131:         
 132:         [System.Runtime.Serialization.DataMemberAttribute()]
 133:         public string greetResult
 134:         {
 135:             get
 136:             {
 137:                 return this.greetResultField;
 138:             }
 139:             set
 140:             {
 141:                 this.greetResultField = value;
 142:             }
 143:         }
 144:     }
 145: }

 


Un saludo !!!

First post

Bueno, por fin me he decidido… desde que trabajo en Plain Concepts llevaba dándole vueltas al tema de empezar con el blog y creo que ya toca (la verdad es que Rodrigo ha tenido mucho que ver, gracias Rodri por los ánimos). Espero poder postear regularmente y hablar de temas mínimamente interesantes. Haré crossposting a Devjoker (gracias también a Pedro), sitio que os recomiendo si aún no lo conocéis.

Un saludo a todos!!!

WCF: netTcpBinding con seguridad tipo Custom

En una aplicación WCF que vaya a ser desplegada en el entorno de una intranet, el binding más idóneo suele ser netTcpBinding, ya que suele cubrir perfectamente las funcionalidades que se necesitan en aplicaciones de este tipo, manteniendo unas características óptimas en cuanto al protocolo y codificación del mensaje. En este tipo de escenario, no es difícil encontrarse con la necesidad de tener que usar un modelo de seguridad en el que el cliente proporcione las credenciales en forma de un nombre de usuario y contraseña, los cuales se validarán con un método personalizado (Custom) en el servicio; es el caso típico de una aplicación que desarrollemos sin poder asumir que vamos a tener un dominio Windows en el que apoyarnos para realizar la autenticación y autorización. Mientras que es bastante común encontrar muchos ejemplos en los que la seguridad se implementa apoyándose en credenciales tipo Windows, no es así para el escenario que usa las credenciales de usuario y contraseña. Este post intenta recoger los pasos a seguir para ponerlo en marcha usando Visual Studio 2008.


 


Por cierto, si os habéis tenido que meter mínimamente con seguridad en WCF habréis visto que es un campo muy amplio en el que nos podemos encontrar muchos casos distintos. Un recurso muy recomendable es la guía de seguridad de WCF que podéis encontrar en codeplex:


 


http://www.codeplex.com/WCFSecurityGuide


 


Parte de este post se basa en información que podéis encontrar en dicha guía, en concreto la que trata de certificados.


 


Paso 1: Creación e instalación de certificados


Para poder usar credenciales de tipo usuario y contraseña con netTcpBinding, WCF requiere que usemos certificados de modo que las credenciales no viajen en texto plano a través de la red.


Como comentaba antes este paso viene bastante bien recogido en la guía de seguridad de WCF (en concreto en el tercer How-to) por lo que voy a intentar ser breve.


En un entorno de producción normalmente usaremos un certificado emitido por una entidad certificadora reconocida, aunque durante el desarrollo podemos usar certificados de prueba generados por nosotros mismos. Para ello el primer paso consiste en crear un certificado que actúe como nuestra entidad certificadora raíz. En la máquina donde vayamos a alojar el servicio, desde una línea de comandos de Visual Studio 2008 ejecutaremos lo siguiente:


 


makecert -n “CN=MiEntidadCertificadora” -r -sv MiEntidadCertificadora.pvk MiEntidadCertificadora.cer

En el parámetro -n indicaremos el nombre (subject) del certificado. El comando nos pedirá las contraseñas para las claves privada y pública del certificado, y generará dos ficheros, uno con la clave privada (extensión .pvk) y otro con el certificado (extensión .cer).

A continuación tendremos que instalar el certificado generado. Abrimos una consola de administración (Inicio – Ejecutar – mmc) y realizamos los siguientes pasos:

1.   Menú File -> Add/Remove Snap‐in. Click en Add
2.   Seleccionar Certificates y hacer click en Add
3.   Seleccionar la opción de “Computer account”, para que el certificado esté disponible para todos los usuarios, y pulsar Next
4.   Dejar seleccionado “Local computer: (the computer this console is running on)” y pulsar Finish. Cerrar los diálogos que queden abiertos
5.   En el panel de la izquierda, expandir el nodo Certificates (Local Computer) y dentro de él la carpeta “Trusted Root Certification Authorities”
6.   Click derecho sobre la subcarpeta Certificates -> All Tasks -> Import
7.   En la pantalla de “File to Import”, click en Browse y abrir el fichero .cer que habíamos generado
8.   En la pantalla “Certificate Store” dejar seleccionado el valor predeterminado


Si estamos desarrollando el servicio y el cliente en la misma máquina, no tenemos que hacer nada más relacionado con la entidad certificadora raíz. Pero si desarrollamos en máquinas distintas, o estamos haciendo un despliegue a otro entorno, hay que tener en cuenta que esta instalación hay que hacerla tanto en la máquina servidora como en todos los clientes. Si no hacemos la instalación en los clientes, no podremos establecer la comunicación porque no se podrá comprobar la validez del certificado usado contra su entidad certificadora.


 


Una vez que hemos instalado el certificado correspondiente a la entidad certificadora raíz, podemos generar el certificado de prueba que utilizaremos en nuestra aplicación WCF. Nuevamente desde una línea de comandos de Visual Studio 2008, en la carpeta donde tengamos los ficheros generados anteriormente, ejecutaremos:


 


makecert -sk <<Nombre único del  certificado>> -iv MiEntidadCertificadora.pvk -n “CN=<<Nombre de la máquina>>” -ic MiEntidadCertificadora.cer -sr localmachine -ss my -sky exchange -pe

Se nos pedirá la contraseña de la clave privada que habíamos introducido previamente al generar el certificado de la entidad certificadora raíz. Con este comando añadiremos al almacén de certificados de la máquina un certificado que nos servirá para cifrar la comunicación de nuestro servicio. En este caso no necesitamos instalar este certificado en los clientes ya que obtendremos una copia codificada en base64 durante la generación del proxy.

Si ya disponemos de un certificado que no sea de prueba (lo cual sería recomendable para el despliegue en producción), podríamos instalarlo de forma similar a como se ha descrito con la consola de administración, lógicamente sin tener que generar nada con la herramienta makecert.

Paso 2: Codificación y configuración del servicio


En la parte del servicio tenemos que ocuparnos de dos tareas: codificar el método Custom que validará el usuario y contraseña recibido del cliente durante el procesamiento de los mensajes entrantes, y configurar el servicio para que use dicho método para la validación, y para que use el certificado para encriptar la conexión.


 


El método Custom para validar el usuario y contraseña recibidos debe incluirse en una clase que deberá heredar de System.IdentityModel.Selectors.UserNamePasswordValidator. En esta clase deberemos sobreescribir el método Validate con el código que realice nuestra validación; el código del método podría ser similar al siguiente:


 



   1: public class Validador : UserNamePasswordValidator
   2: {
   3:     public override void Validate(string userName, string password)
   4:     {
   5:         // Chequeo de parámetros
   6:         if (string.IsNullOrEmpty(userName))
   7:             throw new ArgumentNullException(“userName”);
   8:         if (string.IsNullOrEmpty(password))
   9:             throw new ArgumentNullException(“password”);
  10:  
  11:         // Validación del usuario
  12:         if (userName != “test” || password != “test”)
  13:             throw new SecurityTokenException(“Usuario o contraseña incorrectos”);
  14:     }
  15: }

 


Aquí introduciríamos nuestro código que validase al usuario contra la base de datos o cualquier otra fuente que necesitemos.


Para configurar el servicio, tendremos que incluir en el fichero de configuración de nuestro host WCF una sección system.Servicemodel similar a la siguiente:


 



   1: <system.serviceModel>
   2:   <services> 
   3:     <service name=”ServicioSeguro.ServicioSeguro”
   4:              behaviorConfiguration=”myServiceBehavior”>
   5:       
   6:       <endpoint
   7:         address=”ServicioSeguro”
   8:         binding=”netTcpBinding”
   9:         contract=”ServicioSeguro.IServicioSeguro”
  10:         bindingConfiguration =”mySecureBinding” />
  11:       
  12:       <endpoint binding=”mexHttpBinding” name=”mex” contract=”IMetadataExchange” />
  13:       
  14:       <host>
  15:         <baseAddresses>
  16:           <add baseAddress=”http://<<Nombre de la máquina>>:8000″/>
  17:           <add baseAddress=”net.tcp://<<Nombre de la máquina>>:9000″/>
  18:         </baseAddresses>
  19:       </host>
  20:     
  21:     </service>
  22:     
  23:   </services>
  24:   
  25:   <behaviors>
  26:     <serviceBehaviors>
  27:       <behavior name=”myServiceBehavior”>
  28:         <serviceMetadata httpGetEnabled=”true”/>
  29:           <serviceCredentials>       
  30:             <serviceCertificate findValue=”<<Nombre de la máquina>>” x509FindType=”FindBySubjectName”
  31:                                 storeLocation=”LocalMachine” storeName=”My” />
  32:  
  33:             <userNameAuthentication userNamePasswordValidationMode=”Custom”
  34:               customUserNamePasswordValidatorType=”ServicioSeguro.Validador, ServicioSeguro” />
  35:           </serviceCredentials>
  36:       </behavior>
  37:     </serviceBehaviors>
  38:   </behaviors>
  39:   
  40:   <bindings>
  41:     <netTcpBinding>
  42:       <binding name=”mySecureBinding”>
  43:         <security mode=”Message”>
  44:           <message clientCredentialType =”UserName”/>
  45:         </security>
  46:       </binding>
  47:     </netTcpBinding>
  48:   </bindings>
  49:   
  50: </system.serviceModel>

En esta sección de configuración podemos ver varios puntos a tener en cuenta:


  • Mediante la sección <bindings>, creamos una configuración personalizada para netTcpBinding llamada mySecureBinding, para usar seguridad a nivel de Mensaje con credenciales usuario/contraseña
  • Mediante la sección <behaviors>, creamos un behavior para el servicio llamado myServiceBehavior, en el que especificamos el certificado a usar mediante el nombre que especificamos al crearlo e instalarlo (el nombre de la máquina en este caso). También especificamos el método que vamos a usar para validar las credenciales. Para esto último usamos su nombre cualificado completo, incluyendo el namespace, y el nombre del ensamblado donde reside

 


En este punto, una vez que alojemos el servicio, los clientes que se quieran comunicar con el mismo deberán encriptar los mensajes con el certificado provisto y proporcionar un nombre de usuario y contraseña válidos para el método Validate que hemos escrito (es decir, que no provoquen una excepción). Si no cumplen estos dos requisitos, no serán capaces de invocar ningún método presente en el contrato expuesto en el endpoint.


 



Paso 3: Codificación y configuración del cliente


En el cliente también tenemos dos tareas a realizar, la configuración del endpoint y el paso de las credenciales desde código.


Una vez que hayamos generado el proxy, ya sea añadiendo la referencia al servicio o usando svcutil, tendremos un fichero de configuración en el cual deberíamos encontrar un endpoint que contendrá el certificado que usa el servicio, codificado en base64:



   1: <identity>
   2:     <certificate encodedValue=”AwAAAAEAAAAUAAAAxulv4/ZbZofsJnYuyA6DhEFiaY4gAAAAAQAAAPsBAAAwggH3MIIBYKADAgECAhAC9BTIJWn5nUCqRXjWceukMA0GCSqGSIb3DQEBBAUAMBUxEzARBgNVBAMTClJvb3RDQVRlc3QwHhcNMDgwNzAyMTY0MDQzWhcNMzkxMjMxMjM1OTU5WjATMREwDwYDVQQDEwhCT1JFQUxJUzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtGczeGy3w/9GIHCJCugMXUcD5fsujI4A0tbbgY30rT11CxdQwCdoUGJgd85TLI2O68pWDd0lF02wKeqT9citfoonQ9pG/18u5liOS1ybfTWTfcolBJIN2v9SY+OzAqjgTRoTo0MTp19voSvKDfp811J0hdy8oEn7uTxal8O013MCAwEAAaNKMEgwRgYDVR0BBD8wPYAQ82rcd0p5Uxb4j1jOR7Q8HqEXMBUxEzARBgNVBAMTClJvb3RDQVRlc3SCEDn3hcXuVdW2RP/yAgaqzKwwDQYJKoZIhvcNAQEEBQADgYEAdnetuVAL2loDZZOi0rFa+BJb2lv+pEAKQG8cRkB65rYcPG2EX8M9D5rZyGi1iKXJ50KYohzS4YJQcMOlJ81iUKXDpd1khWfnspNo+sfGvwOTg3Ls7W2ckrCTEmNmDIbhJCv5JJou0092lmVldbvrgWoL6nVSv1d9XuZc8qJgvXM=” />
   3: </identity>

 


De este modo nuestro canal del lado del cliente será capaz de utilizar este certificado para encriptar los mensajes que envíe al servicio. En este mismo fichero de configuración deberemos añadir un behavior para el cliente que especifique el modo de validación y revocación del certificado. Esto es necesario porque como estamos utilizando un certificado de prueba, necesitaremos que sea validado contra nuestra entidad certificadora raíz y que no se compruebe contra una lista de revocación; al pasar a producción esta configuración la cambiaremos por la correspondiente al certificado definitivo. El código de configuración del behavior sería el siguiente; lógicamente tendremos que indicar en el endpoint que se use dicho behavior mediante el atributo behaviorConfiguration:


 



   1: <behaviors>
   2:   <endpointBehaviors>
   3:     <behavior name=”ClientCertificateBehavior”>
   4:       <clientCredentials>
   5:         <serviceCertificate>
   6:           <authentication
   7:               certificateValidationMode=”PeerOrChainTrust” revocationMode =”NoCheck” />
   8:         </serviceCertificate>
   9:       </clientCredentials>
  10:     </behavior>
  11:   </endpointBehaviors>
  12: </behaviors>

 


Por último, necesitamos pasar las credenciales de usuario y contraseña de modo que el servicio pueda comprobarlas para permitir la comunicación. Esto lo haremos usando el miembro ClientCredentials de la clase proxy que se ha generado al añadir la referencia al servicio o al utilizar svcutil. Por ejemplo, si tenemos una instancia de dicha clase proxy llamada miProxy, incluiríamos el siguiente código antes de comenzar a trabajar con los métodos de dicha clase para comunicarnos con el servicio:


 



   1: miProxy.ClientCredentials.UserName.UserName = “test”;
   2: miProxy.ClientCredentials.UserName.Password = “test”;

Si no ha habido nungún problema en el proceso, con esto podríamos comenzar a utilizar el servicio desde el cliente teniendo la comunicación encriptada a nivel de mensaje, y la forma de autenticar las credenciales que más nos convenga.

Un saludo !!!