Información para Integraciones

Para utilizar los servicios de AUTENTICAR en tu sistema o aplicación, es necesario tener en cuenta algunos conceptos técnicos:

  • ¿ Qué significa autenticar la identidad de un ciudadano?
  • Proceso de autenticación utilizando AUTENTICAR
  • Protocolo de autenticación
  • Consideraciones de seguridad
  • Integración de una Aplicación Cliente





Introducción

AUTENTICAR es el servicio brindado por la plataforma PAEC - Plataforma de Autenticación Electrónica Central de la Nación - que oficia de intermediario entre una aplicación cliente (AC) y los proveedores de autenticación (IdP) elegidos para autenticar la identidad de los usuarios de sus sistemas.

Es importante el entendimiento de los siguientes conceptos:


Aplicación Cliente

Se considera Aplicación Cliente (AC) a cualquier sistema o aplicación que utiliza los servicios de AUTENTICAR para resolver las autenticaciones de sus usuarios.

Esta AC puede estar desarrollada en cualquier tecnología y de ésta dependerá su adaptación.


Proveedor de Autenticación

Se entiende por Proveedor de Autenticación (IdP) a cualquier sistema, servicio o aplicación que brinda los servicios de autenticación de usuarios a través de PAEC.


Dominio de Autenticación

Un Dominio de Autenticación en PAEC es un conjunto de configuraciones que agrupa AC con IdPS en distintos Mecanismos de autenticación. Una propiedad interesante de un dominio de autenticación es que toda AC que esté agrupada en el mismo dominio tendrá SSO con el resto de las AC del grupo.


La interacción entre las partes es la que se muestra en el siguiente diagrama:

Diagrama de la Plataforma

Diagrama general de la Plataforma



Dominio de Autenticación con SSO

Un Dominio de Autenticación con SSO en PAEC permite que si un usuario se autentica en una AC del grupo e inicia sesión, al acceder a otra AC del grupo no tenga que iniciar sesión nuevamente porque ya va a estar autenticado.


El flujo de autenticación en este caso se detalla a continuación. En el ejemplo, dos aplicaciones web desarrolladas en distintas tecnologías pertenecen al mismo dominio de autenticación en PAEC que delega el servicio a AFIP como IdP.


Autenticacion con SSO

Diagrama de autenticación de un Dominio con SSO


Referencias:

  1. El usuario ingresa primero a la aplicación cliente de PAEC e intenta autenticarse.
  2. La aplicación cliente, redirige a PAEC para dar inicio al proceso de autenticación consultando el estado de sesión en el dominio configurado.
  3. PAEC delega la acreditación de identidad al Proveedor de Autenticación redirigiendo a su sitio.
  4. El Proveedor de Autenticación valida las credenciales y devuelve el resultado de la autenticación a PAEC siempre que la misma haya sido exitosa.
  5. PAEC devuelve el resultado de la autenticación redirigiendo la aplicación cliente.
  6. La aplicación cliente le muestra el resultado al usuario y da acceso convenientemente.

Si luego de concluido estos pasos el usuario ingresa a la aplicación desarrollada en PHP, no deberá autenticarse nuevamente dado que ya se encontrará autenticado.


Dominio de Autenticación con SLO

Un Dominio de Autenticación con SLO en PAEC permite que si un usuario cierra sesión en una AC del dominio, al acceder a otra AC del grupo tenga que autenticarse nuevamente.


Tomando el ejemplo del dominio con SSO,


Autenticacion con SSO

Diagrama de autenticación de un Dominio con SLO


Referencias:

  1. El usuario cierra sesión en la aplicación desarrollada en JAVA.
  2. La aplicación cliente, envía el cierre de sesión a PAEC.
  3. PAEC cierra sesión en el dominio.
  4. La AC cierra la sesión del usuario en la aplicación.

Si luego de concluido estos pasos el usuario ingresa a la aplicación desarrollada en PHP, deberá autenticarse nuevamente dado que al haberse cerrado sesión en el dominio ya no se encuentra autenticado.




Proceso de Autenticación

La autenticación de un usuario es el proceso mediante el cual se puede asegurar que el usuario es quien dice ser.

Este proceso se brinda desde PAEC - la Plataforma de Autenticación Electrónica Central de la Nación - entre una aplicación cliente y uno o más proveedores de autenticación a los cuales PAEC les delega la responsabilidad de autenticar credenciales de un usuario según la configuración solicitada por la aplicación.

