Bienvenido a la nueva sección del blog dedicada a WSO2 Identity Server, una herramienta revolucionaria para asegurar la seguridad y correcta gestión de identidades de cualquier empresa. Tanto si ya habías escuchado algo sobre la herramienta, como si no, este tutorial introductorio de WSO2 Identity Server te ayudará mucho a conocerlo más profundamente. ¿Te animas?
Te presentamos el primer tutorial de WSO2 Identity Server (IS):
Introducción sobre WSO2 Identity Server
Tal y como comentábamos al comienzo estrenamos una nueva sección en el blog dedicado a un tema apasionante, como es el de la seguridad empresarial y a su gestión. Para ello utilizaremos una brillante herramienta como es Identity Server (IS) de WSO2.
Antes de adelantarnos en esta solución, debemos conocer muy bien qué es y cuáles son las partes que la componen.
El Identity Server es un servidor que gestiona de manera segura identidades tales como empleados, proveedores, socios, clientes, etc (cualquier tipo de información que pueda guardarse en una base de datos como entidad tiene una identidad); y accesos entre sistemas y aplicaciones, con la posibilidad de utilizar un acceso único y sin necesidad de repetir credenciales cada vez que un usuario necesita usar un Proveedor de Servicios.
Como gestor de identidades y proveedor de identidad posee un almacén de directorios y usuarios, autenticación de los mismos con su correspondiente nombre y contraseña, o con el método del second factor, autorización de usuarios para gestionar los permisos de acceso a ciertos recursos una vez autenticados; Single sign on, para logarse una vez en una aplicación y tener acceso al resto de aplicaciones,;provisioning, para poder dar de alta usuarios en el almacén de usuarios de manera automática, delegación de acceso o autenticación federada, reinicio de claves de acceso, auto registro en el gestor, bloqueo de cuentas y mucho más…
Partes que componen el WSO2 Identity Server
Como se aprecia en el diagrama hay tres partes bien diferenciadas, el Identity Server (IS) y los autenticadores locales, cuya función es autenticar el usuario con credenciales locales.
La parte izquierda la podríamos interpretar como los proveedores de servicios o Service Providers (SP), y la derecha como los proveedores de identidad federados o Identity Providers (IdP) externos al IS.
Quizá pueda parecerte un tanto difuso el diagrama con tanta información, ¡pero tranquilo! a lo largo de toda la serie de posts dedicados a Identity Server (IS) te quedará mucho más claro. Por ello, te aconsejamos que siempre lo tengas presente en tu mente como un punto de referencia, o al menos guardado en tu pc. Ahora ya es momento de entrar en materia, vamos por partes:
Autenticadores en el framework de autenticación
Autenticadores de entrada
Estos autenticadores analizan la request de autenticación de entrada y construyen la respuesta de salida. Están constituidos por dos partes, el Procesador de solicitud y el Generador de respuestas (Request Processor, Response Builder).
Este componente está ligado a distintos protocolos dependiendo del protocolo de petición de autenticación usado por el Proveedor de Servicios. Es decir, tenemos el protocolo: SAML SSO, OAuth, Open ID Connect (construido sobre el OAuth) y el Passive STS, tal y como se puede apreciar en el diagrama.
Por ejemplo cuando al Request Processor le llega una request de autenticación la analiza para descubrir el protocolo de autenticación que usa el SP. Si es una SAML request, la petición se redirige al SAML 2.0 Request Processor. Éste valida la solicitud y genera un Component Object Model (COM) y lo reenvía junto con la request al Authentication Framework.
El Response Generator, en nuestro ejemplo el SAML response builder, recibe del Authentication Framework otro COM y genera una SAML response a partir de ese objeto.
Autenticadores locales
La responsabilidad de los autenticadores locales es autenticar al usuario con las credenciales disponibles localmente.
La autenticación se puede hacer con el nombre de usuario/contraseña, con IWA (Autenticación de Windows integrada) o por medio del request-path authenticator, donde las credenciales viajan como parte de la los parámetros en la uri de la request.
La request de petición de autenticación es redirigida desde los autenticadores de entrada (Inbound Authenticators) al Authenticator Framework. Ahora este componente se comunica con un Service Provider configurado en el IS para buscar los autenticadores locales registrados con el Service Provider correspondiente a la petición de autenticación.
Cuando la autenticación ha finalizado con éxito, el autenticador local notifica al Authenticator Framework y éste, según la configuracion que tenga, puede seguir enviado la petición o request a más tipos de autenticación, en caso de que lo tenga configurado de este modo. Al final del proceso este componente envía la response o respuesta al Response Builder del Inbound authenticator.
Autenticadores salientes/federados.
Este componente autentica los usuarios por medio de un Identity Provider (IdP) externo al IS, por eso es federado.
Los IdP pueden ser: Facebook, Google, Yahoo, LinkedIn, Twitter, SalesForce, Shibboleth, etc.
La request de autenticación le llega al Authenticator Framework. Éste consulta la configuración del Service Provider. Si hay alguna autenticación federada configurada, reenvía la petición al autenticador federado correspondiente. Este está ya asociado por medio de la configuración del SP a un IdP externo. Los tipos de protocolos de autenticación que maneja este componente son: Security Assertion Markup Language (SAML) 2.0, OpenID Connect, Oauth 2.0 y WS-Federation (passive).
El componente Request Builder se se encargará de construir la request de autenticación según el tipo de protocolo configurado y la envía al IdP.
Este mismo más tarde procesa la response y construye otra dirigida al Authenticator framework. Los componentes que gestionan la petición/respuesta son: Request Builder y Response Processor.
Tanto en las autenticaciones locales o federadas el SP puede usar dos estrategias:
- Autenticadores multi-opcionales, donde el SP tiene múltiples opciones de inicio de sesión.
- Autenticadores multi-factor, donde el SP está configurado para definir varios pasos de autenticación.
Framework de aprovisionamiento
El framework de aprovisionamiento está formado por los siguientes componentes:
Aprovisionamiento de entrada
El aprovisionamiento de entrada gestiona el alta de nuevos usuarios en el User Store. Se puede realizar por medio de llamadas SOAP al IS o con las Apis del SCIM (System for Cross-domain Identity Management).
El aprovisionador de entrada se configura asociándolo a un SP residente donde se indica en qué User Store se guardan los nuevos usuarios. Ambas APIs usan HTTP Basic Authentication, y SCIM usa también Oauth protocol. El Oauth client id de la request está asociado al SP configurado en el IS.
Aprovisionamiento justo a tiempo o Just-in-time provisioning
Este componente hace lo mismo que el anterior, es decir, dar de alta de manera automática usuarios al User Store, pero para aquellos usuarios que se hayan logado de manera satisfactoria en un IdP externo. Debes saber que todo esto sucede en medio del proceso de autenticación.
-No te pierdas este post: “Las principales soluciones para la gestión de identidades y accesos”-
Aprovisionamiento de salida
Gestiona la provisión de usuarios en sistemas externos. Todas las peticiones de aprovisionamiento están iniciadas por un SP que está asociado con un IdP, y se configuran en la sección de Outbound Provisioning del SP.
El Service Provider (SP)
Aunque no forma parte del IS sí debe configurarse en el mismo.
El Service Provider es un proveedor de servicios, es decir, provee de servicios Web. Pero para ello necesita de alguna manera proteger esos servicios por medio de una autenticacion y autorizacion. ¿Cómo lo logra?te preguntarás. Pues fácil se sirve del Identity Provider (IdP) del IS o de uno externo si es federado. Cuando un usuario intenta usar un servicio web del SP trata de logarse en el SP.
La request de autenticación se envía desde el SP al IS. El autenticador de entrada o Inbound authenticator recibe la request que sigue uno de estos formatos: SAML SSP, Oauth/OpenID connect, Passive STS. Este componente envía la respuesta a la petición de autenticación al SP, como positiva o negativa. Además si el usuario se registró en el SP, podrá enviar una request al IS por medio del protocolo SOAP o SCIM al componente Inbound Provisioning, para dar de alta el mismo usuario en el IS.
Framework de autenticación.
Otra de las tareas interesantes de este componente, además de las que ya hemos comentado, se encuentra en la gestión de claims.
Un claim es cualquier tipo de información de la entidad que se guarda en el user store que se intercambia entre sistemas, pudiendo ser: email, teléfono, nombre, apellidos, género, etc. Esta información se mapea o se relaciona con los claims del SP y del IdP.
El componente JIT inscribe al vuelo usuarios dados de alta en el SPy en el IS. Este componente manda la petición de activación al Provisioning Framework o Framework de Aprovisionamiento.
Proveedores de identidad o aplicaciones externas
Tampoco es un componente del IS pero es necesario conocerlo para poder configurarlo correctamente en la herramienta. Los IdP realizan autenticación, la misma que realiza el IdP interno al IS pero por medio de una aplicación externa como puede ser: Facebook, Google, etc.
El IdP necesita también algún tipo de configuración para habilitar la posibilidad de recibir peticiones de autenticación por parte del IS. Los protocolos de autenticación usados aquí son: (SAML2, OpenID Connect, WS-Federation (Passive)). Otro dato importante, es que una sola solicitud de autenticación puede requerir la autenticación en más de un IdP.
Manager de autorizaciones.
Proporciona gestión de derechos para cualquier llamada REST o SOAP. Este componente se relaciona con otros como el XACML, WS-Trust, OpenID Connect y gestión de claims para el control de acceso. También proporciona control de acceso basado en roles (RBAC) y en políticas detalladas a través de XACML.
En esta gestión de autorización se incluye la edición de políticas de seguridad en las que se incluye conceptos como el Punto de Información de Política (PIP) y Puntos de Decisión de Política (PDP).
Administrador del almacén de usuario
Este componente gestiona la persistencia de los usuarios/roles y perfiles de los mismos en la base de datos.
Este repositorio puede ser el LDAP interno de WSO2 (powered by ApacheDS), o uno externo LDAP, Microsoft Active Directory, o cualquier base de datos JDBC como puede ser Mysql o Oracle.
Por medio de un conjunto de APIs se puede acceder al User Store.
El Identity Server a través de su UI facilita la gestión de usuarios gracias a una serie de menús para crear usuarios, roles y perfiles.
El Administrador de usuarios también recibe peticiones de aprovisionamiento desde el Framework de Aprovisionamiento.
A continuación se actualiza el User Store con un nuevo usuario o modificación. Debes saber que este proceso puede afectar a más de un User Store.
Finalmente se envía la respuesta al Framework de Aprovisionamiento. Este componente también puede recibir peticiones de aprovisionamiento desde un SP a través de llamadas SOAP o con el protocolo SCIM.
Estas peticiones van hacia Inbound Provisioning y desde este al User Store Manager.
El User Store Manager recibe la solicitud de aprovisionamiento, actúa sobre ella y la envía al Framework de aprovisionamiento donde a su vez debe enviarse hacia el Aprovisionamiento Saliente, Outbound Provisioning.
Gestor de Claims
Como comentábamos, el claim almacena información relacionada con un sujeto o identidad.
Los claims son una forma muy común de transmitir datos de las identidades. Esta información puede ir empaquetada en tokens, como en el SAML, emitidos por un emisor como el Servicio de Token de Seguridad o Security Token Service (STS). Este componente está relacionado con: Authentication framework, Authorization manager, Provisioning framework y User store manager.
XACML
XACML o Lenguaje de marcado de control de acceso extensible (eXtensible Access Control Markup Language). Es un lenguaje para describir una política de control de acceso (quién puede hacer qué y cuándo) de grano fino que se configura en un archivo xml y está estandarizado por OASIS (https://www.oasis-open.org).
El lenguaje de solicitud/respuesta expresa consultas sobre si se debe permitir un acceso particular (solicitudes) y describe las respuestas a esas preguntas (respuestas).
Auditoría
Por medio de este componente se puede supervisar operaciones privilegiadas procesadas por el sistema, accesos, autenticación, rendimiento y sesiones de usuario.
Manager de Identidad
Este componente va a facilitar la flexibilidad necesaria de una herramienta de seguridad como es el IS para poder extenderse con nuevos componentes de seguridad y así estar preparado para responder a las necesidades actuales de las empresas. Está relacionado también con el User Store Manager.
Conclusión
Como hemos comentado al comienzo, se trata del primer post-tutorial sobre WSO2 Identity Server, muy introductorio. No te preocupes si no se explicó todo en profundidad, pues esto será todo lo que haremos en las siguientes publicaciones sobre IS. Si tras este post te parece una solución muy completa para la seguridad e integridad empresarial a nivel global, a medida que descubras nuestros siguientes artículos, aún te lo parecerá más.
Antes de finalizar nos gustaría destacar que el IS es la herramienta más compleja y costosa de WSO2, puesto que entre otras cosas es la que siempre debe estar actualizada y al día de los posibles agujeros de seguridad. Sin duda es una solución muy valiosa que toda compañía debería tener en su repertorio de aplicaciones empresariales de gestión de la seguridad. Identity Server (IS) además de ser muy flexible, es perfecta para garantizar por medio de interfaces la adaptabilidad a la lógica de seguridad cambiante de las empresas.
¿Te ha gustado nuestro primer capítulo tutorial dedicado a WSO2 Identity Server ? Si es así, estate atento a nuestro próximo post en el que entraremos de lleno en la web del Identity Server.
¡Hasta la próxima!
