Antes de pasar a presentar las aportaciones y propuestas para dar solución a los problemas de delegación e interoperabilidad planteados a lo largo de este trabajo de tesis conviene definir claramente cuál es el dominio de aplicación de las distintas soluciones y el conjunto de restricciones a tener en cuenta debido a las condiciones específicas de dicho dominio.
El escenario de aplicación sobre el que se ha trabajado y para el que se han pensado las soluciones aportadas en este trabajo es el de la Administración Pública, concretamente el de la provisión de servicios a los ciudadanos desde los entornos de Administración Pública en los que se utilizan los Sistemas de Gestión de Identidad con un modelo similar al presentado en el apartado 3.4.2.1, titulado Escenario genérico de Sistema de Gestión de Identidad Federada. Si recordamos este tipo de escenarios podemos observar que intervienen, básicamente, tres entidades: el usuario, el Proveedor de Identidad (IdP) y el Proveedor de Servicios (SP). Si particularizamos estas entidades en el entorno de las Administraciones Públicas nos encontramos con que, a diferencia de lo que ocurre en el modelo genérico, tanto el Proveedor de Identidad como el Proveedor de Servicios están controlados por la misma organización, el Estado, lo que implica una serie de aspectos que deben ser considerados a la hora de valorar la solución.
Al tratarse de un entorno “cerrado”, en el que solo interviene la Administración Pública, se puede dar por hecho que existen relaciones de confianza entre los distintos IdPs y SPs que puedan participar en una transacción entre el ciudadano y la Administración Pública, es decir, se puede considerar que todas las entidades pertenecientes a la Administración Pública que intervienen en una transacción con el ciudadano son Terceras Partes de Confianza (Trusted Third Parties o TTPs) entre sí. Además, se puede asumir que el comportamiento de dichas entidades es el correcto en el sentido de que el tratamiento que hacen de la información
97
relativa a los ciudadanos es el correcto y esperado de acuerdo a su condición y funcionalidad, pues se consideran adecuadamente auditadas y controladas. Así mismo, por definición, constituyen fuentes fiables de información, sobre todo en el caso del IdP, que tiene como función fundamental la autenticación de los ciudadanos y el aportar información fiable sobre su identidad.
Otra de las asunciones que se pueden realizar es que existirán los mecanismos necesarios para que el ciudadano no se tenga que preocupar de los aspectos relativos a la suplantación tanto de IdP como de SP, es decir, se supone que tanto los Proveedores de Identidad como los de Servicios se encuentran en entornos libres de problemas como, por ejemplo, el phising. A pesar de que esto último es difícil de conseguir, existen múltiples estudios y recomendaciones al respecto para garantizar un elevado nivel de seguridad. Por ejemplo, en el documento
Security and Best Practices del proyecto STORK (86), se indica que todas las conexiones entre los navegadores de usuario y las distintas entidades deben utilizar HTTPS (59). Así mismo, las entidades, que normalmente actúan como servidoras, deben utilizar autenticación clásica TLS basada en certificados reconocidos por el navegador del ciudadano. Para evitar problemas como el comentado phising, es muy importante autenticar a las entidades antes de enviarles información personal o relativa a una transacción. En el mismo documento del proyecto STORK se presenta como solución más obvia el extraer la información relativa a una entidad servidora a partir de su certificado X.509, comprobar que el certificado es válido y que la URL a la que se está accediendo coincide con la presente en el certificado para esa entidad.
Otra consideración importante en el dominio de aplicación sobre el que se trabaja corresponde al tipo de transacciones consideradas cuando se hace uso de la delegación de identidad. En el caso de aquellos servicios en los que se puede habilitar la delegación de identidad, las transacciones entre los ciudadanos y la Administración serán autenticadas y no anónimas, es decir, el ciudadano accede a los servicios haciendo uso de su identidad real, existiendo un proceso de autenticación encargado de verificar la autenticidad de dicha identidad y de verificar que el ciudadano es quien dice ser, no considerándose la posibilidad del acceso a los servicios de forma anónima.
Por último, respecto a la identidad electrónica de los ciudadanos que participan en las transacciones, se supone una identidad electrónica basada en certificados X.509 y en una PKI (Public Key Infraestructure) asociada, similar a lo establecido a día de hoy en muchos de los Estados Miembro de la Unión Europea. Un ejemplo de este tipo de identidad electrónica es el de España. La identidad electrónica del ciudadano se basa en un certificado de identidad X.509 presente en el DNI electrónico y una PKI estatal que da soporte a las operaciones de validación y revocación de dicho certificado.
98
Figura 33 – Escenario de aplicación de las soluciones aportadas en el trabajo de tesis Todas las entidades de la Administración Pública mantendrán relaciones de confianza entre ellas y serán auditables, pudiendo demostrarse en todo momento si su comportamiento es el esperado. Además el Proveedor de Identidad constituye una fuente de datos fiable, es decir, existen garantías de que la información que aporta es auténtica y válida en el momento de la consulta. El acceso por parte de los usuarios al Proveedor de Identidad y a los Proveedores de Servicios se realiza mediante conexiones seguras y autenticadas que garantizan que los intercambios de información tienen lugar entre las entidades correctas. Tanto los usuarios como las distintas entidades de la Administración Pública disponen de certificados X.509 que les permiten demostrar su identidad electrónica. Así mismo, cuentan también con el conjunto de capacidades necesarias para interactuar con una PKI para realizar todos los procesos asociados a la consulta, revocación y validación de certificados X.509.