¡Bienvenido a un nuevo post de la sección WSO2 Identity Server! En esta primera parte del tutorial aprenderemos todo esto:
Introducción
En esta entrega navegaremos por la herramienta Identity Server o servidor de identidad, a través de algún ejemplo o caso de uso relacionado con la vida real.
También aprenderemos cómo la herramienta responde a la gestión y seguridad de identidades, además de mostrar la flexibilidad necesaria para mostrar datos estadísticos sobre el login de Proveedores de Servicios, información sobre la sesión, autenticación federada y muchas cosas más.
Caso de uso
Comenzamos con el ejemplo de una empresa, Chakray, que quiere administrar usuarios y accesos de aplicaciones por parte de personal interno y externo. Gran parte de dichas aplicaciones contienen información sensible que se debe proteger, puesto que en cada aplicación hay usuarios, roles y permisos.
El aprovisionamiento de usuarios debe ser rápido, así como proteger las interacciones entre aplicaciones. También debemos considerar el poder usar un sistema de logado único con el fin de no estar repitiendo las credenciales cada vez que el usuario quiera usar una determinada aplicación en el sistema.Frente a esto se decide usar WSO2 Identity Server.
Además, los administradores del sistema en Chakray deben configurar los análisis para el Servidor de Identidad WSO2 y así proporcionar la información solicitada por la administración superior para monitorear las estadísticas de sesión y autenticación. Para esta tarea se decide utilizar WSO2 Identity Server Analytics.
Instalación de Identity Server
La idea es desplegar en contenedores Docker el Tomcat, Identity Server e Identity Server Analytics:
Para la instalación haremos uso del repositorio de imágenes de Docker de WSO2. Esta es la uri: https://hub.docker.com/u/wso2/ o en esta otra: https://docker.wso2.com/
El recuadro rojo muestra la imagen que necesitamos descargar. Si pulsas DETAILS sobre la misma línea, aparecerá una breve descripción del contenedor del IS.
-Este post te interesa: WSO2 Identity Server, el siguiente paso de las soluciones de IAM-
El primer recuadro rojo muestra la etiqueta Tags donde se guardan las distintas versiones del Identity Server. A la derecha está el comando docker que vamos a usar para instalar la imagen del IS en nuestro equipo. Si pulsas Tags:
La última versión es la 5.7.0. Ahora desde la línea de comandos podemos descargarnos el contenedor. Hay que hacer un pull de la imagen indicando la versión que queremos instalar, en este caso la: 5.7.0
Al final de la descarga, Docker nos informa de la finalización de la instalación de la nueva imagen. La nueva imagen se lista en el siguiente pantallazo:
Ejecución de la imagen en un contenedor
Ahora se puede ejecutar la imagen en un contenedor. La línea de comandos se muestra abajo:
Como se muestra, el nombre del contenedor se indica con el parámetro –-name. Este otro -d ejecuta el contenedor en segundo plano e imprime ID o identificador del contenedor.
Ahora solo queda comprobarlo en el browser con la uri: https://localhost:9443
Ahora ya hemos ejecutado WSO2IS en un contenedor, ¡sigamos!
-Descubre más: Identity Management: tendencias y mejores prácticas-
Comandos de Docker
A continuación mostraremos la salida de algunos comandos importantes. Si deseas iniciarte en el aprendizaje de Docker, escribe los mismos comandos que estamos explicando con el ejemplo del contenedor de WSO2IS y viendo su salida.
El formato que debes escribir es el siguiente:
$docker [Opciones] Comando
docker ps: muestra los contenedores que se están ejecutando.
docker exec -it wso2is-570 bash: Esto es para ejecutar un comando en un contenedor que está activo. -it permite abrir una ventana de comandos con el contenedor. wso2is-570 es el nombre del contenedor que se está ejecutando. bash es la shell de Unix.
docker inspect wso2/wso2is:5.7.0: Retorna informacion a bajo nivel del contenedor del IS. El listado es muy largo para ponerlo en el blog, pero no te preocupes ¡lo analizaremos en los siguientes posts de esta sección!
docker port wso2is-570: Muestra el mapeo de puertos del contenedor. <Host -> Contenedor>
docker container logs wso2is-570: Busca y visualiza los LOGS de un contenedor
Sí, hay más comandos pero los veremos en siguientes capítulos, no te adelantes.
Directorios clave en el Identity Server
Si accedemos dentro del contenedor, podemos navegar entre carpetas para ir descubriendo los directorios más importantes de la herramienta. Como ya sabemos:
$docker exec -it wso2is-570 bash
bin: esta carpeta contiene todos los archivos ejecutables, incluidos los scripts que se utilizan para iniciar/detener la aplicación en entornos Linux y Windows, por ejemplo,: wso2server.sh y
wso2server.bat.
-Leer más: Cómo construir tu estrategia de control de accesos y gestión de identidades-
dbscripts: una colección de scripts de base de datos necesarios para crear la base de datos Carbon y la base de datos específica de WSO2 IS en una variedad de sistemas de administración de bases de datos.
lib: el directorio lib contiene todos los archivos jar que se convertirán en paquetes OSGi al inicio del IS y se copian en el directorio de Dropins.
modules: todos los objetos host que pertenecen al módulo Jaggery se declaran dentro de la carpeta de módulos en un archivo llamado module.xml.
repository: el repositorio principal para todo tipo de implementaciones y configuraciones Carbon. Esto incluye todos los servicios predeterminados, API creadas, configuraciones Carbon, etc.
resources: contiene recursos adicionales que pueden ser utilizados por WSO2 IS.
tmp: contendrá archivos temporales que se crean cuando se ejecuta un producto. Estos archivos se borrarán de vez en cuando según las tareas de mantenimiento.
Archivos de configuración clave
<IS_HOME>/repository/conf/carbon.xml
Tomamos el archivo de configuración del servidor Carbon. Se configura por ejemplo, el nombre del producto y la versión, el nombre Host donde se está ejecutando el servidor IS, los puertos usados, información sobre el LDAP interno, y muchos más detalles que ampliaremos más adelante.
<IS_HOME>/repository/conf/datasources/master_datasources.xml
Aquí es donde se configuran las fuentes de datos, es decir, donde se guardan los orígenes de datos que almacenan las tablas del IS.
<IS_HOME>/repository/conf/identity/identity.xml
En este archivo se configura la gestión y protección de la identidad, con protocolos como el OpenID, OAuth, SAML2 Grant type, OpenIDConnect, Autenticación multifactor, el servicio SSO, configuración de derechos, Autenticadores SCIM.
<IS_HOME>/repository/conf/log4j.properties
El archivo de configuración de la herramienta log4java usada por el servidor para la generación de trazas durante el funcionamiento de la herramienta.
<IS_HOME>/repository/conf/registry.xml
Con él se configura el registro interno. Dicho registro se usa como si fuera un directorio de carpetas para almacenar recursos, como pueden ser archivos.
Estos recursos se pueden cachear en memoria, se puede proteger en modo solo lectura, pueden implementar manejadores de los recursos. También es posible usar registros remotos, base de datos donde se guarda la información de este componente y sus recursos.
<IS_HOME>/repository/conf/user-mgt.xml
La configuración del gestor de usuarios de realiza en este archivo: nombre de usuario, rol y password del administrador, almacén donde reside el usuario administrador, configuración del gestor del almacén de usuario y gestión de la autorización.
<IS_HOME>/repository/conf/security/secret-conf.properties
La configuración del administrador secreto que utiliza el componente Secret Vault.
El almacén de claves y el repositorio secreto (Vault) se pueden configurar a través de este archivo. Todas las contraseñas en los archivos de configuración xml de la herramienta se hacen seguras al protegerlas usando texto cifrado. Cuando se encripta una contraseña, se requiere un almacén de claves para crear la criptografía de descifrado para resolver los valores secretos encriptados. Para ello utilizaremos el archivo secret-conf.properties.
Configuración SP, Identity Server y Analytics
En esta demo vamos a descargar la imagen del IS Analytics y conectarlo al IS. Esto es todo lo que haremos:
Como se puede ver en el gráfico, todas las acciones de autenticación generadas por el Service Provider (Travelocity) van a ser trazadas por el Identity Server. Los datos recogidos a través de eventos se enviarán al Identity Analytics para guardarlos y mostrarlos de una manera gráfica.
IS Analytics y el IS
1.Descarga de la imagen IS Analytics
Como ya sabemos, vamos a descargar la imagen de: https://hub.docker.com/u/wso2/
Pulsamos el botón DETAILS, tal y como se ve en la imagen.
Para la descarga hay que usar la línea de comandos que muestra el recuadro rojo:
$ docker pull wso2/wso2is-analytics
Usaremos la última versión, esa está expuesta en la opción: Tags que muestra la flecha roja. Si pulsamos sobre esas letras:
En el recuadro rojo aparece la última versión: 5.6.0. Por tanto, la línea de comandos para descargar la imagen quedaría del siguiente modo:
$ docker pull wso2/wso2is-ana:5.6.0
Como siempre primero debes intentar hacer el login para poder descargar desde el hub:
Ahora descarga la imagen:
Ya está lista en el repositorio local:
2.Habilitar Analytics en WSO2 IS
Para habilitar la publicación de eventos debemos meternos en el contenedor del IS como root:
$docker exec -u 0 -it wso2is-570 /bin/bash
Y abrimos en modo edición el archivo:
<IS_HOME>/repository/conf/identity/identity.xml
- Habilitar el listener: AuthnDataPublisherProxy
Este es el detector de eventos común para todos los tipos de análisis admitidos en WSO2 IS.
Este listener captura todas las estadísticas enviadas a WSO2 IS Analytics como eventos, y las redirige al oyente/listener relevante según su tipo. Esto es necesario para habilitar tanto el análisis de sesión, como el login.
Habilitar el listener: DASLoginDataPublisherImpl
Habilita este listener solo si deseas analizar estadísticas relacionadas con los inicios de sesión o logins a través de WSO2 IS.
- Habilitar listener: DASSessionDataPublisherImpl
Si quieres analizar estadísticas para sesiones específicas en WSO2 IS Analytics, este es el listener que debes habilitar.
Como puedes comprobar, siempre que quieras habilitarlo debe poner true el parámetro enable.
3.Configurar publicadores de eventos
Todos los publicadores de eventos relacionados con WSO2 IS Analytics se encuentran en el directorio <IS_HOME>/repository/deployment/server/eventpublishers
Ahora configuraremos los publicadores de eventos. Para configurar el análisis de login y sesión debe usar estos archivos:
<IS_HOME>/repository/deployment/server/eventpublishers/
IsAnalytics-Publisher-wso2event-AuthenticationData.xml
<IS_HOME>/repository/deployment/server/eventpublishers/
IsAnalytics-Publisher-wso2event-SessionData.xml
Respectivamente.
- IsAnalytics-Publisher-wso2event-AuthenticationData.xml
receiverURL: Es el punto final al cual van dirigidos los eventos desde el IS. El formato es: tpc://<HOSTNAME>:<THRIFT_PORT> o para múltiples receptores: {tcp://<HOSTNAME>:<PORT>,tcp://<HOSTNAME>:<PORT>,…}
Ejemplo:
username: Esto es el nombre de usuario del listener.
password: Password del listener.
protocol: Protocolo que se emplea para enviar/publicar los eventos.
publishingMode: Publicación asíncrona=> non-blocking
Publicación síncrona => blocking
publishTimeout: Hace referencia al tiempo de espera para el modo de publicación sin bloqueo. Es entero positivo.
ssl: URL del autenticador. No incluido por defecto. Cuando no se incluye, la URL del autenticador se obtiene agregando 100 al puerto thrift. El formato es: ssl://<HOSTNAME>:<SSL_PORT>. Ejemplo: ssl://localhost:7712
- IsAnalytics-Publisher-wso2event-SessionData.xml
En nuestro caso el valor de receiverURL es el nombre del contenedor que ejecuta el IS-Analytics: wso2is-analytics, es decir:
-¿Todavía no has leído nuestra guía sobre Identity & Access Management? Descúbrela aquí-
4. Cambiar el password de administrador
Si deseas cambiar el password de administrador se debe escribir en texto plano en los publicadores de eventos, parámetro: password. Tal y como se puede comprobar en las dos imágenes anteriores.
Otro dato importante es que si has cambiado de keystore en el IS Analytics debes importar la clave pública (certificado publico) en el IS, en el archivo: client-truststore.jks
5. Ejecutar los servidores
Si has hecho cambios en el servidor IS debes parar el contenedor y reiniciarlo.
Para ejecutar el IS-Analytics:
$ docker run –name wso2is-analytics -d -p 9444:9444 wso2/wso2is-analytics:5.6.0
Utilizamos esta vez el puerto 9444 por que el puerto 9443 está ocupado por el IS. Ahora en el explorador usar la uri: https://localhost:9444/carbon/admin/index.jsp ¡Y podrás comprobar el IS-Analytics en acción!
A estas alturas ya tenemos los dos contenedores ejecutándose: el IS y el IS-Analytics.
Redes en Docker
Cuando inicias un contenedor, realmente lo que sucede es que en segundo plano estás conectado a una red Docker en particular. De forma predeterminada, esa es la red bridge.
Posteriormente, cada una de esas redes a las que te puedes conectar, enruta las peticiones a través de un firewall NAT, que en realidad es Docker que configura la dirección IP del host en su interfaz predeterminada. Así, sus contenedores pueden acceder a Internet o al resto de su Red para posteriormente volver.
Todos los contenedores en una misma red virtual pueden comunicarse entre ellos sin usar el parámetro: -p.
Siguiendo las buenas prácticas deberíamos crear una red virtual para cada aplicación y todas las relacionadas. Se puede crear una red virtual para el Service Provider (Travelocity), el Identity Server con el Identity Server Analytics. De este modo pueden hablar o conectarse entre ellas sin problema.
Si visualizamos las redes configuradas en Docker:
Vemos que una de las redes virtuales por defecto es esa: bridge.
Si inspeccionamos esa red veremos los dos contenedores mencionamos anteriormente.
En el apartado Containers se aprecian los nombres de los dos contenedores y la dirección IP asignada. El problema es que cada vez que se reinicia un contenedor, Docker le puede asignar una dirección IP distinta.
Por tanto, es un antipatrón utilizar la IP de un contenedor para comunicarse con otro. Docker utiliza el nombre del contenedor, como el equivalente al Host name, para comunicar a través de la red virtual diferentes contenedores, lo hace con el demonio DNS. Si usamos la red virtual por defecto default hay que emplear el parámetro –link para enlazar un contenedor a otro para que se puedan comunicar sin problema, ya que en esa red por defecto Docker no usa el demonio DNS. Debemos hacer esto cada vez que se arranca el contenedor. Una forma de evitar este problema es creando una nueva red virtual, ya que al crear una nueva red, Docker crea ese demonio DNS.
Siguiendo ahora con las buenas prácticas nuestro diseño, creando una nueva red, quedaría del siguiente modo:
PVN-SP-IS: Private Virtual Network Service Provider/Identity Server.
Para ello, creamos la nueva red: $docker network create pvn_sp_is
Ahora debemos conectar el IS y el IS-Analytics a la nueva red:
Si inspeccionamos la nueva red vemos que están los dos contenedores:
Las redes virtuales están conectadas al interface Ethernet del host. Cada vez que se envía una request a: localhost:8888 ésta se enruta hasta la red virtual que contiene el proceso escuchando en ese puerto, como se puede ver en la siguiente imagen. Tiene que especificar -p para que las requests alcancen el contenedor conectado a la red virtual.
Ahora tan solo nos falta añadir el service provider o proveedor de servicios, en nuestro caso hemos escogido Travelocity.
Service Provider
Este servicio lanza las peticiones de login con el protocolo SAML hacia el Identity Server. Estas acciones de éxito o fracaso en el logado se registrarán después en el Identity Server Analytics.
Para ello primero descargamos Travelocity, nuestro Service Provider, configuramos la conexión al Identity Server y después configuramos en el IS el nuevo Service Provider.
Descarga desde el repositorio
Primero debes crear una carpeta en tu sistema para descargar en ella los ejemplos del Identity Server, con Travelocity incluido.
Dentro de la nueva carpeta hay que iniciar el nuevo Git repository. Nuestra carpeta tiene ahora un repositorio vacío en /.git/ (el repositorio es una carpeta oculta donde opera Git.)
Ahora configuramos en nuestro git local el repositorio que queremos descargar:
$ git remote add -f origin https://github.com/wso2/product-is.git
git-remote – Administrar un conjunto de repositorios rastreados.
add -f – Añade el nuevo repositorio desde el origen a nuestra carpeta. Con la opción -f, git fetch <nombre> se ejecuta inmediatamente después de configurar la información remota. Y el comando git fetch <nombre> se puede usar para crear y actualizar las ramas de seguimiento remoto <nombre> / <branch>.
Habilitar la opción sparseCheckout:
Sirve para descargar del repositorio solo los archivos que queremos usar, y no todos los documentos. Y es ahora cuando le decimos a Git qué cosas queremos descargar. Se hace en el directorio /ISSamples/.git/info. En nuestro caso queremos descargar la carpeta: modules/samples/
En el archivo sparse-checkout se escribe la carpeta o archivos que queremos descargar del repositorio.
Ahora vamos a la carpeta donde estábamos originalmente, es decir: $ cd ../..
Ahora nos descargamos el contenido del repositorio desde la rama: v5.5.0 a otra rama local con el mismo nombre.
Como se aprecia en la imagen se ha producido la descarga de la carpeta que le indicamos anteriormente: modules/samples/. Nuestro ejemplo de Service Provider está dentro de la carpeta: /modules/samples/sso.
Configuración del Service Provider
Ahora hay que configurar Travelocity (nuestro Service Provider) para poder conectarse al Identity Server y poder enviar las peticiones de autenticación SSO por medio del protocolo SAML (Single Sign On – SSO), se trata del inicio de sesión único basado en un navegador web.
Como ya sabíamos, el inicio de sesión único es una característica clave de WSO2 Identity Server que permite a los usuarios acceder a múltiples aplicaciones utilizando el mismo conjunto de credenciales. Además, el usuario puede acceder a todas estas aplicaciones, sistemas y plataformas, sin necesidad de iniciar sesión en cada una individualmente.
Por ejemplo, si los usuarios inician sesión en la aplicación A, automáticamente tendrían acceso a la aplicación B durante la duración de esa sesión, sin tener que volver a ingresar sus credenciales. Más adelante dedicaremos un post alrededor de este concepto para un mayor entendimiento.
Hostname
Agregar la siguiente entrada al archivo /etc/hosts para configurar el nombre del host en el portátil donde se ejecutan los contenedores:
127.0.0.1 wso2is.local
Algunos navegadores no le permiten crear cookies para un nombre de host como localhost. Se requieren cookies cuando se trabaja con SSO.
Por lo tanto, para garantizar que las capacidades de SSO funcionen como se espera, es importante que configuremos este archivo.
Travelocity.properties
En este momento debemos configurar el archivo travelocity.properties. Se encuentra en la ruta:
/ISSamples/modules/samples/sso/sso-agent-sample/src/main/resources/
- Configura las siguientes propiedades con el nombre del container de Tomcat como el nombre del host:
#The URL of the SAML 2.0 Assertion Consumer
SAML2.AssertionConsumerURL=http://wso2is.local:8888/travelocity.com/home.jsp
#openid.return_to parameter
OpenId.ReturnToURL=http://wso2is.local:8888/travelocity.com/home.jsp
- Configura estas otras propiedades y usa como nombre del host localhost:
#The URL of the SAML 2.0 Identity Provider
SAML2.IdPURL=https://localhost:9443/samlsso
#OAuth2 token endpoint URL
OAuth2.TokenURL=https://localhost:9443/oauth2/token
#OpenId Provider Url
OpenId.ProviderURL=https://localhost:9443/openid/
#A unique identifier for this SAML 2.0 Service Provider application
SAML2.IdPEntityId=localhost
Ahora en el terminal, accede a la carpeta /modules/samples/sso/sso-agent-sample y compila el ejemplo usando el siguiente comando: $ mvn clean install
Después de generar con éxito el ejemplo, se puede encontrar el archivo .war llamado travelocity.com dentro del directorio
/sso/sso-agent-sample/target.
Es el momento o de desplegar este archivo war en un contenedor de Servlets, para ello, utiliza el contenedor de Servlets Apache Tomcat.
El contenedor Tomcat
El ejemplo del Service Provider está escrito en Servlet 3.0. Por lo tanto, hay que ejecutar el contenedor de servlets Tomcat 7.x. Esto lo realizaremos descargando una imagen Docker de Tomcat.
-Descubre los 5 principales beneficios de la gestión de identidades-
Para ello ir a la uri: https://hub.docker.com/r/library/tomcat/ donde puedes encontrar la imagen de Tomcat que utilizaremos.
La versión que instalaremos es la: 9.0.13. Si pulsas en Tags puedes visualizar la lista de versiones disponibles.
Con este comando se descarga la imagen: $ docker pull tomcat:9.0.13
Se puede comprobar la instalación listando las imágenes de Docker:
A continuación debemos ejecutar el Contenedor de Tomcat:
$ docker run -it -p 8888:8080 tomcat:9.0.13
Nota:
¿Cómo renombrar un contenedor? $ sudo docker rename old_name new_name
Antes que nada hay que configurar Tomcat con el usuario y contraseña para poder acceder a la consola. Para esto reinicia el contenedor y entra en la consola:
$ docker container restart tomcat9013
$ docker exec -it tomcat9013 bash
Ahora hay que configurar el archivo: tomcat-users.xml Como por ejemplo estos son los usuarios y roles que estamos usando:
Por tanto, para entrar en la consola debes teclear: tomcat/tomcat como usuario y contraseña respectivamente. ¡No olvides de reiniciar de nuevo el contenedor!
Nota:
Si al reiniciar Tomcat en el explorador no te aparece la ventana de logado, busca el archivo CATALINA_HOME/webapps/manager/META-INF/context.xml y agrega los comentarios alrededor de Valve:
En el explorador puedes ver ahora la consola de Tomcat.
Por último, no olvides conectar el contenedor de Tomcat a la red: pvn_sp_is
Ahora sí que tenemos los tres contenedores en ejecución:
Tomcat, WSO2-IS y WSO2-IS-Analytics:
Y los tres en la misma red:
$ docker network inspect pvn_sp_is
Como vimos, dependiendo del orden en que se inicien los contenedores, estos pueden obtener una dirección IP distinta. Por eso no podemos referirnos a ellos a través de su IP, sino con el nombre del contenedor: wso2is-750, wso2is-analytics, tomcat9013. El demonio DNS de docker realiza la correspondencia entre el nombre del contenedor y su dirección IP.
Por último, desplegar el war de Travelocity en el Tomcat. Selecciona: Manager App.
Como se puede ver en la imagen, solo se tiene que seleccionar el archivo war de la carpeta y pulsar Desplegar.
En el apartado Aplicaciones puede ver el war desplegado correctamente:
¡Qué interesante todo lo comentado! ¿No crees? Si quieres continuar con el tutorial no te pierdas la parte II, haremos hincapié en la configuración del SP en el Identity Server, WSO2 IS y Analytics Dashboard.
