Desarrollo de servicios WEB con Gestión de Identidad ...Desarrollo de servicios WEB con gestión de...
Transcript of 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.
Desarrollo de servicios WEB con gestión de Identidad federada y autorización 141
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
UserAthenticationItf
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
UserAthenticationItf
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.
142 Carlos Rodríguez Fernández y Francisco J. Garijo
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
TelcoIdentityMgmt Service
Interceptor
TechnicianVisualizationReswithIDM
TechnicianVisualizationUseItf
PostBindingAsssertionConsumerItf
UnsolicitedResponseAssertionConsumerItf
TechnicianAssistantwithIDM
TechnicianAssistantUseItf
1: ActivateService()
1.1: ActivateService (SAMLToken)
1.2: GetWorkplan(TecnicianID)
1.3: VisualizeWorkplan(Technician Work Plan)
2: fill reparation report and get invoice()
Tecnician
TelcoIdentityMgmt Service
Interceptor
TechnicianVisualizationReswithIDM
TechnicianVisualizationUseItf
PostBindingAsssertionConsumerItf
UnsolicitedResponseAssertionConsumerItf
TechnicianAssistantwithIDM
TechnicianAssistantUseItf
1: ActivateService()
1.1: ActivateService (SAMLToken)
1.2: GetWorkplan(TecnicianID)
1.3: VisualizeWorkplan(Technician Work Plan)
2: fill reparation report and get invoice()
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.
Desarrollo de servicios WEB con gestión de Identidad federada y autorización 143
AuthorizationService
AuthorizationPort
CustomerIdentityMgmt
IdmPort
SMEIdentityMgmt
SMEIDMPort
TechnicianAssistantwithIDM
TechnicianAssistantUseItf
TechnicianVisualizationReswithIDM
PostBindingAsssertionConsumerItf
TechnicianVisualizationUseItf
UnsolicitedResponseAssertionConsumerItf
Payment Service
Payment
ServiceUseItf
TelcoIdentityMgmt
Service
Interceptor
Billing Service
BilllingServiceUseItf
Tecnician
AuthorizationItf
SecurityTokenItfUserAthenticationItf
SecurityTokenItf
UserAthenticationItf
1: fill reparation report and get invoice()
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
144 Carlos Rodríguez Fernández y Francisco J. Garijo
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.
Desarrollo de servicios WEB con gestión de Identidad federada y autorización 145
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
146 Carlos Rodríguez Fernández y Francisco J. Garijo
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
Desarrollo de servicios WEB con gestión de Identidad federada y autorización 147
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
148 Carlos Rodríguez Fernández y Francisco J. Garijo
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
Desarrollo de servicios WEB con gestión de Identidad federada y autorización 149
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/
150 Carlos Rodríguez Fernández y Francisco J. Garijo
[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/