Usar WS-Trust para la transformación token

Cómo usar WS-Trust para solicitar tokens de seguridad al transformar los formatos token

WS-Trust proporciona una forma estándar para enviar los pedidos de tokens de seguridad a Security Token Service (STS). Esta especificación se puede utilizar para administrar la transformación de los tokens al cruzar los diferentes límites de la seguridad del sistema de la información. Este artículo presenta los conceptos de WS-trust y su uso básico para administrar el intercambio de tokens

Laurent Chades, Senior Certified IT Architect, IBM

Laurent Chades photoLaurent Chades es un Senior Certified IT Architect de IBM Global Business Services en Francia. Está a cargo del diseño de las soluciones SOA y presta su servicio como líder técnico en grandes proyectos. También actúa como consultor, ayudando a los clientes a apalancar las tecnologías y los conceptos de SOA y a definir sus procesos de gobernabilidad. Laurent tiene más de 8 años de experiencia en la industria de IT y ha estado trabajando en el diseño y en la entrega de las soluciones SOA desde el año 2003.



11-05-2010

Introducción al WS-Trust

El consumo de los servicos a través de un sistema de información con frecuencia requiere utilizar formatos token de seguridad. Los proveedores de servicios y los consumidores están repartidos en diferentes dominios de seguridad utilizando diferentes tipos de token o diferentes tecnologías de implementación que no dan soporte a un conjunto común de formatos token. Utilizar WS-Security para transmitir la información de autenticación de los usuarios no es suficiente para garantizar la interoperabilidad de la autenticación entre los consumidores y los proveedores. Aquí es donde el uso de WS-Trust puede ayudar a apalancar los mecanismos transparentes del consumidor para llevar a cabo la transformación de token con Security Token Service (STS).

WS-Trust describe una estructura destinada a administrar, establecer y evaluar las relaciones de confianza para activar los servicios de la Web a fin de interoperar con seguridad. Esta estructura es independiente de los protocolos de seguridad utilizados.

Security Token Service (STS) es un componente estándar de una arquitectura de seguridad que permite operaciones como:

  • La autenticación
  • La autorización
  • La validación de la identidad
  • La correlación de la identidad
  • El intercambio cambio de tokens de seguridad

Como se muestra en la figura 1, WS-Trust presenta tres partes. STS es el elemento central porque emite tokens en los que los proveedores de servicios confían (o confían en STS para validar los tokens).

Figura 1. Modelo de seguridad WS-Trust
WS-Trust Modelo de serguridad

Solicitar un token de seguridad

WS-Trust define los escenarios múltiples. En este artículo, nos centraremos en la solicitud de token y en el escenario de la emisión. WS-Trust 1.3 define la Solicitud de Token Request como se indica en la Figura 2.

Figura 2. Solicitud de Token de WS-Trust
WS-Trust Solicitud Token

WS-Trust se basa en WS-Security para transmitir la identidad del solicitante.

La solicitud contiene un campo obligatorio que especifica el tipo de pedido. Para una solicitud de token, el valor es http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue.

El El campo TokenType es opcional y permite especificar el formato deseado del token devuelto. Los valores posibles de este campo están detallados en los diferentes perfiles de token de WS-Security (Username Token Profile, X509 token Profile, y así sucesivamene). Por ejemplo:

  • Nombre del usuario de Token: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-secext-1.0.xsd/UsernameToken
  • SAML V2.0 assertion: urn:oasis:names:tc:SAML:2.0:assertion

El campo AppliesTo es opcional y le permite al solicitante especificar la terminal a la cual el token será devuelto. En algunos casos STS está configurado para saber qué tipo de token debe ser devuelto a una terminal específica.

Si el campoAppliesTo y los campos TokenType están presentes en la solicitud, la prioridad es la del campo AppliesTo es decir, STS sabe que "endpoint" utiliza un tipo de token distinto al especificado en el campoTokenType éste ignora el campoTokenType y devuelve el token que es usado por endpoint. Éste supone que STS es la única parte que sabe qué tipo de token les da soporte a las endpoints de los proveedores. La ventaja de este mecanismo es que cada consumidor no tiene que mantener toda la lista completa de tokens y endpoints soportados.