Se puede describir a grandes razgos en los siguientes pasos:

  1. El usuario ingresa a una aplicación cliente (AC) de PAEC.
  2. La AC redirige al login del reino configurado dentro de la plataforma.
  3. El reino de PAEC redirige al login externo del proveedor de autenticación (IdP) que corresponde.
  4. El usuario se autentica en el IdP.
  5. El IdP devuelve un token con el resultado de la autenticación a PAEC.
  6. El reino de PAEC crea una sesión de usuario al usuario autenticado.
  7. Se le devuelve el token con la autenticación y datos que correspondan por IdP a la AC.



Integración de una Aplicación Cliente con AUTENTICAR

Si bien los pasos pueden cambiar dependiendo de la tecnología (tanto del servidor como de la aplicación), podemos resumir los pasos para una integración entre una aplicación y AUTENTICAR en los siguientes pasos:

  1. Creación de un reino para la aplicación cliente:

    Un reino es un dominio dentro de AUTENTICAR que comprende un conjunto de configuraciones que afecta a un grupo de aplicaciones (clientes) y usuarios, en forma aislada a otros reinos. Cada usuario de un reino puede acceder con SSO a todas las aplicaciones del mismo.

    Esta configuración se refiere a:

    • Conjunto particular de aplicaciones y web services (clientes).
    • Tema para las interfaces (login y consola de administración).
    • Medidas de seguridad (cabeceras HTTP aceptadas, detección de ataques por fuerza bruta).
    • Proveedores de Autenticación.
    • Flujos de autenticación (secuencia de pasos para autenticar cada operación del usuario).
    • Sesiones de usuarios.

  2. Configuración de la aplicación cliente en el reino correspondiente:

    Una vez configurada la aplicación cliente en el reino dentro de AUTENTICAR, se le va a enviar al responsable de la aplicación un adaptador con el objetivo de simplificar al integración.


    Adaptador

    Son módulos externos a AUTENTICAR, que se instalan en el servidor de la aplicación cliente. Hay diferentes adaptadores para distintos servidores. Los mismos proporcionan la funcionalidad necesaria para securizar una aplicación haciendo los mínimos cambios.


  3. Configuración del servidor donde se ejecuta la aplicación:

    La configuración va a depender de la tecnología del servidor. Las que están soportadas en esta plataforma son:

    • Apache HTTP Server
    • Apache Tomcat
    • JBoss EAP/WildFly
    • Proxy de Seguridad


  4. Adaptación de la aplicación cliente en sí:

    Las aplicaciones cliente deben ser modificadas, teniendo en cuenta los siguientes aspectos:

    • Configuración del cliente
    • Restricción de acceso a páginas securizadas
    • Obtención de datos del usuario logueado
    • Logout




Tecnologías Soportadas

Consideraciones generales:

  • La plataforma de AUTENTICAR está desarrollada sobre Keycloak
  • La plataforma implementa el protocolo de OpenID Connect

Disponibilizamos algunos ejemplos de integración con la plataforma en distintas tecnologías:



paper-integracion-java

Integración AC en JAVA

Descargar
paper-integracion-php

Integración AC en PHP

Descargar
paper-integracion-net

Integración AC en .NET

Descargar

paper-integracion-js

Integración AC en JavaScript

Descargar
paper-integracion-js

Integración AC en .NET Framework 4.X

Descargar
paper-cookies

Integración AC en Angular.js

Descargar

paper-integracion-net

Integración AC en PHP II

Descargar



Protocolo de Autenticación

Esta plataforma utiliza OpenID Connect como protocolo de autenticación.

OIDC es un protocolo de autenticación y autorización, basado en OAuth 2.0. Si bien OAuth 2.0 provee un framework de autorización, no especifica ningún mecanismo para que el cliente conozca la identidad del dueño del recurso. En el protocolo OpenID Connect, se agrega un ID Token implementado con JSON Web Tokens (para más información ver RFC 7519 ) que permite a la aplicación saber qué usuario fue autenticado, y provee un endpoint donde obtener más datos sobre su identidad.

Define un flujo de mensajes entre tres entidades con roles diferentes:

  • Relying Party (RP, “parte que confía”): Es la aplicación protegida, que recurre al proveedor de autenticación para autenticar a un usuario.
  • Identity Provider (IDP, proveedor de autenticación): Es un servidor que recibe la solicitud de la RP y pide autenticación y autorización al usuario.
  • End User (usuario final): Usuario que puede dar autorización a la RP. OpenID Connect expone datos de su identidad a la RP a través del endpoint UserInfo.


Flujos

