desarrollo de servicios web con gestión de identidad ...desarrollo de servicios web con gestión de...

Desarrollo de servicios WEB con Gestión de Identidad

Federada y Servicios de Autorización

Carlos Rodríguez Fernández1, Francisco J. Garijo

2

1Dto Ing. Software e Int. Artificial, Universidad Complutense de Madrid

Ciudad Universitaria s/n, 28040 Madrid, Spain 2Telefónica I+D

C/ Emilio Vargas 6, 28043 Madrid, Spain

[email protected], [email protected]

Abstract. En este trabajo se describe la arquitectura, las experiencias y los

resultados obtenidos en la integración de tecnologías de gestión de identidad

abiertas (Liberty Alliance), y tecnologías Web Services. El marco experimental

se ha basado en la realización de un prototipo de servicios integrales para

PYMES que utiliza varios proveedores de identidad federados y un Servicio

de Autorizaciones basado en el People Service de Liberty. En el artículo se

describen la arquitectura de los componentes y los estándares utilizados -

SAML 2.0, WS-Trust 1.3, WS Security 1.1, y WS-Trust 1.3 Interoperability

Profile: SAML 2.0 Token Profile-, analizándose las extensiones necesarias en

los WS compuestos (BPEL) para procesar mensajes con aserciones SAML. El

comportamiento del sistema se ilustra con casos de uso del piloto. En las

conclusiones se resumen los principales retos del proceso de integración, los

resultados obtenidos y las posibles mejoras.

1 Introducción

La integración de mecanismos de seguridad basados en gestión de identidad sigue

siendo un factor clave para el desarrollo y la implantación de las tecnologías y

paradigmas orientados a servicios. Aunque existen varios modelos y estándares para

tratar el tema de la gestión de identidad [7], la integración efectiva de dichos

estándares en entornos de desarrollo compuestos por múltiples dominios de confianza

con distintos proveedores de identidad, es un tema abierto donde las soluciones están

por llegar. En el presente trabajo se describe un caso de estudio desarrollado en el

marco del proyecto SECSE [2] [5], donde la gestión de identidad aparece como un

requisito básico para garantizar la seguridad, la trazabilidad y las condiciones de

confidencialidad y privacidad establecidos por el usuario. El escenario considerado

esta formado por varios proveedores de servicio y diferentes proveedores de

identidad federados. El usuario accede a los servicios federados de forma segura y

transparente, por medio de las credenciales facilitadas por una Autoridad de

Certificación (AC), en este caso un operador de Telecomunicaciones. La información

de identidad del usuario se utiliza para autenticar al usuario y para validar el acceso a

los servicios federados teniendo en cuenta los permisos declarados por el usuario. Se

Desarrollo de servicios WEB con gestión de Identidad federada y autorización 139

utiliza un servicio de Gestión de Autorizaciones, modelado como un servicio Web,

que permite a los clientes definir y almacenar los servicios autorizados y procesar de

forma segura las peticiones de autorización para el acceso y uso de otros servicios. El

caso de estudio ha tenido un doble objetivo:

Evaluar la madurez de los estándares de Gestión de Identidad basados en

Liberty Alliance y su utilización en el desarrollo de servicios

Analizar la integración con los componentes de ingeniería que intervienen

en la creación de WS en particular con la herramientas de creación y de

ejecución de WS compuestos

La implementación del piloto se ha basado en los estándares de OASIS,.y de la

Liberty Alliance [1]. Se han utilizado los estándares: SAML 2.0 [6], WS-Trust 1.3

[4], WS Security 1.1 [9], y WS-Trust 1.3 Interoperability Profile: SAML 2.0 Token

Profile [8]. La implementación del Gestor de Autorizaciones se basa en el Servicio

People Service [1].

En la siguiente sección se describe con más detalle el caso de estudio, la

arquitectura del sistema propuesto, y sus componentes principales. Finalmente en las