El campoOnBehalfOf le permite al solicitante especificar que la solicitud es enviada en nombre de otra de las partes. En este caso, este campo contiene la autenticación de token de la otra parte.


Devolver un token de seguridad

STS devuelve un Request Token Response, cómo se puede ver en la Figura 3, encapsulando el token solicitado. En realidad la respuesta contiene una colección de tokens, porque WS-Trust utiliza el mismo mensaje sin importar la cantidad de tokens solicitados.

El mensaje de la respuesta también contiene los datos relacionados con el token generado. Al utilizar los campos opcionales de WS-Trust en el mensaje de respuesta, STS puede comunicar las propiedades del token generado, incluso si el solicitante no pudiera interpretar la información encapsulada en el token mismo. Por ejemplo, usted puede proporcionar la fecha de emisión del del token y su vida útil.

Figura 3. WS-Trust Request Token Response
WS-Trust Request Respuesta Token

Consideranciones arquitectónicas

Como se describe en la figura 4, las aplicaciones compuestas con frecuencia necesitan consumir servicios prestados por otras apliciones fuera de su propio sistema (o dominio de seguridad). En ese caso, cada aplicación necesita saber qué tipo de token es soportado por cada proveedor.

Figura 4. Arquitectura de base
Arquitectura de base

Esto plantea varias cuestiones:

  • Un gateway debe saber qué tipo de token requiere cada sistema.
  • La configuración debe ser repetida por cada gateway.
  • Cualquier cambio en un sistema debe ser configurado varias veces.
  • Algunos gateways no pueden dar soporte al tipo de token requerido por el proveedor.
  • Algunos formatos de token requerirán un intercambio específico con un proveedor de identidad o de token que el gateway deberá manejar.

El uso de STS para administrar la configuración de los diferentes tokens de seguridad soportados por los proveedores otorga las siguientes ventajas:

  • La configuración es centralizda y más fácil de mantener.
  • Los gateways simplemente solicitan un token para un servicio endpoint, la generación del token es transparente, sin importar si el gateway da soporte a ese tipo de token o no.

Uso de Security Token Service para consumir servicios en otro dominio

Centrémonos en un escenario base, ver la Figura 5, en el que un usuario comprueba en una aplicación compuesta que necesita consumir un servicio provisto por otro sistema ubicado en otro dominio.

La aplicación utiliza ESB basándose en un gateway del servicio de la Web para contactarse con el proveedor de servicios externos. El gateway es responsable de administrar la complejidad de la interacción con un proveedor externo. Desde el punto de vista del consumidor del servicio, todo el proceso relacionado con la comunicación externa es transparente, es decir, el servicio es consumido como cualquier otro servicio provisto en el dominio local al nivel de ESB (especialmente relacionado con el tipo de token de seguridad utilizado inicialmente.)

Figura 5. Escenario base para el consumo de servicios externos
Escenario de base para consumir servicios externos

En nuestro simple ejemplo, para las comunicaciones internas el dominio del consumidor del servicio se basa en un token de nombre de usuario simple, con acreditación de ID y sin password. El cosumidor del servicio envía un pedido parecido al Listado 1. 1.

Listado 1. Solicitud de servicios de base
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header>
      <To xmlns="http://www.w3.org/2005/08/addressing">
        http://testHost/HelloService
      </To>
      <Action xmlns="http://www.w3.org/2005/08/addressing">
        http://testHost/HelloService/hello
      </Action>
      <wsse:Security xmlns:wsse="http://.../oasis-200401-wss-wssecurity-secext-1.0.xsd"
        soapenv:mustUnderstand="1">
        <wsse:UsernameToken>
          <wsse:Username>jdoe</wsse:Username>
        </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
    …
  </soapenv:Body>
</soapenv:Envelope>

