This website has been translated by machine translation software and has not been subsequently revised by translators. Further information at: link. Hide
the accesskey _ mod _ content
-

Cl@ve Identification

  • RoadMap:
    • In the second half ending support Cl@ve 1 , por lo que los organismos y entidades deben migrar a  Cl@ve 2 throughout the first half 2020. Cl@ve 2 supports the European authentication via the eIDAS node.
    • Cl@ve 2 proporcionará identificadores homogéneos y persistentes (DNI, NIE, o NIF con letras L y M) para aquellas personas que se identifican a través del nodo eIDAS.
    • Support for SMS admissions in the register with Cl@ve .
    • Registration is permitted in Cl@ve de extranjeros y españoles sin DNI, con la utilización de identificadores NIF L y M.
    • New service that allows mobile applications identification through native Cl@ve .

     

    Functional description

    El diseño de Cl@ve está basado en un sistema de federación de identidades electrónicas, que integra diferentes elementos: 

    • Service providers of electronic administration (SP): Entities that provide electronic services to citizens and use the platform for the identification and authentication.
    • 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.
    • Gateway/manager of Identification: matchmaker System allowing access to service providers to the different mechanisms of identification and selection by the user.

    According to this design, service providers Only have to integrate with the manager of identification, by setting The relevant relations with different systems of identification. For this establishes a relationship of trust between the different actors that integrates among themselves, supported by the exchange of electronic certificates and sending messages signed between them, which guarantee secure transmission of information throughout the process of identification and authentication.

    Additionally, the system is prepared to integrate with other two systems intermediadores of identification:

    • @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 Interoperability: platform that enables cross-border recognition of electronic identities, developed during the execution of projects STORK and STORK 2.0 that serve as a basis for building the future system of recognition of electronic identities under European regulation of electronic identification and services of confidence (eIDAS rules).

    Solution schema

     

     El flujo de interacción con el usuario se observa en el diagrama siguiente:

     

      CTT Navigation

     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.

    In this case we see the generic SP it does not interact directly with no IdP, but what makes exclusively through the citizen's browser.

    The steps of interaction are as follows:

    • The citizen accesses a service of electronic administration integrated with Cl@ve requiring identification.
    • 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
    • Transparently, without needing interaction, the citizen is redirected back to 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.

    All the tokens van signed by the issuing entity and that the signature is validated by the addressee component depends on trust between Signing Certificates of both components. This way regardless of the method chosen, and in case of everything that has gone well, the citizen is with the same result, a SAML signed with their identifiers.

    This mode of operation is modular, i.e., each validation system is independent of the others, and can be enabled or disabled depending on the needs of the client application. This modularization allows the system to be easily scalable if in a future appear new methods of authentication admitted by the administration, and that each system is the support of others, offering a better service to the citizen.

    Each system will have an indicator of the quality assigned to identify uniquely the strength of each of the authentication methods supported by the same (level of quality assurance of authentication, QAA). The client application choose, depending on this level, the whole of identification systems, which allows.

    Technical Description

    Technical Description *

    For the identification of the citizen, the model of federation of identities of Cl@ve is based on the standard SAML. Therefore the connection Mode in the service of key is not through Web services, but through assertions SAML of browser.

    In particular, Cl@ve is based on using the profile SAML 2.0 defined by STORK. This profile will be used for both the integration between Cl@ve and the service provider, as for the integration between Cl@ve and the provider of identity, as shown in the following diagram:

      Identity provider

    To integrate with Cl@ve, service providers must have the capacity to create tokens SAML. For generating these tokens, provides a package of integration for SP with an engine SAML, the STORKSAMLEngine, who must be integrated in the layer of authentication of business logic of SP.

    The package of integration is completed with a Demo application server (SP-DEMO) which integrates the engine of creation of tokens SAML and facilitates the development of methods of invocation of functions of sending and receiving tokens SAML engine.

Maintainer

Interesting links Solutions