conclusiones se presentan las experiencias obtenidas y las posibles mejoras.

2 Descripción del Caso de Estudio

El caso de estudio esta basado en un piloto desarrollado por Telefónica I+D y ATOS

para proporcionar servicios integrales basados en tecnologías Web Services a

pequeñas y medianas empresas PYMES dedicadas a mantenimiento y reparación.

Estas empresas no pueden comprar herramientas sofisticadas y caras, pero pueden

beneficiarse de sus ventajas con un modelo basado en servicios. El piloto soporta

distintos roles (administrador, técnico, atención clientes) incluyéndose los siguientes

servicios: Servicios de atención al cliente – gestión de llamadas, de incidencias,

selección de personal – ; Servicios de gestión de tareas con logística y localización –

asignación dinámica de tareas, asignación de personal cualificado, itinerarios en

función de la localización de los técnicos y clientes – ; Servicios de gestión de

almacén y facturación.

La introducción de la GI en este escenario tiene como objetivo facilitar el acceso

seguro de clientes y técnicos minimizando las interacciones de los clientes para

autenticarse y para controlar la política de autorizaciones.

En el modelo de despliegue del piloto figura 1 se describen los componentes WS

que integran el piloto y los nodos donde se ejecutan.

140 Carlos Rodríguez Fernández y Francisco J. Garijo

Fig. 1. Modelo de despliegue del Piloto con Gestión de Identidad.

El nodo de provisión del servicio tiene dos componentes de orquestación definidos

en BPEL, que implementan el modelo de control de los servicios del piloto y la

interacción con el resto de los WS. El SecretaryAssistant se encarga de los servicios a

la persona responsable de la relación con los clientes y de la asignación de tareas, y el

TechnicianAssistant de los servicios para los técnicos encargados de realizar las

tareas asignadas. Los componentes BPEL que controlan la funcionalidad del piloto

utilizan los siguientes tipos de WS:

Servicios de visualización. Implementan la interfaz de usuario adaptándola

al tipo de terminal. SecretaryVisualizationRes implementa la IU para un

PC. TechnicianVisualizationRes implementa la visualización de los técnicos

para PC y para la PDA.

Servicios proporcionados por terceras partes: Se utilizan un servicio de

Gestión de fuerzas de trabajo (Enterprise Worflow Management), un servicio

de Facturación (Billing), un servicio de Gestión de recambios (Spare Parts

Management) y un servicio de localización. Estos servicios pueden

cambiarse de forma dinámica negociando los parámetros de calidad.

Servicios de gestión de identidad (IdM). Implementados por el Servicio

de Autorización (SA) y por los proveedores de IdM: el operador de

telecomunicaciones y por el IdM de la PYME y el IdM del usuario.


2.1 Arquitectura lógica y comportamiento de los componentes de Gestión de

Identidad

El escenario seleccionado para la incorporación de la gestión de identidad se ha

centrado en los componentes relacionados con el técnico, aunque pueden aplicarse

también al resto de los componentes del servicio. La figura 2 muestra los

componentes seleccionados y las dependencias entre ellos.

Service Components

AuthorizationService

AuthorizationPort

CustomerIdentityMgmt

IdmPort

SMEIdentityMgmt

SMEIDMPort

TechnicianAssistantwithIDM

TechnicianAssistantUseItf

TechnicianVisualizationReswithIDM

PostBindingAsssertionConsumerItf

TechnicianVisualizationUseItf

UnsolicitedResponseAssertionConsumerItf

Payment Service

Payment

ServiceUseItf

TelcoIdentityMgmt Service

Interceptor

Billing Service

BilllingServiceUseItf

TelcoAttributeService

AttributeQueryItf

AuthorizationItf

SecurityTokenItf

UserAthenticationItf

SecurityTokenItf


Service Components


AuthorizationPort


IdmPort

SMEIdentityMgmt

SMEIDMPort







Payment Service

Payment

ServiceUseItf


Interceptor

Billing Service