Al recibir esta solicitud, ESB se basa en el gateway para manejar las comunicaciones externas. Como la solicitud debe ser enviada en un dominio que puede requerir un tipo diferente de token al utizado internamente en el dominio del consumidor, el ateway tiene que ejecutar un cambio de token antes de enviar el pedido al proveedor. WS-Trust es utilizado para enviar una solicitud de token a Security Token Service.

hay dos cosas que observar aquí:

  • Se debe establecer una relación de confianza entre el gateway y STS. Volver a un token implica que STS confíe en que el sistema solicitante convalide a los usuarios; éste es una aspecto relacionado con la organización. Se debe apalancar algún método para garantizar que el pedido de token sea hecho por el sistema solicitante.
  • Las identidades deben ser difundidas por todo el sistema de información (ya sea utilizando el mismo almacén de usuario o sincronizando los almacenes de los usuarios de distintos sistemas). WS-Trust no controla la federación.

Establecer la confianza entre el gateway y STS se puede lograr firmando la solicitud de token y utilizando la clave privada del gateway.

El listado 2 contiene una solicitud correspondiente a la muestra de la solicitud de token. Usted puede ver el token binario del gateway y la firma de la solicitud. Observe que el campoOnBehalfOf contiene la seguridad de token enviada por el consumidor.

Listado 2. Muestra de Request Token Request
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope" 
   xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd"
   xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:wsse="http://.../oasis-200401-wss-wssecurity-secext-1.0.xsd">
  <S:Header>
    <wsse:Security S:mustUnderstand="1">
      <wsse:BinarySecurityToken wsu:Id="SecurityToken-id"
    EncodingType="http://.../oasis-200401-wss-soap-message-security-1.0#Base64Binary"
    ValueType="http://.../oasis-200401-wss-x509-token-profile-1.0#X509v3">
       Gateway X509 Certificate
       </wsse:BinarySecurityToken>
      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
        <SignedInfo>
          …
        </SignedInfo>
        <SignatureValue>
          …
        </SignatureValue>
        <KeyInfo>
          <wsse:SecurityTokenReference>
            <wsse:Reference URI="#SecurityToken-id"
        ValueType="http://.../oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
          </wsse:SecurityTokenReference>
        </KeyInfo>
      </Signature>
      …
    </wsse:Security>
  </S:Header>
  <S:Body>
    <RequestSecurityToken xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512"
     xmlns:wsa="http://www.w3.org/2005/08/addressing"
     xmlns:pol="http://schemas.xmlsoap.org/ws/2004/09/policy">
      <RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</RequestType>
      <pol:AppliesTo>
        <wsa:EndpointReference>
          <wsa:Address>http://testHost/HelloService</wsa:Address>
        </wsa:EndpointReference>
      </pol:AppliesTo>
      <OnBehalfOf>
        <wsse:UsernameToken 
        xmlns:wsse="http://.../oasis-200401-wss-wssecurity-secext-1.0.xsd"> 
          <wsse:Username>jdoe</wsse:Username>
        </wsse:UsernameToken>
      </OnBehalfOf>
      <TokenType>urn:oasis:names:tc:SAML:2.0:assertion</TokenType>
    </RequestSecurityToken>
  </S:Body>
</S:Envelope>

En nuestro ejemplo, STS responde con una afirmación SAML V2 integrada como se puede ver en el Listado 3.

