domingo, 6 de marzo de 2022

Flowable UI en blanco al utentificarse con Keycloak

Después de haber configurado Flowable para identificar los usuarios contra Keycloak lo que me ocurría es que no me aparecían las aplicaciones.

Según la documentación de Flowable hay que hacer un Mapper en el cliente para que devuelva los grupos del usuario.

Pero le sigue faltando los Roles que es lo que utiliza para dar permiso a las diferentes aplicaciones.

Yo lo he resuelto Añadiendo uno nuevo de la siguiente forma:

  • Entra en las propiedades del cliente que has creado siguiendo las instrucciones de Flowable, en mi caso se llama flowable-client.
  • Entra en la pestaña Mappers
  • Utiliza el botón Create
  • Asigna los siguientes valores:
    • Name: Groups (por ejemplo)
    • Mapper Type: User Realm Role
    • Token Claim Name: groups (hay que respetar el nombre para que lo utilice Flowable

Si tienes curiosidad por saber que información está recibiendo Flowable, puedes ir a Client Scopes -> Evaluate seleccionar un User, pulsar en Evaluate y en la página siguiente seleccionar la pestaña Generated User Info

sábado, 19 de febrero de 2022

Autentificación de usuarios en Django contra el Servidor OpenID Keycloak con la ayuda de mozilla-django-oidc

 

mozilla-django-oidc vs django-allauth 

En la entrada anterior explicaba como utilizar la librería django-allauth para lo mismo que quiero hacer ahora con mozilla-django-oidc. Soy un principiante en lo que tiene que ver con OpenID  y no se si más adelante echaré de menos funcionalidad de django-allauth en mis proyectos, pero allauth está más enfocada a una gestión de usuario integral en la app y precisamente lo que busco es dejar esa responsabilidad al servidor Keycloak.

Las presentaciones

Entiendo que si has llegado aquí es por que conoces de sobra Django y probablemente te hayas topado con Keycloak.

Particularmente di con Keycloak buscando una solución que me pudiera simplificar la vida con la gestión de usuarios de una aplicación web corporativa. A la que quería dar acceso a todos los usuarios registrados en el Active Directory, junto con otros usuarios que se debían gestiona a parte.

Ademas quería contar con un mecanismo de Single Sign On para poder huir de crear grandes aplicaciones corporativas monolíticas y poder hacer Apps más especializadas sin que los usuarios tuvieran que ir introduciendo su usuario y contraseña cada vez que cambian de Aplicación / Funcionalidad.

Docker Keycloack 

Para ejecutar Keycloak en Docker, crea un archivo keycloak-postgresql.yml con el siguiente contenido:


version: '3'

volumes:
  postgres_data:
      driver: local

services:
  postgres:
      image: postgres
      volumes:
        - postgres_data:/var/lib/postgresql/data
      environment:
        POSTGRES_DB: keycloak
        POSTGRES_USER: keycloak
        POSTGRES_PASSWORD: password
  keycloak:
      image: quay.io/keycloak/keycloak:latest
      environment:
        DB_VENDOR: POSTGRES
        DB_ADDR: postgres
        DB_DATABASE: keycloak
        DB_USER: keycloak
        DB_SCHEMA: public
        DB_PASSWORD: password
        KEYCLOAK_USER: admin
        KEYCLOAK_PASSWORD: Pa55w0rd
        # Uncomment the line below if you want to specify JDBC parameters. The parameter below is just an example, and it shouldn't be used in production without knowledge. It is highly recommended that you read the PostgreSQL JDBC driver documentation in order to use it.
        #JDBC_PARAMS: "ssl=true"
      ports:
        - 8080:8080
      depends_on:
        - postgres
        

Para ejecutarlo:


  $ docker-compose -f keycloak-postgresql.yml up -d --build

Una vez ejecutado el comando y habiéndose puesto en marcha correctamente, deberemos poder acceder a la página de administración de Keycloak:

http://localhost:8080/auth/

Entra en la opción Administration Console y haz el login con admin y Pa55w0rd como se predefinió en keycloak-postgresql.ym.

Crea tu Reino en Keycloak

Pulsa sobre el desplegable Master y posteriormente sobre la opción "Add realm"

Como Name djangotest y guardamos

Estando dentro del reino djangotest crea por lo menos un usuario, mediante la opción Manage -> Users -> Add user

Yo me he creado el usuario demouser y posteriormente le he asignado una contraseña en la pestaña Credentials que he dejado marcada como Temporary para que me obligue a modificarla la primera vez que haga el login con ese usuario.

Dar acceso al proyecto Django como "cliente"

Hay que autorizar a nuestra aplicación para que pueda "consumir" credenciales proporcionadas por Keycloak, por lo que dentro de la sección Clients pulsaremos en Create.

Para el ejemplo podemos utilizar djangoclient y pulsamos en Save.

En la pestaña de Settings tenemos que configurar que URLs permitimos que el cliente solicite a Keycloak que sea redirigido el usuario una vez que se ha hecho el Login correctamente. Para el ejemplo ya que correremos el proyecto de Django también en local utilizaremos http://localhost:8000/*

Crear el proyecto Django


> mkdir djangoclient
> cd djangoclient
> virtualenv env
(env) > .\env\Scripts\activate
(env) > pip install django
(env) > pip install django-allauth
# Por costumbre siempre llamo a la aplicacion APP de forma
# que dentro de la carpeta con el nombre de la aplicación 
# me queda una carpeta env para el entorno 
# y otra app donde está el código fuente
(env) > django-admin startproject app 
(env) > cd app

Editar el archivo app\settings.py


INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    # Añadido para allauth
    'django.contrib.sites',

    'allauth',
    'allauth.account',
    'allauth.socialaccount',
    'allauth.socialaccount.providers.keycloak',
]