TelcoAttributeService

AttributeQueryItf

AuthorizationItf

SecurityTokenItf


SecurityTokenItf


Fig. 2. Dependencias entre componentes del servicio

El Operador de telecomunicaciones. Actúa como proveedor de servicios

de Telecomunicaciones y como IdM. Autentica al usuario de forma

transparente, genera aserciones SAML con las credenciales de los

empleados de la PYME y las inserta en las invocaciones a los servicios

invocados por el empleado.

El IdM de la PYME. Permite crear cuentas para sus empleados, asignar

roles y otros atributos típicos de la gestión de identidad. Proporciona

servicios de autenticación y genera aserciones SAML para el usuario.

El IdM del cliente. Puede ser el mismo proveedor de la PYME o uno

diferente. Gestiona la identidad del cliente y genera igualmente SAML

tokens que deben ser interpretables por diferentes proveedores en distintos

espacios de nombres de forma que se garantice la privacidad del usuario.

El Servicio de Autorización (SA). Gestiona y almacena las autorizaciones

de los clientes para que la PYME u otras compañías realicen determinadas

operaciones. Responde a peticiones de autorización por parte de otros

servicios para actuar en nombre del usuario, verificando los permisos y

devolviendo las credenciales de los clientes en caso en que hayan sido

autorizados.


Los Componentes BPEL del piloto han sido extendidos para poder interpretar

mensajes SOAP con Tokens SAML. Se han implementado dos nuevos componentes:

IdMAdaptador4BPEL. Se encarga de insertar SAML Tokes en los

mensajes SOAP enviados por el WSBPEL

IdM Proxy. Implementa la interfaz externa del componente

TechnicianAssintantService. Procesa los mensajes entrantes con SAML

tokens, analiza su contenido y lo pasa al BPEL Engine.

2.2 Caso de uso de gestión de Identidad

Para ilustrar el comportamiento de los componentes de identidad en el piloto,

partimos de un escenario en el que el cliente ha autorizado a la PYME a efectuar

pagos por cargos de servicios. Las autorizaciones están almacenadas en el SA. La

figura 3 presenta un diagrama de comunicación con los componentes, las interfaces

y los mensajes intercambiados en el inicio del servicio por parte del técnico.

Tecnician


Interceptor







1: ActivateService()

1.1: ActivateService (SAMLToken)

1.2: GetWorkplan(TecnicianID)

1.3: VisualizeWorkplan(Technician Work Plan)

2: fill reparation report and get invoice()

Tecnician


Interceptor







1: ActivateService()

1.1: ActivateService (SAMLToken)

1.2: GetWorkplan(TecnicianID)

1.3: VisualizeWorkplan(Technician Work Plan)


Fig. 3. Activación del servicio y generación de credenciales del técnico

Cuando el técnico activa el servicio el proveedor de telecomunicaciones que actúa

también como IdM intercepta la invocación del servicio y genera una invocación al

servicio incluyendo el SAML Token con las credenciales de técnico. A continuación

el técnico solicita el plan de trabajo que es visualizado en la pantalla de la PDA,

selecciona la tarea a realizar y se dirige al domicilio del cliente para realizar la

reparación. Una vez resuelta satisfactoriamente, el técnico rellena el boletín con los

datos para obtener la factura y proceder al cobro de la misma. En el siguiente

escenario figura 4 se detallan el proceso de pago del cargo de los servicios.



AuthorizationPort


IdmPort

SMEIdentityMgmt

SMEIDMPort







Payment Service

Payment

ServiceUseItf

TelcoIdentityMgmt

Service

Interceptor

Billing Service


Tecnician

AuthorizationItf

SecurityTokenItfUserAthenticationItf

SecurityTokenItf



1.1: get Bill4Client (Repair Info)

1.2: CustomerBill= ElaborateBill(Repair Info)

1.3: SMESAMLToken= RequestSAMLToken()