Listado 3. Respuesta del Token de Solicitud
<S:Envelope xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd"
   xmlns:S="http://www.w3.org/2003/05/soap-envelope">
  <S:Header>
    <wsse:Security xmlns:wsse11="http://.../oasis-wss-wssecurity-secext-1.1.xsd"
     xmlns:wsse="http://.../oasis-200401-wss-wssecurity-secext-1.0.xsd"
     S:mustUnderstand="1">
      <wsu:Timestamp>
        <wsu:Created>2009-11-08T11:03:20Z</wsu:Created>
        <wsu:Expires>2009-11-08T11:08:20Z</wsu:Expires>
      </wsu:Timestamp>
    </wsse:Security>
  </S:Header>
  <S:Body>
    <trust:RequestSecurityTokenResponseCollection
      xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"
      xmlns:wsse="http://.../oasis-200401-wss-wssecurity-secext-1.0.xsd"
      xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
      xmlns:wsa="http://www.w3.org/2005/08/addressing"
      xmlns:trust="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <trust:RequestSecurityTokenResponse>
        <trust:TokenType>urn:oasis:names:tc:SAML:2.0:assertion</trust:TokenType>
        <trust:RequestedSecurityToken>
          <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
           ID="uuid-76a197ba-c2e8-4704-97a2-147db7619f2c"
           IssueInstant="2009-11-08T11:03:20Z" Version="2.0">
            ...
            <saml:Subject>
              <saml:NameID NameQualifier="STS">jdoe</saml:NameID>
              <saml:SubjectConfirmation
                Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
            </saml:Subject>
            ...
          </saml:Assertion>
        </trust:RequestedSecurityToken>
        <trust:RequestedAttachedReference>
          <wsse:SecurityTokenReference>
            <wsse:KeyIdentifier
             ValueType="http://.../wss/oasis-wss-saml-token-profile-1.1#SAMLID">
              uuid-76a197ba-c2e8-4704-97a2-147db7619f2c
            </wsse:KeyIdentifier>
          </wsse:SecurityTokenReference>
        </trust:RequestedAttachedReference>
          ...
        <wsp:AppliesTo>
          <wsa:EndpointReference>
            <wsa:Address> http://testHost/HelloService</wsa:Address>
          </wsa:EndpointReference>
        </wsp:AppliesTo>
        <trust:Lifetime>
          <wsu:Created>2009-11-08T11:03:20.344Z</wsu:Created>
          <wsu:Expires>2009-11-08T11:09:20.344Z</wsu:Expires>
        </trust:Lifetime>
      </trust:RequestSecurityTokenResponse>
    </trust:RequestSecurityTokenResponseCollection>
  </S:Body>
</S:Envelope>

Observe la presencia del campoLifetime en la respuesta. Este campo puede ser usado cuando el formato del token devuelto no está soportado por el solicitante.

Finalmente el gateway puede reemplazar el nombre del usuario del token en la solicitud del consumidor del servicio y enviarla al proveedor. La solicitud del servicio se transforma luego como se ve en el Listado 4.

Listado 4. Solicitud de servicio trandsformada
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Header>
      <wsse:Security xmlns:wsse="http://.../oasis-200401-wss-wssecurity-secext-1.0.xsd"
       soapenv:mustUnderstand="1">
        <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
           ID="uuid-76a197ba-c2e8-4704-97a2-147db7619f2c"
           IssueInstant="2009-11-08T11:03:20Z" Version="2.0">
            ...
            <saml:Subject>
              <saml:NameID NameQualifier="STS">jdoe</saml:NameID>
              <saml:SubjectConfirmation
                Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
            </saml:Subject>
            ...
          </saml:Assertion>

      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
    …
  </soapenv:Body>
</soapenv:Envelope>

Conclusión

En este artículo se muestra como se puede utilzar WS-Trust para resolver las cuestiones del intercambio de token. Las interacciones se resumen en el diagrama de secuencias en la Figura 6.

Figura 6. Secuencia del diagrama de la transformación del token
Diagrama de secuencia de la transformación del token

Para implementar una solución como la descrita en este artículo, usted puede utilizar las aplicaciones de WebSphere®DataPower SOA tales como un gateway y Tivoli® Federated Identity Manager como Security Token Service.


Agradeciemientos

Al autor le gustaría agradecer a Arnauld Desprets de IBM Software Group y a Stéphane Monfort de IBM Global Business Services por su colaboración en este artículo.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere, SOA y servicios web
ArticleID=489325
ArticleTitle= Usar WS-Trust para la transformación token
publish-date=05112010