Pública
El procedimiento de delegación que se presenta en este apartado se construye en base al token de delegación presentado en el apartado anterior y tomando como punto de partida el escenario genérico de gestión de identidad presentado en el apartado 3.4.2.1 Escenario genérico de Sistema de Gestión de Identidad Federada, que refleja la realidad de la mayoría de los sistemas de Gestión de Identidad y Provisión de servicios empleados a día de hoy en los entornos de la Administración Pública, tanto a nivel nacional como pan-Europeo.
A continuación se presentan las entidades participantes y el modelo de comunicación y comportamiento que se propone.
En una primera aproximación el conjunto de entidades participantes son las siguientes:
Delegador: Corresponde a la persona o entidad que cede una parte de sus privilegios a otra.
Delegado: Es la persona o entidad que recibe los privilegios del Delegador.
Proveedor de Servicio: Es la entidad encargada de proveer un determinado servicio, ya sea al delegado o al delegador. En la arquitectura que se propone, al soportar la
131
provisión de servicios a delegados, debe ser capaz de verificar si el proceso de delegación se ha efectuado o no de forma correcta.
Proveedor de Identidad: Es la entidad encargada de la autenticación de los usuarios y de la generación de los correspondientes asertos de autenticación o de atributos. El modelo de comunicación y las interacciones en la provisión de un servicio con delegación sería el que se presenta paso a paso en las siguientes figuras. La secuencia en la que tiene lugar el intercambio de información se detalla a continuación:
Figura 47 – Modelo de provisión de servicio con delegación: autenticación
Los pasos indicados en la Figura 47 representan la interacción del ciudadano o entidad que actúa como delegador con el Proveedor de Identidad, es decir, la fase de autenticación del delegador. A continuación se comentan de forma detallada:
1. Como primer paso el Delegador presenta sus credenciales al Proveedor de Identidad con la intención de ser autenticado. Las credenciales del Delegador pueden ser, tal y como sucede en la actualidad en la mayoría de los países de la Unión Europea, de distintos tipos: desde una pareja simple de usuario y contraseña a los más complejos y seguros certificados de clave pública X.509. Dado que el mecanismo de autenticación mediante certificados de clave pública X.509 se corresponde con la tendencia actual a nivel europeo será el que se considere de ahora en adelante. Adicionalmente al proceso de autenticación 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 o servicios que se quieren 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.
2. El Proveedor de Identidad, tras verificar las credenciales del delegador y comprobar que todo es correcto, le devuelve un aserto SAML firmado que incluye el conjunto de atributos solicitados. Corresponde al delegador la tarea de comprobar la integridad de la respuesta, 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.
Una vez autenticado y en posesión de la declaración de atributos en forma de aserto SAML necesaria para el acceso al servicio o servicios en el Proveedor de Servicios, tiene lugar el proceso de delegación mediante el cual el delegador genera el token de delegación y se lo entrega al delegado. En la siguiente figura se representa el proceso y, a continuación, se comentan de forma detallada los pasos representados:
132
Figura 48 – Modelo de provisión de servicio con delegación: delegación de la identidad a. El delegador solicita al delegado que acceda al servicio en su nombre, es decir, le
solicita intervenir en un proceso de delegación de identidad.
b. El delegado, con la intención de obtener un token que le autorice a actuar en nombre del delegador ante el Proveedor de Servicios, genera una pareja de claves asimétricas (una clave pública y su correspondiente privada).
c. A continuación le envía al delegador, a través de un canal seguro, la clave pública generada, manteniendo debidamente protegida la clave privada.
d. El delegador construirá un token de delegación con la clave recibida. Como hemos visto, el token de delegación incluirá, a través de un conjunto de extensiones no críticas, el aserto SAML v2 con la declaración de atributos del delegador generada y firmada por el Proveedor de Identidad y la indicación del conjunto de servicios a los que el delegado podrá acceder dentro de entre los ofrecidos por el Proveedor de Servicios.
e. Una vez generado el token de delegación el delegador se lo envía a través de un canal seguro al delegado.
Con la intención de simplificar las representaciones gráficas del proceso, de ahora en adelante los pasos a, b, c, d y e se resumirán como paso 3.
Ya en posesión del token de delegación el delegado podrá acceder a los distintos servicios ofrecidos por el Proveedor de Servicio, pero siempre de acuerdo, como hemos visto con anterioridad, a las limitaciones establecidas por el delegador en el token de delegación.
En la Figura 49 se representa el acceso al servicio por parte del delegado y la entrega de resultados al delegador.
Figura 49 – Modelo de provisión de servicio con delegación: El delegador obtiene el servicio a través del delegado
133
3. El delegador genera el token de delegación de identidad y se lo hace llegar, a través de un canal seguro, al delegado.
4. El delegado, una vez en posesión del token de delegación, dispone de elemento que le permite solicitar al Proveedor de Servicio, en nombre del delegador, el servicio demandado. Como primer paso ante la presentación del token de delegación por parte del delegado el Proveedor de Servicio comprueba su validez 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. 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.
5. Suponiendo que todo es correcto, el Proveedor de Servicio entrega al delegado la información correspondiente al servicio demandado.
6. Una vez finalizada la interacción con el Proveedor de Servicio el delegado hace llegar al delegador los resultados del servicio demandado.
Como se puede observar, en el paso 2 (Figura 47) se realiza una verificación de firma que implica la interacción del delegador con la PKI para verificar si el certificado del Proveedor de Identidad está revocado o no. Así mismo, el Proveedor de Servicios debe verificar la firma de delegador en el paso 4, por lo que también debe interactuar con la PKI. En ese mismo paso 4 existe otro proceso de validación que debe ser previo al proceso de validación de firma, se trata del proceso de validación del token de delegación. El proceso de validación del token de delegación consiste, fundamentalmente, en verificar dos aspectos: que el camino de delegación del token es correcto y que el token no se encuentra revocado.
Dado que el token de delegación está basado en los Certificados Proxy el proceso de validación del camino de delegación es similar al de estos (ver apartado 5.2.1.1.3 Validación y revocación de Certificados Proxy). Para proceder a la validación del token de delegación son necesarios el nombre distintivo y la clave pública del certificado de clave pública del Delegador. Si consideramos el modelo más complejo de delegación, es decir, si tenemos en cuenta la posibilidad de que exista delegación indirecta de forma que el camino de delegación pueda estar formado por n tokens de delegación tenemos que, para que un token sea considerado válido, se debe verificar que el camino de delegación, es decir, la cadena de n tokens de delegación, cumpla las siguientes condiciones:
a. Para todo x en el conjunto comprendido entre 1 y n-1, el valor del campo subject del token de delegación x coincide con el valor del campo issuer del token de delegación
x+1 y el subject distinguished name del token de delegación x+1 es un subject distinguished name legal para haber sido generado por el token de delegación x. b. El token de delegación 1 es un token de delegación válido generado por el certificado
de entidad final (ECC) del Delegador. Dicho certificado se proporciona como entrada al proceso de validación del camino de delegación.
c. El token de delegación n es el token de delegación a validar.
d. Para todo x en el rango comprendido entre 1 y n el token de delegación x es válido en el momento en cuestión.
134
e. Para todos los tokens de delegación en el camino con un determinado valor en el campo pCPathLenConstraint, el número de tokens de delegación a continuación en el camino de delegación no excede la longitud especificada en dicho campo.
Resulta de especial interés a la hora de validar el camino de delegación el apartado d, en el que se dice que el token de delegación debe ser válido en el momento en cuestión. Esto implica un proceso recurrente en el que cada uno de los tokens implicados en el camino de delegación debe verificar que el camino de delegación hasta él es correcto y que, además, dicho token de delegación no se encuentra revocado. La forma de comprobar si un token de delegación se encuentra o no revocado haciendo uso de la Autoridad de Revocación de Tokens de Delegación ha sido explicada en anteriores apartados y constituye una de las aportaciones de este trabajo de tesis. En el caso que nos ocupa la entidad que debe verificar tanto el camino de delegación como el estado de revocación de los tokens de delegación es el Proveedor de Servicio. Por ello, dentro del paso 4 podemos considerar que existe una interacción entre el Proveedor de Servicio y la Autoridad de Revocación de Tokens de Delegación, tal como se representa en la Figura 50.
Figura 50 – Modelo de provisión de servicio con delegación: Proceso de consulta del estado de revocación de un token de delegación
Así, si en la arquitectura representada en las figuras anteriores (Figura 47, Figura 48, y Figura 49) incluimos a la Autoridad de Revocación de Tokens de Delegación y representamos como pasos 4a y 4b el proceso de consulta del estado de revocación del correspondiente token de delegación por parte del Proveedor de Servicio obtenemos la propuesta definitiva de modelo de provisión de servicio con delegación representada en la Figura 51.
135
Figura 51 – Modelo de provisión de servicio con delegación y consulta de revocación A continuación se presenta la particularización del modelo para un posible escenario de prestación de servicios por parte de la Administración Pública Española. Concretamente se detalla el caso de uso de un ciudadano español que pretende realizar un trámite personal con la Agencia Estatal de Administración Tributaria por vía telemática pero que opta por delegar parte de su identidad, en particular el conjunto de atributos de identidad necesarios para acceder al servicio, en un gestor, de manera que será éste último el que obtenga el servicio en nombre del ciudadano.
El modelo de comunicación sería similar al modelo genérico, por lo que a la hora de particularizar el modelo para un entorno real lo más importante es definir claramente qué entidades reales corresponden a qué entidades del modelo. En nuestro caso:
Delegador: El ciudadano que pretende realizar un trámite con la Agencia Estatal de Administración Tributaria pero opta por delegar.
Delegado: Corresponde al gestor en el que el ciudadano delega una parte de su identidad.
Proveedor de Identidad: La entidad encargada de autenticar a los ciudadanos a través de su identidad digital y generar declaraciones firmadas de atributos mediante asertos SAML 2.0. En el caso de España esta labor corresponde a la plataforma encargada de validar las identidades digitales contenidas en el DNI electrónico, soportada por la Policía Nacional. Dicha plataforma no dispone, a día de hoy, de la capacidad para generar asertos SAML con atributos de identidad pero es de suponer que, si se adopta un modelo como el propuesto, sea capaz de realizar este tipo de operaciones.
Proveedor de Servicio: En el caso que nos ocupa sería la Agencia Estatal de Administración Tributaria.
Autoridad de Revocación de Tokens de Delegación: Dado que esta entidad es una de las aportaciones de este trabajo de tesis, actualmente no existe una entidad que haga las labores propuestas para esta autoridad. Como hemos comentado se espera que se integre dentro de la PKI nacional como una Tercera Parte de Confianza (TTP).
PKI: En el caso de España la PKI está muy ligada a las identidades digitales de los ciudadanos pues dichas identidades se basan en certificados X.509 de clave pública. A
136
nivel nacional se puede considerar que existen dos autoridades, el Ministerio de Administraciones Públicas y la Real Casa de la Moneda. Por simplicidad, en este ejemplo consideraremos únicamente el Ministerio de Administraciones Públicas.
Figura 52 – Escenario real de aplicación de la solución de delegación de identidad y conjunto de interacciones entre entidades
La Figura 52 refleja el escenario presentado y el conjunto de interacciones que tienen lugar y se explican a continuación:
1. El ciudadano que pretende delegar, el delegador, se autentica mediante su DNI electrónico y haciendo uso de su certificado de clave pública frente a la plataforma de autenticación de la Policía Nacional. Adicionalmente, en este proceso de autenticación le solicita a dicha plataforma la entrega de una declaración de atributos que, mediante un aserto SAML v2, incluya el conjunto de sus atributos de usuario requeridos por la Agencia Estatal de Administración Tributaria para permitir el acceso al servicio que pretende delegar.
2. La plataforma de autenticación de la Policía Nacional, tras verificar a través de su certificado de clave pública que el ciudadano es quién dice ser, le devuelve una declaración firmada de atributos SAML con el conjunto de atributos solicitados. El ciudadano verifica a continuación la integridad de la respuesta, la validez de la firma y comprueba la corrección del conjunto de atributos sobre su identidad aseverados en la declaración de atributos SAML v2 entregada por la plataforma de autenticación. 3. El ciudadano se pone en contacto con el gestor de su confianza y le solicita iniciar el
proceso de delegación de identidad para el acceso al servicio proporcionado por la Agencia Estatal de Administración Tributaria.
4. El gestor, con la intención de obtener un token de delegación que le autorice a actuar como delegado ante la Agencia Estatal de Administración Tributaria, genera una pareja de claves asimétricas (una clave pública y su correspondiente privada) y le envía al
137
ciudadano la clave pública generada a través de un canal seguro, haciendo uso, por ejemplo, de SSL.
5. El ciudadano formará un token de delegación con la clave pública recibida del gestor, la declaración de atributos firmada por la plataforma de autenticación de la Policía Nacional y la indicación, mediante el correspondiente IRI, del servicio, dentro de los ofrecidos por la Agencia Tributaria, cuyo uso delega en el gestor.
6. Una vez generado el token de delegación, el ciudadano se lo envía a través de un canal seguro al gestor.
7. El gestor dispone pues de un token de delegación que le permite solicitar a la Agencia Estatal de Administración Tributaria la prestación del servicio demandado por el ciudadano.
8. La Agencia Estatal de Administración Tributaria validará el token de delegación verificando que el camino de delegación es correcto y que el token no se encuentra revocado y comprobará en nombre de qué ciudadano está intentando acceder el gestor.
9. En base a esto, al aserto SAML con la declaración de atributos y a la IRI del servicio especificada en el token de delegación, la Agencia Estatal de Administración Tributaria podrá tomar las decisiones de autenticación y autorización pertinentes que le permitan decidir si prestar o no el servicio solicitado por el gestor actuando en nombre del ciudadano. Suponiendo que todo es correcto, la Agencia Estatal de Administración Tributaria entregará al gestor la información o resultados correspondientes a la prestación del servicio demandado.
10. Una vez finalizada la interacción con la Agencia Estatal de Administración Tributaria el gestor hará llegar al ciudadano los resultados del servicio demandado.
Como se puede observar, la solución de delegación es perfectamente integrable en un escenario real. Si tomamos como ejemplo el escenario español actual el conjunto de modificaciones a realizar se resume en las siguientes:
Añadir una Tercera Parte de Confianza, la Autoridad de Revocación de Certificados Proxy, a la actual infraestructura de PKI.
Centralizar los atributos de usuario que puedan ser necesarios para el acceso a los servicios en una única entidad que actúa como Proveedor de Identidad y dotarla de soporte para la generación de declaraciones de atributos SAML. La actual plataforma de eDNI actúa como Proveedor de Identidad en el entorno nacional, por lo que bastaría con realizar las acciones comentadas sobre ella.
Modificar los Proveedores de Servicios para que basen el control de acceso en atributos y acepten el token de delegación. La mayoría de los Proveedores de Servicios en la Administración Pública actual basan la autenticación de usuarios y la prestación de servicios en certificados de identidad X.509, por lo que modificar su comportamiento para que entiendan los tokens de delegación debería resultar sencillo. Al fin y al cabo basta con saber procesar un conjunto definido de extensiones de certificado X.509 v3.
Dotar a los usuarios de las herramientas necesarias para que, haciendo uso de sus DNIs electrónicos, puedan llevar a cabo la generación de los tokens de delegación y los trámites asociados (revocación, etc.).
138