1.4: CustomerSAMLToken= GetPermission(SMESAMLToken, CustomerInfo, PaymentService)

1.5: CustomerSAML= RequestSAMLToken(CustomerAuthenticationInfo)

1.6: VisualizeCustomerBill (Biling Info)

1.7: ShowCustomerBill ()

2: Pay Bill()

2.1: PayBill(CustomerBill)

2.2: Charge(CustomerSAMLToken , ChargInfo)

2.3: VisualizeConfirmationChargedInfo(ChargInfo)

2.4: ShowConfirmationChargedInfo()

Fig. 4. Pago del Servicio

La secuencia de mensajes (1.x ) es la siguiente: El técnico envía el informe de

reparación al TecnicianVisualizatioReswithIdM, este extrae los datos del cliente y de

la reparación y los transforma en una petición al TecnicianAssistanwithIdM para

obtener la cuenta del cliente ( mensaje 1.2) a través del BillingService Este

componente (mensaje 1.3) pide al IdM de la PYME un token para poder acceder al

Servicio de Autorizaciones y pedirle el token del cliente para efectuar el pago

(mensaje 1.4); el SA verifica la autorización y pide al IdM del usuario un token con

las credenciales del cliente (mensaje 1.5) , proporcionándole los datos de

autenticación del cliente. Este token es devuelto al TecnicianAssistanwithIdM que lo

guarda para utilizarlo cuando el técnico decida proceder al pago, y a continuación

ordena al visualizador (mensaje 1.6) que presente la información de la factura. El

técnico ve la factura en la PDA, puede mostrársela al usuario y pedirle confirmación

de efectuar el pago. En caso de conformidad el cliente no tiene que hacer nada. El

técnico pulsa un botón de conformidad y se inicia la segunda serie de mensajes. La

orden de pago (mensaje 2.) llega al TecnicianAssistanwithIdM a través del recurso de

visualización con los datos de cobro, éste envía una orden al servicio de cobro

(mensaje 2.2) con los datos y con las credenciales del cliente para efectuar el pago. Si

no hay problemas en la transacción se informa al técnico del resultado (mensajes 2.3

y 2.4)

3 Descripción de los Componentes IdM

En los apartados siguientes se describe con detalle la estructura interna de los

componentes representativos de la implementación de las funciones de gestión de

identidad. Se detallan en primer lugar los componentes que implementan servicios de

IdM: se describe únicamente el SMEIdentityManagement ya que tiene una estructura


y comportamiento similar al CustomerIdentityManagement, y a continuación se

describe el AuthorizationService. En los componentes dependientes del piloto como

son el TechnicianAssistantwithIdM, y el TechnicianVisualizationReswithIdM se

detallan los elementos internos necesarios para implementar la gestión de identidad y

su relación con los componentes computacionales que implementan la funcionalidad

del servicio.

Gestores de Identidad

El componente representativo es el SMEIdentityManagemet cuya estructura interna

se describe en la figura 5. Los componentes internos son los siguientes:

UserAuthenticationIdP: Implementa la Autenticación de Usuarios vía Web,

esto es, el proveedor de identidad de los escenarios descritos en “Web

Browser SSO Profile” del estándar SAML 2.0.

STSIdentityProvider: Provee el servicio Security Token Service

especificado en el estándar WS-Trust 1.3 aplicado a Tokens SAML 2.0 (ver

[8]).

SMEAttributeService: Provee el servicio AttributeService especificado en

el estándar SAML 2.0.

ConfigurationManagement: Gestiona la Configuración del servicio de

Gestión de Identidad dado por el componente SMEIdentityManagement.

SMEIDMConfiguration: Contiene la información de configuración del

servicio de Gestión de Identidad dado por el componente

SMEIdentityManagement.


Fig. 5. Estructura interna del componente SMEIdentityManagement

Servicio de Autorizaciones

El componente AuthorizationSProvider figura 6 realiza la interfaz AuthorizationItf

