Programación y Estrategias de Negocios RSS 2.0
# Tuesday, March 04, 2008

Este post tiene que ver con la forma como se invocan servicios Web usando certificados X.509.  En especial visto como una guía muy básica de resolución de problemas al momento de configurar los clientes.  (Que como ya debe saberse pueden ser aplicaciones de escritorio o Aplicaciones Web).

 

Antecedentes.

La seguridad es un elemento clave en la construcción de servicios web, especialmente cuando estos servicios web se exponen en internet.

Para poder construir servicios web seguros se pueden utilizar diversos métodos de autenticación y certificación de identidad, algunos de ellos incluyen:

 

· Tokens de Seguridad Personalizados

· Tokens de Seguridad del Contexto

· Tiquetes de Kerberos

· Usuario y Contraseña

· y Certificados X.509, que son los que nos interesan hoy.

 

Un certificado X.509 es básicamente una llave de encripción emitida y certificada por una entidad certificadora valida, sin entrar mucho en definiciones que se pueden encontrar mas en detalle en Internet, el certificado es un archivo que me emite una entidad reconocida, y que básicamente es un numero único que me han dado para yo entregar a mis clientes y saber que son ellos los que esta llamando mi servicio.

 

Escenario.

Un cliente me pide invocar un servicio web seguro desde mi propia aplicación web, (por ejemplo para mostrar los valores de un combobox), este cliente me provee un certificado X.509 y me informa la política de encripción, autenticación para este servicio. 

 

Solución.

1. Debo instalar el certificado Digital en la Maquina de desarrollo, en el ambiente de pruebas y en el servidor de Producción, es posible que el cliente me provea con dos direcciones web, una para prueba, otra para desarrollo, eso es independiente del certificado.

2. La instalación del certificado puede realizarse de diversas maneras, una muy fácil es copiar el certificado en una ruta de la maquina donde desea instalarse, luego hacer clic derecho del mouse e seguir el asistente

 

clip_image001

 

La siguiente pregunta del asistente es si desea ubicar el certificado en un almacén determinado o si desea que el asistente lo instale basado en la información del certificado, esta es una de esas típicas preguntas que no se sabe bien que contestar o que significa. El repositorio de certificados esta divido por niveles.

El primer nivel indica si se quiere almacenar el certificado en la maquina local, en el perfil del usuario o en la cuenta del servicio con la que corre el OS.

 

luego viene un segundo nivel que incluye personal, autoridades, entidades certificadoras, directorio activo, entre varias otras, así que lo primero es saber donde colocar el certificado, una buena guía es esta que muestra las ubicaciones por default que se utilizan para buscar los certificados digitales, así, si la aplicación es un web service o una aplicación de escritorio que intenta firmar o encriptar el mensaje va a buscar en el User Personal Store.

 

clip_image002

 

3. Ahora que tengo el servidor instalado debo configurar el webconfig y la política que quiero seguir para este certificado. (hay muchas formas de hacerlo, algunos no usan el web config, sino que crean la política en ejecución, etc. esta es solo una forma de abordar el problema).  En e web config va algo como esto:

 

<!-- WSE 2.0 -->
    <section name="microsoft.web.services2" type="Microsoft.Web.Services2.Configuration.WebServicesConfiguration, Microsoft.Web.Services2, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

En la parte de configuración - </configSections> (ojo, esto en  VS2003, en VS2005 puede variar)

y claro, la sección donde en realidad hago la configuración (en web config)

<microsoft.web.services2>
    <diagnostics>
      <detailedErrors enabled="true" />
      <trace enabled="true" />
      <policyTrace enabled="true"
       input="receivePolicy.webinfo"
       output="sendPolicy.webinfo"/>
    </diagnostics>
    <tokenIssuer>
      <autoIssueSecurityContextToken enabled="true" />
    </tokenIssuer>
    <policy>
      <cache name="policyCache.config" />
    </policy>
    <security>
      <x509 storeLocation="LocalMachine" verifyTrust="false" allowTestRoot="false" allowRevocationUrlRetrieval="true" allowUrlRetrieval="false" />
    </security>
  </microsoft.web.services2>

 

