Cuando se gestionan varias aplicaciones para un mismo grupo de usuarios (como suele pasar en la mayoría de las empresas), es un verdadero fastidio tener que identificarse en cada una de las distintas aplicaciones, más aún cuando en cada una los criterios de acceso son completamente distintos: en uno se identifica con email, en otro con un nombre de usuario, diferentes contraseñas, etcétera.
Para solventar este problema, la mejor opción es crear un único acceso y una vez el usuario se haya identificado, podrá acceder a todas las aplicaciones a las que tenga acceso.
Para quien todavía no entiende de lo que estamos hablando, el ejemplo más conocido es Google. Una vez que te identificas con tu cuenta de Google, tienes acceso a todos sus sitios y aplicaciones: Gmail, Youtube, Maps, Analytics, etcétera.
Además, lo mejor de todo esto, es que al tener nuestros usuarios centralizados en una sóla base de datos, tendremos una mejor gestión y monitorización sobre todos los usuarios del sistema, evitando también los fallos de seguridad que puedan existir en los procesos de autentificación en alguna de nuestras aplicaciones.
En esta serie de artículos os vamos a mostrar como crear este sistema de acceso único desde cero. Pero en el artículo actual, sólo vamos a hacer una introducción sobre qué tecnologías y metodologías vamos a utilizar para crear este sistema.
Como nuestro sistema será una API REST, podremos integrarlo con cualquier tipo de aplicación: web, móvil, escritorio, etcétera.
¿Qué podrá hacer nuestro sistema?
Nuestro sistema gestionará lo siguiente:
- Usuarios
- Crear / Editar / Eliminar
- Habilitar y deshabilitar cuentas de usuario.
- Búsqueda de usuarios
- Recuperar contraseñas
- Validación contra servidor LDAP (Active Directory)
- Roles de usuarios (API)
- Administrador
- Usuario genérico
- Aplicaciones
- Roles de los usuarios en las aplicaciones
- Datos adicionales de los usuarios necesarios para las aplicaciones
- Si por ejemplo en una de nuestras aplicaciones necesitamos guardar y conocer el «Centro de trabajo» del usuario actual, este dato lo podemos guardar en la base de datos de nuestra aplicación y sincronizarlo con nuestra API. Así, si modificamos este dato en cualquier usuario desde el sistema, la API sincronizará los cambios en la base de datos de la aplicación y viceversa.
¿Y cómo va a funcionar todo esto?
La forma rápida de explicarlo sería así:
Todas nuestras aplicaciones preguntarán en cada petición a nuestro sistema de acceso único si el usuario es válido (está autentificado) y tiene permisos de acceso a dicha aplicación.
Representación gráfica (click para ampliar)
Y ahora vamos a entrar un poco más en detalle:
Para poder crear un login único en todas las aplicaciones se utiliza un proceso de autentificación llamado JWT (Javascript web tokens).
¿Cómo funciona el proceso de autentificación?
Los usuarios se identifican a través de un Front-End en el que aparece un formulario de login.
Cuando se envía el formulario, el Front-End hace una petición a la API para comprobar si las credenciales proporcionadas por el usuario son correctas.
En el caso de que las credenciales sean correctas, se crea una cookie en el navegador que contiene el JWT (en el caso de las aplicaciones web), la cual es válida para todos los subdominios de nuestro dominio *.albertolabs.com.
¿Cómo saben las aplicaciones si mi cookie es válida?
Las aplicaciones que están integradas, comprueban en cada petición si el JWT que contiene la cookie es válido preguntando a la API.
Para que el JWT sea válido, se deben cumplir ciertas condiciones previamente definidas:
- Que el JWT se haya generado desde el servidor / RSA Public / Private keys.
- El usuario tiene que estar habilitado (tanto en la bbdd de la API).
- El usuario debe tener acceso (un rol asignado) a la aplicación a la que se accede.
Si el JWT es válido y se cumple lo mencionado anteriormente, podemos acceder a la aplicación, de no ser válido, nos enviará al Front-End para que nos identifiquemos.
¿Qué información contiene el JWT?
El JWT contiene la información básica del usuario que proporciona desde la tabla Users en la base de datos de la API.
También incluye el listado de aplicaciones a las que el usuario tiene acceso junto con su rol correspondiente.
Ejemplo del contenido de un JWT:
{ "id": 13, "type": "api", "username": "albertolabs", "email": "info[at]albertolabs[dot]com", "role": [ "ROLE_SUPERADMIN" ], "name": "Alberto", "surnames": "~", "avatar": null, "apps": { "intranet": { "role": "ROLE_SUPERADMIN" }, "issues_portal": { "role": "ROLE_SUPERADMIN" } }, "exp": 1495034731, "iat": 1495002331 }
En el próximo artículo comenzaremos con la parte técnica y con el desarrollo de nuestra API.
A young developer from Madrid who loves programming and computing. Constantly testing with new technologies and thinking in new projects and challenges.