En el blog de hoy veremos cómo llevar a cabo una prueba de concepto a realizar con WSO2 Identity Server para evaluarlo y testear las diferentes características del producto.
¿Qué es WSO2 Identity Server?
WSO2 es un software abierto enfocado a proveer una arquitectura orientada a servicios (SOA) que nos permite cubrir todos los pasos del ciclo de vida de un proyecto de desarrollo. Forma parte de la plataforma WSO2 Integration Agile y se compone de los siguientes productos:
- WSO2 Api Manager: desarrollo y publicación de APIs
- WSO2 Identity Server: gestión de credenciales y protocolos de acceso a los recursos.
- WSO2 Enterprise Integration: implementación de patrones de integración empresariales (EIP)
¿Qué arquitectura utiliza WSO2 Identity Server?
WSO2 IS es un producto creado sobre WSO2 Carbon. Basado en la especificación OSGi, permite una fácil personalización y extensión a través de su arquitectura en componentes.
Además también podemos tener la instalación on-premise y en la nube, es completamente de código abierto y se publica bajo la licencia de software Apache versión 2.0. También permite crear, mantener y cancelar cuentas de usuario junto con identidades de usuario en múltiples sistemas, incluidas las aplicaciones en la nube.
Cuando hay varias aplicaciones que requieren autenticación, los usuarios deben poder iniciar sesión en un lugar y seguir teniendo acceso sin problemas a todas las demás aplicaciones.
El siguiente diagrama muestra la arquitectura de Identity Server y los diversos procesos que tienen lugar en él.
Marco de autenticación
Autenticadores de entrada
La responsabilidad de los autenticadores entrantes es identificar y analizar todas las solicitudes de autenticación entrantes y luego generar la respuesta correspondiente.
Para cada protocolo compatible con WSO2 Identity Server, debe haber un autenticador de entrada:
- SAML
- OAUTH2
- OpenId Connect
- WS-federation
Autenticadores locales
La responsabilidad de los autenticadores locales es autenticar al usuario con las credenciales disponibles localmente. Normalmente será con usurio y contraseña o IWA (autenticación integrada de Windows).
Autenticadores de salida/federados
La responsabilidad de los autenticadores federados es autenticar al usuario con un sistema externo:
- Salesforce
Un autenticador federado no tiene valor a menos que esté asociado con un proveedor de identidad (Google Apps puede ser un proveedor de identidad, con el autenticador federado SAML 2.0).
Autenticadores multifactor
El proveedor de servicios puede definir cómo autenticar a los usuarios en el servidor de identidad, es decir, cada proveedor de servicios puede definir varios pasos y para cada paso puede elegir más de un autenticador.
Marco de aprovisionamiento
Aprovisionamiento entrante
Decidirá dónde aprovisionar al usuario (a qué tienda de User Store) en función de la configuración de aprovisionamiento de entrada del proveedor de servicios.
Para esto podemos usar:
- Api SOAP
- Api SCIM 2.0, compatible con Oauth 2
Aprovisionamiento justo a tiempo
El aprovisionamiento Just-In-Time (JIT) se utiliza para almacenar usuarios temporalmente en la autenticación federada. El Service Provider inicia la solicitud de autenticación al Identity Provider, este delega en el Proveedor de Identidad externo hasta que reciba una respuesta de autenticación positiva.
Se puede elegir un UserStore específico para el JIT.
Aprovisionamiento saliente
El aprovisionamiento de salida habla sobre el aprovisionamiento de usuarios en sistemas externos.
Componentes WSO2 Identity Server
Service Provider
Un proveedor de servicios depende de un proveedor de identidad (IdP) de confianza para la autenticación y la autorización.
Un usuario del proveedor de servicios (SP) intenta iniciar sesión en la aplicación de SP. El proveedor de servicios envía una solicitud de autenticación al servidor de identidad.
El proveedor de servicios recibe la confirmación de autenticación del servidor de identidad
Claims
Se usa para especificar información que está directamente relacionada con el usuario, como atributos relacionados con la dirección postal, el nombre de usuario, el correo electrónico, el nombre, dni, etc
Algunos de estos claims suelen ser obligatorios para realizar la autenticación.
Podemos usar SCIM 2.0 para extender los claims locales que vienen en el producto
Roles
Mediante los roles podemos especificar los permisos que va a tener cada usuario, tanto para consumir recursos internos como bien poder hacer login en un Service Provider concreto.
Algunos de estos claims suelen ser obligatorios para realizar la autenticación.
Podemos usar SCIM 2.0 para extender los claims locales que vienen en el producto
User Store
- Almacen Primario. Suele haber un almacén primario, por defecto un H2, aunque se puede configurar para que sea cualquier otro tipo de DDBB como Oracle, Postgres, etc
- Almacenes Secundarios. Se puede hace la conexión con DA (Directorio Activo) o LDAP externos mediante conectores que Wso2 ya tiene preconfigurados.
Identity provider
Los proveedores de identidad realizan la autenticación.
La solicitud de autenticación proviene del componente de autenticadores internos o federados y se envía al proveedor de identidad correspondiente. El usuario se autentica e inicia sesión en la aplicación externa correspondiente.
Instalación y configuración
Para instalar Wso2 IS descargamos el fichero correspondiente a la plataforma donde queremos desplegarlo. En mi caso lo descargo el Zip y lo descomprimo.
Apuntar que hay 2 versiones que podemos instalar. La normal, en la que Wso2 IS es independiente de Wso2 AM y como Key Manager, en la que ambos sistemas están interconectados.
Antes de lanzarlo tendremos que especificar una nueva variable de entorno “CARBON_HOME” apuntando al directorio de instalación.
También hay que tener JDK de Java. La que suele funcionar mejor es la versión 1.8. Configuramos una nueva variable del sistema “JAVA_HOME” apuntando al JDK.
En el “Path” añadimos el /bin del JDK.
Una vez configurado ambos parámetros inciamos la aplicación en {{wso2}}/bin. por línea de comandos con “wso2server.bat” en sistemas Windows o “wso2server.sh” en sistemas Linux.
Esperamos a que el programa cargue completamente y cuando termine nos devuelva las url donde podremos acceder.
Extensiones
En algunas ocasiones será necesario extender la funcionalidad de wso2is, para lo cual nos proponen una serie de clases de las cuales podremos heredar y así poder implementar nuestra solución customizada. Estos desarrollos suelen hacerse mediante 2 mecanismos:
- Handlers: son extensiones de código que implementan una funcionalidad y son lanzadas mediante un trigger, es decir, como respuesta a un evento concreto.
- Listeners: al iguales que los handlers son lanzadas ante diferentes lanzadores, pero a diferencia de los anteriores son procesos que están escuchando continuamente.
Scripts: dentro de “Carbon” podemos configurar pequeños scripts en los Service Provider para que hagan una cierta lógica, por ejemplo, haciendo una autenticación adaptativa, añadiendo pasos o configurando MFA (autenticación multifactor).
Ficheros importantes
En algunos casos no podremos realizar ciertos tipos de configuración en Carbon, por lo que será necesario tocar algunos ficheros, por ejemplo para la configuración de email, claims externos, etc. Esta configuración tendremos que realizarla en los siguientes ficheros:
- {{wso2is}}/repository/conf/deployment.toml: configuración general (email, cors, tenant, custom user store, etc)
- {wso2is}}/repository/conf/log4j2.properties: logs del sistema (podemos cambiar entre los diferentes niveles de logs (INFO, WARM, DEBUG) y añadir nuevos logs para desarrollos propios).
- {wso2is}}/repository/conf/scim2-schema-extension.properties: para añadir claims externos que no corresponden a ningún LDAP o DA, por lo cual hay que añadirlos de manera independiente.
{wso2is}}/repository/components/dropins: ubicación para las extensiones que hayamos desarrollado mediante maven. Se añadira el .jar final. En ocasiones la ubicación será en /components/lib, dependiendo si se usa OSGi o no.
Flujos de autenticación
Mediante el siguiente diagrama se intenta explicar un flujo de autenticación básico mediante Wso2 IS, en el cual configuramos una aplicación externa como Service Provider, linkeados ambas mediante protocolos de seguridad (SAML, OAUTH2) y url de entrada (assertion) y salida (callback).
- Cuando un usuario intenta hacer Login en su app, automáticamente esa url es capturada por wso2is, siendo redirigido a la pantalla de autenticación de wso2.
- El Service Provider delegará estas credenciales al Identity Provider, el cual buscará dentro de los User Store configurados que el usuario tiene los permisos (Roles) necesarios y configurado los Claims configurados como obligatorios para poder ingresar en dicha app.
- En este caso el Service Provider, redigirá al usuario hacia la url de salida configurada anteriormente.
Enlaces de interés
¡Contacta con nosotros!
Author