![Cerrar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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
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 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
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
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
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>
|
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
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.
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.
-
Web
Services Security:
Obtenga la especificación.
-
Web
Services Trust Language:
Obtenga la especificación de WS-Trust.
-
SOA: Administración
de los contextos de identidades en la solicitud de los servicios: Consideraciones sobre la propagación de
las identidades en el entorno de SOA.
(developerWorks 2008): Su artículo aborda los retos empresariales al administrar
los contextos de identidades en los servicios de la Web y de SOA. Pone de manifiesto
la importancia de crear soluciones basadas en los estándares. La capacidad de security
token service(STS) en IBM® Tivoli® Federated Identity Manager (TFIM)
es un elemento clave que puede ser usado en las soluciones para abordar estos rquisitos
de la propagación de identidades. Este artículo explica las capacidades
de STS y esboza enfoques arquitectónicos utilizando TFIM para resolver estas
necesidades.
-
Servicios de developerWorks WebSphere Web y SOA zone:
Obtenga los últimos recursos técnicos de los servicios de IBM WebSphere Web y de las soluciones de
SOA, incluyendo las descargas, las demostraciones, los artículos, los tutoriales, los eventos, los webcasts y mucho más
Laurent 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.
