Funcionamiento del desarrollo

Como primer paso el Delegador presenta sus credenciales al Proveedor de Identidad con la intención de ser autenticado. En este caso la credencial corresponde a un certificado de clave pública X.509 y la presentación se realizada mediante una interacción directa con un Web Service que actúa como interfaz del Proveedor de Identidad. Una vez autenticado a través de su certificado, el delegador le solicita al Proveedor de Identidad una declaración de atributos que incluya aquellos de sus atributos que son necesarios para el acceso al servicio que se quiere delegar. Es decir, se le solicita al Proveedor de Identidad un aserto SAML v2 que incluya aquellos atributos de usuario relativos al delegador requeridos por el Proveedor de Servicio a la hora de permitir el acceso a un servicio o conjunto de servicios. Esta solicitud, al igual que la autenticación, tiene lugar mediante la invocación de un Web Service en el Proveedor de Identidad.

En el Proveedor de Identidad, concretamente en el Web Service invocado, tras verificar las credenciales del delegador a través de su certificado de identidad y comprobar que todo es correcto se compone un aserto SAML con los atributos solicitados, se firma haciendo uso de la

159

clave privada del Proveedor de Identidad y se le entrega como respuesta de la interacción al delegador.

Figura 63 – Autenticación del Delegador y generación de la declaración de atributos SAML El delegador, tras obtener la respuesta, comprobará su integridad, la validez de la firma por parte del Proveedor de Identidad y la corrección del conjunto de atributos sobre su identidad aseverados en el aserto SAML. Tanto en el caso del Web Service que actúa como Proveedor de Identidad como en el del proceso que actúa como delegador las operaciones criptográficas se realizan mediante la API proporcionada por Bouncycastle (109).

En el proceso delegado, con la intención de obtener un token que le autorice a actuar en nombre del delegador ante el Proveedor de Servicios y haciendo uso de la API criptográfica Bouncycastle (109), se genera una pareja de claves asimétricas (una clave pública y su correspondiente privada). En este ejemplo se han generado claves RSA de 1024 bits, tal como se puede ver en la siguiente captura.

Figura 64 – Generación de claves para el token de delegación

A continuación le envía al delegador, a través de un canal seguro SSL, la clave pública generada, manteniendo debidamente protegida la clave privada.

160

En el proceso delegador, a partir del aserto SAML recibido en su interacción con el Proveedor de Identidad y de la clave pública recibida del delegado se genera, haciendo uso del Globus Toolkit® (110) combinado con el plugin GridShib (111), un Certificado Proxy X.509 al que se le añade la extensión que contiene el aserto de atributos SAML y la extensión

serviceIRIConstraints propuesta en este trabajo de tesis, es decir, se genera el token de delegación de identidad. En la Figura 65 puede verse el token generado.

Figura 65 – Token de delegación

Tras esto, el proceso delegador le envía al delegado el token de delegación a través del canal seguro SSL.

El proceso delegado, una vez recibido el token de delegación a través del canal SSL, dispone de elemento que le permite solicitar al Proveedor de Servicio, en nombre del delegador, el servicio demandado. Al igual que en el caso del Proveedor de Identidad, el Proveedor de Servicio ofrecerá sus servicios a través de un Web Service identificado por un IRI específico. Dicho IRI está incluido en la lista de IRIs permitidos establecida en el token de delegación. Como primer paso ante la recepción del token de delegación en el Proveedor de Servicio comprueba su validez, es decir, que el camino de validación es correcto. Como hemos visto, el token de delegación está ligado al delegador por su firma, por lo que el Proveedor de Servicio sabe en nombre de quién está accediendo al servicio el delegado y comprueba, mediante la correspondiente verificación, la validez del aserto de atributos. En base a esto, al aserto SAML con la declaración de atributos y a las restricciones de acceso a los servicios especificadas en el token de delegación mediante la extensión serviceIRIConstraints, el Proveedor de Servicio podrá tomar las decisiones de autenticación y autorización pertinentes y decidir si prestar o no el servicio solicitado por el delegado. En la siguiente captura, correspondiente al log del Proveedor de Servicio, pueden verse estos pasos.

161

Figura 66 – Log Proveedor de Servicio

Suponiendo que todo es correcto, en el Proveedor de Servicio se ejecuta el servicio demandado, entregándosele a continuación al delegado la información resultante.

Una vez finalizada la interacción con el Proveedor de Servicio el delegado hace llegar al delegador los resultados del servicio demandado.

En las siguientes capturas podemos ver los logs de los procesos tanto delegador como delegado.

162

Figura 68 – Log del proceso delegado

Como consideraciones a la implementación realizada indicar que no se ha incluido la parte de la propuesta relativa a la revocación y, por lo tanto, no se ha implementado la Autoridad de Revocación de Tokens de Delegación. Esto se debe a que el objetivo de esta implementación es demostrar, como aquí se recoge, que el token de delegación es realizable y que el proceso de delegación propuesto es viable de acuerdo a lo especificado en este trabajo de tesis.

Cabe destacar que, a pesar de que la implementación se ha realizado en un entorno muy reducido en el que solo existen un Proveedor de Identidad y un Proveedor de Servicios, lo desarrollado es fácilmente extrapolable a entornos de aplicación más complejos en los que, por ejemplo, convivan varios Proveedores de Identidad y de Servicios.

163