que proporciona operaciones para autorizar a entidades a actuar en nombre de otras.

Esta basado en el PeopleService de Liberty Alliance.

La implementación de la interfaz AuthorizationItf se apoya en el núcleo IdMCore

que contiene clases del dominio ,y servicios como encriptación y desencriptación,

creación de mensajes, parsers de XMLs, validadores, etc.. También hace uso del

modelo de información AuthorizationInformation que contiene clases que modelan la

información1 que se intercambian entre el AuthorizationService y sus clientes.

1 Transfer Object según Core J2EE Patterns, y “Documentos” en la terminología Web Services


Fig. 6. Estructura interna del componente AuthorizationService

Extensión de los componentes de Servicio

En la figura 7 se describe visualmente mediante un diagrama la estructura interna

del componente TechnicianAssistantwithIdM. Este componente es un WS-BPEL

adaptado para soportar la Gestión de Identidad. Dicha adaptación consiste en la

introducción de los componentes IdMProxy y IdMAdaptador4BPEL.

La descripción de cada uno de estos componentes es la siguiente:

IdMProxy: Intercepta todos los mensajes que van dirigidos al

componente original WS-BPEL con el objetivo de analizar la autenticidad

de los Token SAML 2.0 que adjuntan. Una vez hecho esto, obtiene

información de Identificación del llamante mediante un AttributeService

(el TelcoAtributeService en este caso) y la incorpora en el mensaje

original para que sea usado por el servicio original

TechnicianAssistantService.

IdMAdaptador4BPEL: Intercepta los mensajes salientes del WS-BPEL

TechnicianAssistantService con el fin de introducirles Tokens SAML 2.0

necesarios en la invocación de otros servicios. Estos tokens son

solicitados a proveedores de identidad como SMEIdentityManagmenet

mediante la interfaz SecurityTokenService, y en el caso de necesidad de


actuar en nombre de otra entidad son solicitados a servicios de

autorización mediante la interfaz AuthorizationItf.

Fig. 7. Estructura interna del componente TechnicianAssistantwithIDM. Ejemplo de

Integración del BPEL con IdM

En la figura 8 se muestra un diagrama que describe la estructura interna del

componente TechnicianVisualizationReswithIdM. En este diagrama se puede

identificar tres partes además del componente original TechnicianVisualizationRes.

Estos tres componentes SAMLAnalyser, PostBindingManagement y

UnsolicitedSAMLResponseManagmenet son introducidos con el fin de dar soporte a

la Gestión de Identidad. Concretamente, implementar la parte del proveedor de

servicios de los escenarios “Web Browser SSO Profile” especificados en SAML 2.0.

Dichos componentes tienen las siguientes funciones:

SAMLAnalyser: Verifica si el usuario ha sido autenticado, en caso de

que no este autenticado lo redirige al proveedor de identidad

correspondiente para que se autentique. Esto corresponde al escenario

“SP-Initiated SSO: Redirect/POST Binding” del estándar SAML 2.0.

PostBindingManagement: Verifica la información de autenticación (un

SAML Response) previamente solicitada, que llega vía HTTP POST

desde el proveedor de identidad. Una vez verificada su validez, se redirige


al usuario al recurso solicitado (TechnicianVisualizationRes en este caso).

Esto corresponde al escenario “SP-Initiated SSO: Redirect/POST

Binding” del estándar SAML 2.0.

UnsolicitedSAMLResponseManagement: Verifica la información de

autenticación (un SAML Response) que no ha sido solicitada

previamente. Una vez verificada la validez se redirige al usuario al

recurso solicitado. Esto corresponde con el escenario “IdP-Initiated SSO:

POST Binding” del estándar SAML 2.0.

Fig. 8. Estructura interna del componente TechnicianVisualizationReswithIdM.

Ejemplo de Integración de un Cliente con IdM

4 Experiencias y Conclusiones

La integración de los estándares de gestión de identidad en el desarrollo de Servicios