esta es la versión de desarrollo o de pruebas, como puede ver esta habilitado el trace de la política <policyTrace enabled="true"... y se esta generando archivos con información de las peticiones y las respuestas (input="receivePolicy.webinfo" output="sendPolicy.webinfo"). Para que estos archivos se puedan crear, son súper útiles, debe habilitarse la cuenta con la que esta corriendo la aplicación (ASP.NET generalmente) para que escriba en el directorio donde se esta ejecutando.

 

Lo otro importante de este segmento es el nombre de la política, en este caso policyCache.config. lo que se esta diciendo aquí es que en ese archivo config estará la definición completa de la política, pueden haber tantas políticas como se quiera. y claro, la seguridad usando X.509 y diciendo en que almacén esta el certificado (storeLocation),

 

Ahora el archivo de la política es como esto:

 

<?xml version="1.0" encoding="utf-8"?>
<policyDocument xmlns="http://schemas.microsoft.com/wse/2003/06/Policy">
  <mappings xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy">
    <!--The following policy describes the policy requirements for the service: http://algo.asmx .-->
    <endpoint uri="algo.asmx">
      <defaultOperation>
        <request policy="" />
        <response policy="" />
        <fault policy="" />
      </defaultOperation>
    </endpoint>
    <endpoint uri=http://algo.asmx>
      <defaultOperation>
        <request policy="#Encrypt-X.509" />
        <response policy="" />
        <fault policy="" />
      </defaultOperation>
    </endpoint>
    <endpoint uri=http://algo.asmx>
      <defaultOperation>
        <request policy="#Encrypt-X.509" />
        <fault policy="" />
      </defaultOperation>
    </endpoint>
  </mappings>
  <policies xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy" xmlns:wssp="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:wse="http://schemas.microsoft.com/wse/2003/06/Policy" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
    <wsp:Policy wsu:Id="Encrypt-X.509">
        <!--The Confidentiality assertion is used to ensure that the SOAP Body is encrypted.-->
        <wssp:Confidentiality wsp:Usage="wsp:Required">
            <wssp:KeyInfo>
                <!--The SecurityToken element within the KeyInfo element describes which token type must be used for Encryption.-->
          <wssp:SecurityToken>
            <wssp:TokenType>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3</wssp:TokenType>
            <wssp:TokenIssuer>C=US, O="VeriSign, Inc.", OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)05, CN=VeriSign Class 3 Secure Server CA</wssp:TokenIssuer>
            <wssp:Claims>
              <!--By specifying the SubjectName claim, the policy system can look for a certificate with this subject name in the certificate store indicated in the application's configuration, such as LocalMachine or CurrentUser. The WSE X.509 Certificate Tool is useful for finding the correct values for this field.-->             <wssp:SubjectName MatchType="wssp:Exact">C=US, S=Wisconsin, L=Milwaukee, O=CLIENTE Company, OU=IS Technical Services, CN=www.cliente.com</wssp:SubjectName>
              <wssp:X509Extension OID="2.7.34.87" MatchType="wssp:Exact">0GJdsds3UdP3fsdtretterERFE4=</wssp:X509Extension>
            </wssp:Claims>
          </wssp:SecurityToken>
            </wssp:KeyInfo>
            <wssp:MessageParts Dialect="http://schemas.xmlsoap.org/2002/12/wsse#part">wsp:Body()</wssp:MessageParts>
        </wssp:Confidentiality>
    </wsp:Policy>
  </policies>
</policyDocument>

 

Donde he puesto en negrilla los valores que son claves, vienen del certificado y se pueden ubicar usando alguna de las herramientas enumeradas mas adelante.

 

Ya podía verse desde aquí la introducción a los conceptos como endpoint que luego serian aun mas completos en WCF pero eso es otra historia.

 

Herramientas.