# Añadido para allauth
SOCIALACCOUNT_PROVIDERS = {
    'keycloak': {
        'KEYCLOAK_URL': 'http://localhost:8080/auth', # Servidor Keycloak
        'KEYCLOAK_REALM': 'Djangotest' # Nombre del Reino
    }
}

# Añadido para allauth
AUTHENTICATION_BACKENDS = (
    # Needed to login by username in Django admin, regardless of `allauth`
    'django.contrib.auth.backends.ModelBackend',
    # `allauth` specific authentication methods, such as login by e-mail
    'allauth.account.auth_backends.AuthenticationBackend',
)

# Añadido para allauth
SITE_ID = 1

# It's important that the domain follows the RFC 1034/1035 or else Django will complain
# This URL is defined as an extra host in client/docker-compose.yml
# We use the exposed port and not the host port because this URL will be fetched programmatically by the container
OAUTH_SERVER_BASEURL = 'http://localhost:8080'

Editar el archivo app\urls.py


from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('accounts/', include('allauth.urls')),
]

Ejecutamos la migración para que se adecue la BBDD


(env) > py manage.py migrate
(env) > py manage.py createsuperuser
(env) > py manage.py runserver

Entrar en http://localhost:8000/admin para crear una nueva entrada en Social applications.

Selecciona como Provider: Keycloak, en Name: keycloak y como Client id: djangoclient, que es el nombre que diste en Keycloak para la aplicación cliente. Añade a Chosen sites: example.com.

Añade un Site, es obligatorio pero creo que es parte de la funcionalidad de Allauth como gestor de usuarios y no es algo que tenga relevancia en la autentificación a través de Keycloak.

Login a través de Keycloak

Ha llegado el momento de probar que funciona

Como no tenemos preparada ninguna vista y ver errores nos podría despistar, lo que vamos a hacer es intentar modificar directamente el eMail y como no estamos "logeados" nos desviará al formulario de login. Si al introducir el usuario y la contraseña correctos nos lleva a la página de actualización del email significará que lo tenemos funcionando.

Entra en http://localhost:8000/accounts/email/, observa que nos ha llevado a la vista /accounts/login/.

Pulsa sobre Keycloak y deberemos ser llevados al login de Keycloak en el reino DJANGOTEST.

Introduce el usuario demouser que creamos al principio y si todo ha ido como se esperaba llegarás a la vista que te permite modificar el email.

Documentación de django-allauth

sábado, 29 de agosto de 2020