Web presenta numerosos retos entre los que destacan la falta de madurez de los


estándares, (por ejemplo WS Trust 1.3 y SAML 2.0 profile), la existencia de

numeroso parámetros opcionales que dificulta al integración con otros sistemas, y la

falta de soporte de código abierto a SAML 2.0 y a la gestión de identidad en general

(Infraestructura robusta, estable y con APIs bien documentadas).

El prototipo desarrollado en el marco del proyecto SECSE incorpora soluciones

concretas para superar estas dificultades. Se han diseñado e implementado los

componentes IdM del piloto y se han extendido los componentes WS para incorporar

capacidades de tratamiento de Tokens SAML 2.0 en los mensajes. De los resultados

obtenidos cabe señalar:

La implementación de una infraestructura (Framework) para Proveedores

de Identidad que contiene:

o Un Security Token Service [4]

o Una implementación “HTTP Redirect/POST Binding” de “Web

Browser SSO Profile” [6]

o Un “Attribute Service” [6]

o Un Servicio de Autorizaciones.

o Una interfaz gráfica Web para la gestión de las partes autorizadas,

servicios y clientes.

La infraestructura se complementa con un SDK para desarrolladores que

incluye soporte para aplicaciones Web, servicios Web y clientes de servicios

Web, tanto para lenguaje Java como BPEL.

Como líneas de trabajo futuro se plantea extender la infraestructura desarrollada en

dos aspectos:

Dar cobertura a todo el estándar SAML 2.0, incluyendo distintos tipos de

políticas, y de vínculos (binding).

Soportar el estándar de autorización de recursos eXtensible Access Control

Markup Language (XACML).

Agradecimientos

Los resultados del proyecto se han obtenido en el marco del proyecto IP Service

Centric Systems Engineering (SECSE) financiado por la UE. Las ideas y la

colaboración del departamento de Ingeniería Software e Inteligencia Artificial de la

Universidad Complutense de Madrid y de Carlos Plaza (Telefónica I+D) ha sido

especialmente valiosa tanto para el desarrollo del piloto como para la presentación del

trabajo.

Referencias

[1] C. Cahill, C Canales, H. A. Le Van Gong, P. Madsen, NTT, E. Maler, Greg Whitehead,

Liberty Alliance Web Services Framework: A Technical Overview Version 1.0.

http://www.projectliberty.org/liberty/resource_center/papers

[2] Deliverable A6.D5b - T-A Telecommunication pilot development architecture.

http://secse.eng.it/


[3] Nadalin, Anthony; Kaler, Chris; Monzillo, Ronald; & Hallam-Baker, Phillip; eds. Web

Services Security: SOAP Message Security 1.1 (WS-Security 2004). OASIS Standard

Specification, February 1, 2006.

[4] Nadalin, Anthony; Goodner, Marc; Gudgin, Martin; Barbir, Abbie; & Granqvist, Hans; eds.

WS-Trust 1.3. Committee Draft 01, OASIS, September 6, 2006.

[5] Service Centric Systems Engineering (SECSE). EU Integrated Project (2004-2008).

http://www.secse-project.eu/

[6] SAML 2.0 Standards, http://docs.oasis-open.org/security/saml/v2.0/

[7]Teruko MIYATA1, Yuzo KOGA1, Paul MADSEN1, Shin-ichi ADACHI1, Yoshitsugu

TSUCHIYA1A Survey on Identity Management Protocols and Standards IEICE Trans Inf &

Syst.2006; E89-D: 112-123

[8] WS-Trust 1.3 Interoperability Profile: SAML 2.0 Token Profile,

http://switch.ch/grid/support/documents/wst-saml-wd01.pdf

[9] Web Services Security, http://docs.oasis-open.org/wss/v1.1/

http://www.secse-project.eu/

http://docs.oasis-open.org/wss/v1.1/

desarrollo de servicios web con gestión de identidad ...desarrollo de servicios web con gestión de...

Documents