El protocolo OpenID Connect define distintos flujos de autenticación, de los cuales AUTENTICAR utiliza dos:

  • Flujo estándar o de código de autorización (Standard Flow o Authorization Code Flow): Es el flujo más utilizado, ya que le permite al IDP autenticar tanto al usuario como al cliente.

    Este flujo se lleva a cabo de la siguiente manera:

    1. La RP envía un pedido de autenticación al proveedor de autenticación.
    2. El proveedor de autenticación autentica a la RP mediante el ID y el secret compartidos. Si las credenciales no son válidas, rechaza el pedido.
    3. Si las credenciales del cliente son válidas, autentica al usuario y pide su autorización, según el pedido de la RP.
    4. Una vez que el usuario se autentica, el proveedor de autenticación envía un ID token a la RP, con datos (claims) acerca del usuario. También puede enviar un token de acceso.
    5. Con el token de acceso, la RP puede usar el endpoint UserInfo de OpenID Connect para obtener claims adicionales acerca del usuario. Solamente puede pedir los datos que el usuario haya permitido ver a la RP.

  • Flujo implícito (Implicit Flow): Este flujo se utiliza en aplicaciones client-side, donde no se puede guardar un secret en forma segura.



Seguridad

Protección contra ataques de Cross Site Scripting (XSS) y ClickJacking

Las vulnerabilidades XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. XSS permite a los atacantes ejecutar secuencia de comandos en el navegador de la víctima los cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al usuario hacia un sitio malicioso. Clickjacking es una técnica maliciosa para engañar a usuarios de Internet con el fin de que revelen información confidencial o tomar control de su ordenador cuando hacen click en páginas web aparentemente inocentes.

AUTENTICAR aplica protecciones para proteger a todos los usuarios de ambos ataques anterioremente indicados.


Protección contra exposición de datos sensibles

Muchas aplicaciones web no protegen adecuadamente datos sensibles tales como números de tarjetas de crédito o credenciales de autenticación. Los atacantes pueden robar o modificar tales datos para llevar a cabo fraudes, robos de identidad u otros delitos. Los datos sensibles requieren de métodos de protección adicionales tales como el cifrado de datos, así como también de precauciones especiales en un intercambio  de datos con el navegador. AUTENTICAR permite que todas las conexiones sean seguras utilizando HTTPS con el fin de evitar que atacantes puedan capturar tráfico de red y obtener un token de acceso.  


Protección contra Redirecciones y reenvíos no validados

Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios hacia otras páginas o sitios web, y utilizan datos no confiables para determinar la página de destino. Sin una validación apropiada, los atacantes pueden redirigir a las víctimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder páginas no autorizadas. AUTENTICAR requiere que todas las aplicaciones y clientes registrados registren al menos un patrón URI de redirección. Cada vez que un cliente solicita a AUTENTICAR que realice una redirección (en el inicio de sesión o el cierre de sesión, por ejemplo), comprobará el URI de redireccionamiento en comparación con la lista de patrones URI registrados válidos.  


Protección contra Cross Site Request Forgery (CSRF)

Un ataque de CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificado, incluyendo la sesión del usuario y cualquier otra información de autenticación incluida automáticamente, a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la víctima para generar pedidos que la aplicación vulnerable piensa son peticiones legítimas provenientes de la víctima. AUTENTICAR utiliza la especificación de inicio de sesión de OAuth 2.0 para que todos los inicios de sesión estén protegidos.




Federación de Usuarios

La federación de usuarios consiste en agregar usuarios externos a una base de usuarios. Las credenciales del usuario no se guardan en AUTENTICAR, pero la plataforma provee un frontend de autenticación. Los ejemplos nativos de federación de usuarios son LDAP y Kerberos. Si se implementa un conector, se pueden federar usuarios directamente de una base de datos. Este mecanismo también se usa para los proveedores de autenticación. AUNTENTICAR genera un usuario transitorio vinculado a la identidad del mismo en el Proveedor de Autenticación (IdP) de un reino. Los datos obtenidos del IdP se cargan en este usuario federado, y se exponen a las aplicaciones cliente en el ID Token del estándar OIDC.

Por ejemplo, en el caso del reino “minmodernizacion-afip”, se tiene configurado como IdP el reino canónico “afip”, y éste a su vez con el IdP de AFIP “real”. Un usuario que se autentica en AFIP, genera una identidad federada en “afip”, y otra en “minmodernizacion-afip”. Estas identidades se cargan con los datos del usuario, que luego se exponen en el ID Token.

Es importante destacar que en ningún momento AUTENTICAR guarda las credenciales de los usuarios utilizadas para autenticarse en cada uno de los proveedores de autenticación soportados por la plataforma.




Otros Documentos


paper-cookies

Manejo de Cookies en PAEC

Descargar
paper-cookies

Flujo de Autenticación SSO entre TAD y VUCE

Descargar
paper-cookies

Flujo de Autenticación de TAD con AFIP

Descargar
paper-token

Ejemplo de Token devuelto por PAEC en caso de autenticación exitosa

Descargar