El diseño de Cl@ve está basado en un sistema de federación de identidades electrónicas, que integra diferentes elementos:
Proveedores de servicios de administración electrónica (SP): Entidades que proporcionan servicios electrónicos a los ciudadanos y utilizan la plataforma para la identificación y autenticación de los mismos.
Proveedores de servicios de identificación y autenticación (IdP): Entidades que proporcionan mecanismos de identificación y autenticación de los ciudadanos para ser utilizados como medios comunes por otras entidades. Inicialmente se contempla la existencia de dos proveedores de servicios de identificación, la Agencia Estatal de Administración Tributaria (AEAT) que ofrecerá los servicios de Identificación y autenticación correspondientes al sistema Cl@ve PINy ,la Gerencia de Informática de la Seguridad Social (GISS) que ofrecerá el servicios Cl@ve permanente, basado en el uso de usuario y contraseña, reforzado con claves de un solo uso por SMS. El diseño de la solución contempla la extensión a otros potenciales proveedores de identidades, si así se considera conveniente.
Pasarela / Gestor de Identificación: Sistema intermediador que posibilita el acceso de los proveedores de servicios a los distintos mecanismos de identificación y la selección de éstos por parte del usuario.
De acuerdo con este diseño, los proveedores de servicios únicamente tienen que integrarse con el Gestor de Identificación, encargándose éste de establecer las relaciones pertinentes con los distintos sistemas de identificación. Para ello se establecen relaciones de confianza entre los distintos actores que se integran entre sí, soportadas por el intercambio de certificados electrónicos y el envío de mensajes firmados entre ellos, que garantizan la transmisión segura de la información durante todo el proceso de identificación y autenticación.
Adicionalmente, el sistema está preparado para integrarse con otros dos sistemas intermediadores de identificación:
@firma : Suite de productos a disposición de las Administraciones Públicas que permite a los servicios de administración electrónica gestionar la identificación y firma mediante certificados electrónicos, entre ellos el DNIe.
STORK : Plataforma de interoperabilidad que permite el reconocimiento transfronterizo de identidades electrónicas, desarrollada durante la ejecución de los proyectos STORK y STORK 2.0, y que servirá de base para la construcción del futuro sistema de reconocimiento de identidades electrónicas previsto en reglamento europeo de identificación electrónica y servicios de confianza (reglamento eIDAS).
El flujo de interacción con el usuario se observa en el diagrama siguiente:
Toda la comunicación con un componente de la plataforma Cl@ve se realiza a través del intercambio de tokens que pasan previamente por el navegador del ciudadano. De esta manera cada proveedor de servicios de identificación sólo responde al ciudadano desde el que ha recibido una petición de autenticación.
En este caso genérico vemos que el SP no interactúa directamente con ningún IdP, sino que lo hace exclusivamente a través del navegador del ciudadano.
Los pasos de la interacción son los siguientes:
El ciudadano accede a un servicio de administración electrónica integrado con Cl@ve que requiere que se identifique.
El ciudadano es redirigido a Cl@ve, que le presenta una pantalla en la que debe seleccionar el método de identificación que quiere utilizar. Las opciones activas en la pantalla vienen condicionadas por los parámetros que el SP ha indicado en el mensaje que ha enviado a Cl@ve relativos a los IdP y niveles QAA permitidos.
El ciudadano selecciona el método de identificación y es redirigido al IdP correspondiente. El ciudadano se autentica en el IdP seleccionado y es redirigido de nuevo a Cl@ve
De forma transparente, sin que sea necesario interacción, el ciudadano es redirigido de nuevo al SP.
En la información que viaja a través del ciudadano siempre existe un token SAML, y es en la creación y validación de esos tokens donde se produce la comunicación indirecta de los distintos componentes del sistema.
Todos los tokens van firmados por la entidad emisora y el que esa firma sea validada por el componente destinatario depende de que exista confianza entre los certificados de firma de ambos componentes. De este modo con independencia del mecanismo escogido, y en caso de que todo haya ido bien, el ciudadano acaba saliendo con el mismo resultado, un SAML firmado con sus datos identificativos.
Este modo de funcionamiento es modular, es decir, cada sistema de validación es independiente de los demás, y pueden ser habilitados o inhabilitados en función de las necesidades de la aplicación cliente. Esta modularización permite que el sistema sea fácilmente escalable si en un futuro aparecen nuevos métodos de autenticación admitidos por la Administración, y que cada sistema sea el respaldo de los demás, ofreciendo un mejor servicio al ciudadano.
Cada sistema tendrá un indicador de la calidad asignado que identifique unívocamente la fortaleza de cada uno de los métodos de autenticación soportados por el mismo (nivel de aseguramiento de la calidad de la autenticación, QAA). La aplicación cliente podrá escoger, en función de este nivel, el conjunto de sistemas de identificación que permite.
Para la identificación del ciudadano, el modelo de federación de identidades de Cl@ve se basa en el estándar SAML. Por tanto el modo de conexión al servicio de clave no es mediante servicios Web, sino mediante aserciones SAML de navegador.
En concreto, Cl@ve se basa en la utilización del perfil SAML 2.0 definido por STORK. Este perfil se utilizará tanto para la integración entre Cl@ve y el proveedor de servicios, como para la integración entre Cl@ve y el proveedor de identidad, tal como se observa en la siguiente figura:
Para integrarse con Cl@ve, los proveedores de servicios deben tener la capacidad de crear tokens SAML. Para la generación de estos tokens, se proporciona un paquete de integración para SP con un motor SAML, el STORKSAMLEngine, que debe ser integrado en la capa de autenticación de la lógica de negocio del SP.
El paquete de integración se completa con un Servidor de Aplicaciones Demo (SP-DEMO) que integra el motor de creación de tokens SAML y facilita el desarrollo de los métodos de invocación de las funciones de envío y recepción de tokens del motor SAML.