Utilidad para ver información de los certificados (con código fuente)

Configurar una consola para gestionar los certificados digitales.

La herramienta de gestión de información de los certificados incluida con WSE*

Referencia

Como Firmar un Mensage usando un certificado X.509

 

Espero que esto le ahorre un par de horas, en resumen, el certificado se instala en una de las ubicaciones de búsqueda por defecto o toca cambiar la configuración en los archivos de config.  Luego se modifica el archivo webconfig y los archivos de políticas con la información que se saca del certificado usando una de las herramientas enumeradas, para poder revisar errores, se habilitan los servicios de trace.

 

Juan Peláez

Arquitecto de Software

 

keywords:  Web Services, WSE, certificados X.509, encriptar, firmar, servicios web, herramientas para configurar certificados digitales, políticas de configuración, certificados digitales. seguridad en servicios web, servicios seguros, identificación de clientes, identidad de clientes.

Tuesday, March 04, 2008 8:10:17 PM (SA Pacific Standard Time, UTC-05:00)  #    Comments [0] - Trackback
Visual Studio | VS2005 | Web Services
# Tuesday, February 12, 2008

Al usar VS2005, una de las cosas con las que se encuentran los usuarios (que vienen de VS2003) es un nuevo modelo de compilación de los proyectos Web. (Web Site Project).   Hay varias diferencias entre un modelo y otro, desde el sitio donde se seleccionan para crear un nuevo proyecto hasta los resultados de compilación. Para muchas cosas esto es muy importante, así que aunque este no es un tema nuevo vuelvo a él para referencia propia y de otros.

En el modelo Web Application:

·          Toda la aplicación se compila en un solo assembly (dll) que queda en la carpeta bin.

·          Todas las referencias, y archivos se relacionan en el archivo del proyecto.

·          Todo el proceso de compilación usa MSBuild así que se puede personalizar lo que pasa antes, durante y después de la compilación.

En el Modelo Web Project:

Se generan muchos dlls que viven en el directorio bin, es un poco complicado saber para que es cada uno y cual es cual.

Para mi entonces la principal diferencia esta relacionada con la compilación, y aquí es donde esto se vuelve importante hoy. (3 años después de VS2005.)

Ahora estoy desarrollando algunos proyectos para Sharepoint 2007, hay muchas opciones pero una interesante es crear una aplicacion asp.net normal, agregar las referencias a Sharepoint y publicarla en el directorio _layouts.

Para hacer esto y que quede bien es obligatorio que el assembly de la aplicación web sea uno solo, es decir que sea un proyecto Web Application. , hay otros escenarios como usar Enterprise services en los que eso del ensamblado único también es importante. Asi que para mucha gente, esto resulto tan importante que se creo una adición para VS2005 que permite volver a tener los proyectos Web Applications.

A continuación algunas fotos de mi maquina de desarrollo (gracias clo J) que permiten ver las diferencias al momento de creación, los resultados de compilación y el deployment resultante en sharepoint.

Cuando se entra a Visual Studio y se selecciona nuevo web site se ve una pantalla como esta:

clip_image001

si se crea una pagina, un botón, una clase, se compila y se publica (Publish) se obtiene algo como esto:

clip_image002

Como pueden ver hay dos dlls, una llamada application Code y Otra llamada App_web_xxxx.dll.

Para tener el soporte para Web Applications se puede ir al sitio de Microsoft y rápidamente instalarlo siguiendo estos pasos:

1. Primero Aplicar este parche y

2. Luego descargar el complemento de aqui.

Luego de instalar esto se siguen teniendo los web projects, pero también esta ahora la opcion de web applications, solo que se encuentran en otro lado como se puede ver aquí:  (new Project, Web…)

clip_image003

Y al agregar la misma página, el mismo botón, la misma clase que en el proyecto anterior, compilar y publicar se obtiene esto:

clip_image004

Como se ve una sola dll con el mismo nombre del proyecto.

Pues bien, esta dll es la que se puede colocar en el carpeta BIN del directorio virtual del sitio sobre el que se esta creando la aplicación en sharepoint.