Autentificación de usuarios en Django contra el Servidor OpenID Keycloak con la ayuda de django-allauth

Las presentaciones

Entiendo que si has llegado aquí es por que conoces de sobra Django y probablemente te hayas topado con Keycloak.

Particularmente di con Keycloak buscando una solución que me pudiera simplificar la vida con la gestión de usuarios de una aplicación web corporativa. A la que quería dar acceso a todos los usuarios registrados en el Active Directory, junto con otros usuarios que se debían gestiona a parte.

Ademas quería contar con un mecanismo de Single Sign On para poder huir de crear grandes aplicaciones corporativas monolíticas y poder hacer Apps más especializadas sin que los usuarios tuvieran que ir introduciendo su usuario y contraseña cada vez que cambian de Aplicación / Funcionalidad.

Docker Keycloack 

Para ejecutar Keycloak en Docker, crea un archivo keycloak-postgresql.yml con el siguiente contenido:


version: '3'

volumes:
  postgres_data:
      driver: local

services:
  postgres:
      image: postgres
      volumes:
        - postgres_data:/var/lib/postgresql/data
      environment:
        POSTGRES_DB: keycloak
        POSTGRES_USER: keycloak
        POSTGRES_PASSWORD: password
  keycloak:
      image: quay.io/keycloak/keycloak:latest
      environment:
        DB_VENDOR: POSTGRES
        DB_ADDR: postgres
        DB_DATABASE: keycloak
        DB_USER: keycloak
        DB_SCHEMA: public
        DB_PASSWORD: password
        KEYCLOAK_USER: admin
        KEYCLOAK_PASSWORD: Pa55w0rd
        # Uncomment the line below if you want to specify JDBC parameters. The parameter below is just an example, and it shouldn't be used in production without knowledge. It is highly recommended that you read the PostgreSQL JDBC driver documentation in order to use it.
        #JDBC_PARAMS: "ssl=true"
      ports:
        - 8080:8080
      depends_on:
        - postgres
        

Para ejecutarlo:


  $ docker-compose -f keycloak-postgresql.yml up -d --build

Una vez ejecutado el comando y habiéndose puesto en marcha correctamente, deberemos poder acceder a la página de administración de Keycloak:

http://localhost:8080/auth/

Entra en la opción Administration Console y haz el login con admin y Pa55w0rd como se predefinió en keycloak-postgresql.ym.

Crea tu Reino en Keycloak

Pulsa sobre el desplegable Master y posteriormente sobre la opción "Add realm"

Como Name djangotest y guardamos

Estando dentro del reino djangotest crea por lo menos un usuario, mediante la opción Manage -> Users -> Add user

Yo me he creado el usuario demouser y posteriormente le he asignado una contraseña en la pestaña Credentials que he dejado marcada como Temporary para que me obligue a modificarla la primera vez que haga el login con ese usuario.

Dar acceso al proyecto Django como "cliente"

Hay que autorizar a nuestra aplicación para que pueda "consumir" credenciales proporcionadas por Keycloak, por lo que dentro de la sección Clients pulsaremos en Create.

Para el ejemplo podemos utilizar djangoclient y pulsamos en Save.

En la pestaña de Settings tenemos que configurar que URLs permitimos que el cliente solicite a Keycloak que sea redirigido el usuario una vez que se ha hecho el Login correctamente. Para el ejemplo ya que correremos el proyecto de Django también en local utilizaremos http://localhost:8000/*

Crear el proyecto Django


> mkdir djangoclient
> cd djangoclient
> virtualenv env
(env) > .\env\Scripts\activate
(env) > pip install django
(env) > pip install django-allauth
# Por costumbre siempre llamo a la aplicacion APP de forma
# que dentro de la carpeta con el nombre de la aplicación 
# me queda una carpeta env para el entorno 
# y otra app donde está el código fuente
(env) > django-admin startproject app 
(env) > cd app

Editar el archivo app\settings.py


INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',

    # Añadido para allauth
    'django.contrib.sites',

    'allauth',
    'allauth.account',
    'allauth.socialaccount',
    'allauth.socialaccount.providers.keycloak',
]

# Añadido para allauth
SOCIALACCOUNT_PROVIDERS = {
    'keycloak': {
        'KEYCLOAK_URL': 'http://localhost:8080/auth', # Servidor Keycloak
        'KEYCLOAK_REALM': 'Djangotest' # Nombre del Reino
    }
}

# Añadido para allauth
AUTHENTICATION_BACKENDS = (
    # Needed to login by username in Django admin, regardless of `allauth`
    'django.contrib.auth.backends.ModelBackend',
    # `allauth` specific authentication methods, such as login by e-mail
    'allauth.account.auth_backends.AuthenticationBackend',
)

# Añadido para allauth
SITE_ID = 1

# It's important that the domain follows the RFC 1034/1035 or else Django will complain
# This URL is defined as an extra host in client/docker-compose.yml
# We use the exposed port and not the host port because this URL will be fetched programmatically by the container
OAUTH_SERVER_BASEURL = 'http://localhost:8080'

Editar el archivo app\urls.py


from django.contrib import admin
from django.urls import path, include

urlpatterns = [
    path('admin/', admin.site.urls),
    path('accounts/', include('allauth.urls')),
]

Ejecutamos la migración para que se adecue la BBDD


(env) > py manage.py migrate
(env) > py manage.py createsuperuser
(env) > py manage.py runserver

Entrar en http://localhost:8000/admin para crear una nueva entrada en Social applications.

Selecciona como Provider: Keycloak, en Name: keycloak y como Client id: djangoclient, que es el nombre que diste en Keycloak para la aplicación cliente. Añade a Chosen sites: example.com.

Añade un Site, es obligatorio pero creo que es parte de la funcionalidad de Allauth como gestor de usuarios y no es algo que tenga relevancia en la autentificación a través de Keycloak.

Login a través de Keycloak

Ha llegado el momento de probar que funciona

Como no tenemos preparada ninguna vista y ver errores nos podría despistar, lo que vamos a hacer es intentar modificar directamente el eMail y como no estamos "logeados" nos desviará al formulario de login. Si al introducir el usuario y la contraseña correctos nos lleva a la página de actualización del email significará que lo tenemos funcionando.

Entra en http://localhost:8000/accounts/email/, observa que nos ha llevado a la vista /accounts/login/.

Pulsa sobre Keycloak y deberemos ser llevados al login de Keycloak en el reino DJANGOTEST.

Introduce el usuario demouser que creamos al principio y si todo ha ido como se esperaba llegarás a la vista que te permite modificar el email.

Documentación de django-allauth

lunes, 20 de mayo de 2019

Google ha iniciado el desarrollo de un nuevo sistema operativo que no estará controlado por Google.

Hoy la noticia es que Android y las herramientas de Google estarán vetadas para el fabricante chino Huawei.

Para mi este movimiento podría salirles más caro a los del buscador a medio plazo que el que en principio se supone sufrirá la compañía China.

Este puede ser el revulsivo que necesita la gigantesca industria China para ponerse a una y lanzar el folk de android que pueda terminar haciendo sombra al propio android.

A día de hoy los fabricantes Chinos y el propio potencial de su mercado local es más que suficiente para impulsar un nuevo futuro sistema operativo estándar.

Quizás, hoy sea uno de esos días en los que un árbol caído en mitad del camino te enseña un lugar totalmente desconocido donde quedarte a vivir.

martes, 19 de febrero de 2019

Comportamiento Indefinido en FirebirdSQL 3 debido al “Cursor Stability”

FirebirdSQL 3.x trae una sorpresita que te puede complicar bastante la vida en el caso de que tengas en una tabla TRIGGERS que modifican otros registros de su propia tabla.

El problema viene cuando haces un UPDATE de varias filas modificando el FIELD1, y por ejemplo, el TRIGGER del primer registro hace un cambio en el segundo registro en el FIELD2. El resultado que obtienes es que ese cambio realizado por el TRIGGER desaparece, por que el UPDATE al llegar al segundo registro dejara el valor del FIELD2 que tenía en el momento en el que se lanzó el UPDATE. Vamos que utiliza el cursor en vez de utilizar la ultima versión del registro como era de esperar, y que dicho sea de paso, Firebird 2.5 lo hace a la perfección.