asi : (En este caso mi aplicación dentro del Sharepoint se llama ProjectServer)

clip_image005 

Y las páginas del compilado si quedan en el directorio layouts:

clip_image006

 

Personalmente me gustan los proyectos que usan webApplications, y hasta el momento no he encontrado ninguna restricción o algo que no pueda hacer, incluso en otro proyecto que usaba Enterprise Services desde una de las clases del Web Site fue perfecto para registrar con facilidad los componentes en la consola de COM+.

 

espero que sea de ayuda.

 

Juan Carlos Peláez

MCTS

Distributed Applications

 

Keywords: VS2005, Sharepoint, Web Application Projects, Web Projects, Sharepoint Applications, Juan Peláez, MCTS Distributed Applications. Build, deploy, Desarrollo para Sharepoint, Consultor en Sharepoint.

 

Tuesday, February 12, 2008 5:12:22 PM (SA Pacific Standard Time, UTC-05:00)  #    Comments [0] - Trackback
.net | Articulos de Desarrollo | Sharepoint | Visual Studio | VS2005
# Wednesday, December 12, 2007

 

Se ha publicado el Preview de Diciembre de Blend 2.  Para descargarlo puede ir a este enlace.

En una revisión rápida para preparar un demo para Microsoft Andino he encontrado dos caracteristicas interesantes:

 

  • La Solución ahora puede manejar multiples proyectos lo que permitirar reconstruir y reusar controles que estaban en proyectos diferentes.
  • Ya se pueden cerrar los diferentes paneles con la acostumbrada x que tanto extrañamos antes.

 

Hay muchas más que se pueden leer en el mismo sitio de la descarga.

 

Un Comentario.

Al crear un nuevo proyecto ya se puede seleccionar el framework que desea usarse para compilar, esto ya estaba en la versión anterior (preview de septiembre), pero solo se habilitaba si se instalaba el framework 3.5. (Lo que por cierto traia muchos dolores de cabeza con proyectos nuevos que se crearan despues de instalar el Framework 3.5). Imagino que es por la misma razón que en esta versión actual todos los proyectos y soluciones que se crean son para VS2008, lo que tiene sentido pero es complicado para todos los que veniamos usando blend, queremos las mejoras de la ultima versión pero aún no estamos en VS2008.

Tambien puede verse como una excusa más para migrar a VS2008. (Otras en un post futuro...)

 

Espero que sea de ayuda

 

Juan Peláez

MCTS.

Miembro de Microsoft Andean Influencer Framework

Miembro de Microsoft Andean Speaker Group.

 

Keywords: VS2008, Blend 2, Juan Peláez., Problemas Proyectos Blend 2 Diciembre VS2005., Por que mi proyecto Blend no abre en VS2005, Visual Studio 2005.

Wednesday, December 12, 2007 5:31:04 PM (SA Pacific Standard Time, UTC-05:00)  #    Comments [0] - Trackback
Blend Expression | Silverlight | Visual Studio | VS2005 | VS2008 | WPF
Contácteme
mail: jpelaez at juanpelaez.com
Archivo
<November 2008>
SunMonTueWedThuFriSat
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456
FeedBurner
Maps
Locations of visitors to this page
Sponsors
Acerca de...

Aviso Legal
Las opiniones expresadas en este sitio representan el punto de vista de Juan Peláez sobre diferentes temas y no representan la posición de Studiocom.com.Inc, Microsoft. o de cualquier otra compañía que haya contratado los servicios de consultoría de Juan Peláez

© Copyright 2008
Juan Carlos Peláez
Sign In

Technorati Profile
Estadísticas
Total Posts: 69
This Year: 40
This Month: 2
This Week: 0
Comments: 10
All Content © 2008, Juan Carlos Peláez
El tema 'Business' para DasBlog fue creado por Christoph De Baene (delarou) y modificado para espa�ol por Juan Peláez
Powered by FeedBurner