Ahora si haces un UPDATE sobre el primer registro y luego un UPDATE a parte para el segundo registro si que se mantendrá en cambio que se realizó en el FIELD2. Incluso si se hace sobre la misma transacción.

Si no he sido capaz de explicarlo bien espero que con el código de abajo se entienda mejor.

Esto viene provocado por una nueva funcionalidad que denominan “Cursor Stability” y tras una pequeña mención en la documentación ponen una nota que dice más o menos...

“El estándar SQL estipula que la instrucción MERGE debe generar un error si se encuentran múltiples coincidencias. Firebird no es tan estricto en este sentido, pero su comportamiento debe considerarse indefinido en estos casos.”

Firebird - SQL Language Changes

O sea… que ahora resulta que ya no tenemos la certeza de que los TRIGGERs funcionan en todos los casos, y por lo tanto, ahora la informática ha pasado de ciencia cierta a ciencia infusa. Teníamos programas que funcionaban perfectamente con las versiones anteriores de Firebird y al actualizar el motor, de repente, empiezan a trabajar con un comportamiento indefinido.

Yo personalmente hubiera preferido encontrarme de repente con errores al actualizar Firebird en desarrollo. La solución adoptada por los chicos de Firebird nos ha llevado a encontrarnos el problema ya en producción, con datos deteriorados por ese comportamiento indefinido.

Lo tengo reportado como un BUG en Firebird Tracker, aunque según el equipo encargado del desarrollo de Firebird no lo es.

CREATE TABLE TEST_UPDATE
(
  ID INTEGER NOT NULL,
  FIELD1 INTEGER,
  FIELD2 INTEGER,
  CONSTRAINT PK_TEST_UPDATE PRIMARY KEY (ID)
);

SET TERM ^^ ;
CREATE TRIGGER TEST_UPDATE_AU FOR TEST_UPDATE ACTIVE AFTER UPDATE POSITION 0 AS
begin
  Update TEST_UPDATE
  SET FIELD2=NEW.FIELD1
  Where ID=NEW.ID+1;
end ^^
SET TERM ; ^^

Insert into TEST_UPDATE (ID,FIELD1,FIELD2) VALUES (1,0,0);
Insert into TEST_UPDATE (ID,FIELD1,FIELD2) VALUES (2,0,0);
Insert into TEST_UPDATE (ID,FIELD1,FIELD2) VALUES (3,0,0);
Insert into TEST_UPDATE (ID,FIELD1,FIELD2) VALUES (4,0,0);
Insert into TEST_UPDATE (ID,FIELD1,FIELD2) VALUES (5,0,0);

Update TEST_UPDATE
Set Field1=10
Where ID in (2,3);
=== In Firebird 3.0.4 ===
Select *
From TEST_UPDATE;

ID,FIELD1,FIELD2
1,0,0
2,10,0
3,10,0 <== This value must be 10
4,0,10
5,0,0

=== In Firebird 2.5 is Correct!!!! ===
ID,FIELD1,FIELD2
1,0,0
2,10,0
3,10,10
4,0,10
5,0,0

lunes, 21 de marzo de 2016

Menú Desaparecido en DraftSight para Linux.

Si de repente has dejado de ver el menú de DraftSight y no eres capaz de volver a recuperarlo, solo tienes cerrar el programa, entrar en la carpeta /home//.config y eliminar o renombrar las carpetas DraftSight y draftsight. Al volver a entrar te volverá a cargar la configuración por defecto.

jueves, 1 de noviembre de 2012

Pantalla principal con Ubuntu 12.08, GNOME y Driver NVIDIA

Tengo dos monitores conectados a mi tarjeta gráfica NVIDIA y desde la configuración de la pantalla no era capaz de indicar que la principal (donde aparece la barra) era la otra. Al final ya sabéis... hay que entrar en el todopoderoso terminal.

Con el comando xrandr obtendras la información de las "salidas" que tienes disponible y cuales están conectada.

Averigua el nombre de la salida "output" que quieres convertir en principal y ejecuta el comando:

sudo xrandr --output [salida] --primary

Ejemplo: sudo xrandr --output DVI-I-1 --primary

Espero que os sirva.