Keycloak on slash-root.fr

Keycloak : Federation d’un annuaire LDAPS (Active Directory)

Tue, 23 Aug 2022 15:10:58 +0200

Cet article a pour but de décrire la mise en place de la fédération d'un annuaire LDAPS (Active Directory) au sein d'un royaume Keycloak.

Testé avec un domaine Active Directory On-Premises et avec Azure Active Directory.

Contexte de l’infrastructure

L'infrastructure sur laquelle je vais m'appuyer est la suivante :

1 contrôleur de domaine Active Directory (AD DS) avec sa PKI (AD CS) sous Windows Serveur 2019 Standard
- Domaine : aukfood.lan
- FQDN du contrôleur de domaine : dc01.aukfood.lan
1 serveur Keycloak en version 19.0.1
- Déployé dans docker swarm avec ce stack : /docker-swarm-stack-keycloak-v19-latest/
- URL : keycloak.example.com

Certificat TLS

Note : Les commandes de ce chapitre sont réalisées depuis le serveur hébergeant le conteneur keycloak.

Récupération du certificat

Pour commencer, il va falloir récupérer le certificat TLS utilisé pour la liaison LDAPS.

LDAP = Port 389 TCP

LDAPS = Port 636 TCP

Avec l'utilitaire openssl, il est possible de tester que la liaison LDAPS est fonctionelle ainsi que de récupérer différentes informations (dont le certificat du serveur) :

openssl s_client -connect dc01.aukfood.lan:636

Voici le retour pour cette infra :

depth=0 CN = dc01.aukfood.lan
---
Certificate chain
 0 s:CN = dc01.aukfood.lan
 i:DC = lan, DC = aukfood, CN = aukfood-DC01-CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHLzCCBRegAwIBAgITTAAAAAczDQgCtUWEjAAAAAAABzANBgkqhkiG9w0BAQsF
[...]
AniSQdTOnACZrX//9tDg73RV9w==
-----END CERTIFICATE-----
subject=CN = dc01.aukfood.lan
issuer=DC = lan, DC = aukfood, CN = aukfood-DC01-CA

Copier le Server certificate commençant par -----BEGIN CERTIFICATE----- et se terminant par -----END CERTIFICATE----- dans un fichier server-ldaps.cer :

cat <<EOF > server-ldaps.cer
-----BEGIN CERTIFICATE-----
MIIHLzCCBRegAwIBAgITTAAAAAczDQgCtUWEjAAAAAAABzANBgkqhkiG9w0BAQsF
[...]
AniSQdTOnACZrX//9tDg73RV9w==
-----END CERTIFICATE-----
EOF

Création du keystore

Maintenant que le certificat TLS du contrôleur de domaine a été récupéré, il va falloir l'importer dans un keystore.

Tout d'abord, installer openjdk-11-jre :

sudo apt install openjdk-11-jre

Puis importer le certificat server-ldaps.cer dans un keystore nommé keystore.jks :

keytool -import -trustcacerts -alias dc01.aukfood.lan-CA -file server-ldaps.cer -keystore keystore.jks

Saisir un mot de passe à appliquer au keystore :

Entrez le mot de passe du fichier de clés : 
Ressaisissez le nouveau mot de passe :

Vérifier la présence du certificat dans le keystore généré :

keytool -list -keystore keystore.jks

Après avoir entrer le mot de passe du keystore, le certificat est bien présent :

Entrez le mot de passe du fichier de clés : 
Type de fichier de clés : PKCS12
Fournisseur de fichier de clés : SUN

Votre fichier de clés d'accès contient 1 entrée

dc01.aukfood.lan-ca, 22 août 2022, trustedCertEntry, 
Empreinte du certificat (SHA-256) : 61:EA:83:97:92:[...]:B5:59:EE:2C:8A:2D:EA

Déclaration du keystore

Maintenant que le keystore a été généré avec le certificat TLS du contrôleur de domaine, il va falloir le déclarer au sein de Keycloakpour qu'il puisse être exploité.

Dans la stack keycloak (voir lien en début d'article), un volume conf est monté pour la persistance des données du répertoire /opt/keycloak/conf dans le conteneur.

Envoyer le keystore précédement généré dans le conteneur :

docker cp ./keystore.jks $(docker ps -qf name=keycloak):/opt/keycloak/conf/

Puis ajouter les variables suivantes sur la stack de keycloak :

services:
 app:
 [...]
 environment:
 [...]
 # Indiquer le mot de passe du keystore
 KC_SPI_TRUSTSTORE_FILE_FILE: /opt/keycloak/conf/keystore.jks
 KC_SPI_TRUSTSTORE_FILE_PASSWORD: MotDePasseTresSecure
 [...]

Le MotDePasseTresSecure est celui qui a été indiqué lors de la création du keystore.

Lister les stacks dans docker swarm :

docker stack ls

Identifier l'ID du service docker exécutant

NAME SERVICES ORCHESTRATOR
keycloak 1 Swarm
nextcloud 2 Swarm
portainer 2 Swarm
rocketchat 2 Swarm
swarmpit 4 Swarm
traefik 1 Swarm

La stack faisant tourner le keycloack en v19 est nommé keycloak dans ce cluster docker.

Supprimer la stack keycloak :

docker stack rm keycloak

Puis relancer la stack kycloak pour prendre en compte les nouvelles variables d'environnement concernant le truststore :

docker stack deploy -c ./keycloak/stack.yml keycloak

Le fichier stack.yml est stocké dans un répertoire nommé keycloak de mon répertoire courant. A adapter suivant son emplaccement dans le FHS.

Logs

Avant de passer à la configuration de la fédération de l'annuaire Active Directory via LDAPS à Keycloak, il est important de vérifier et de de s'assurer du bon redémarrage du conteneur.

Pour cela, lister les services en cours au sein du cluster docker :

docker service ls

Identifier le service adéquat (ici : keycloak_app) :

ID NAME MODE REPLICAS IMAGE PORTS
2degmsl8r3se dashy replicated 0/0 lissy93/dashy:latest 
7jq3dje5b0t8 keycloak_app replicated 1/1 quay.io/keycloak/keycloak:latest 
ubq1dvhwv0st nextcloud_app replicated 1/1 nextcloud:latest 
arz4ca4gvfgv nextcloud_mariadb replicated 1/1 mariadb:latest 
vr2c7ptq6a8k portainer_agent global 5/5 portainer/agent:latest 
h6h5merxg9a2 portainer_portainer replicated 1/1 portainer/portainer-ce:latest 
mzsq3uof6c1r rocketchat_mongodb replicated 1/1 bitnami/mongodb:4.4 
tmu3kz5n7xq9 rocketchat_rocketchat replicated 1/1 registry.rocket.chat/rocketchat/rocket.chat:latest 
kos1zg1wowxi swarmpit_agent global 5/5 swarmpit/agent:latest 
gtjs3mikbtaf swarmpit_app replicated 1/1 swarmpit/swarmpit:latest 
nx6s2mt19bzx swarmpit_db replicated 1/1 couchdb:2.3.0 
n5oq9gx05bnd swarmpit_influxdb replicated 1/1 influxdb:1.7 
u7b8rsym5lzp traefik_traefik replicated 1/1 traefik:latest

Vérifier la bonne exécution du service en gardant un shell ouvert avec la lecture des logs en temps réel :

docker service logs -f keycloak_app

Configuration de la fédération LDAPS

Note : A partir de maintenant, la configuration est à effectuer à travers la console web d'administration du service Keycloak.

User federation

Sélectionner le royaume adéquat ou en créer un nouveau (1), puis se rendre sur User federation (2) :

Ajouter un fournisseur LDAP :

Note : Pour les explications des différents champs, leurs fonctions, leurs utilités, etc... qui vont suivre, se référer à cet article que j'ai écris en 2021 sur l'intégration d'un annuaire LDAP (OpenLDAP, huhu) : /keycloak-integration-ldap-externe/

Tous les paramètres de synchronisation y sont traités :

Gestion du stockage des utilisateurs
L'influence du mode Import Users sur les requêtes LDAP (LDAPS, même combat)
L'Edit Mode et ses différents paramètres
Les types de Vendor
Les différents champs Users DN ou Bind DN
Les configurations possibles pour la synchronisation ainsi que leurs périodicités

General options

(1) Console display name : Entrer un nom afin d'identifier cette fédération d'utilisateurs au sein de Keycloak.
(2) Vendor : Indiquer le type d'annuaire.

Connection and authentication settings

(1) Connection URL : Renseigner l'URL de connexion à l'annuaire LDAPS sous la forme ldaps://FQDN_DC:636. Cette URL doit correspondre au "Common Name" du certificat. Celui-ci peut être identifié lors de l'utilisation de la commande openssl au début de cet article.

(2) Use Truststore SPI : Indiquer l'utilisation du truststore javax.net.ssl.trustStore (pour le keystore.jks) uniquement pour ldaps.

(3) Bind DN : Indiquer le DistinguishedName de l'utilisateur de l'annuaire qui sera utilisé par Keycloak. Pour le récupérer facilement :

Get-ADUser UTILISATEUR_AD | FT DistinguishedName

(4) Bind credentials : Mettre le mot de passe de l'utilisateur indiqué au point précédent.

A noter que pour le moment, il manque des informations dans le paramétrage de la liaison LDAPS. De ce fait, le "Test connection" et le "Test authentication" ne sont pas encore réalisables (Une des différences avec les versions de Keycloak sous Wildfly en version 16 et inférieure).

LDAP searching and updating

(1) Edit mode : Définir le mode d'édition de l'annuaire.

(2) Users DN : Indiquer le DistinguishedName de l'OU contenant les utilisateurs à fédérer.

Tests et import utilisateurs

Il est maintenant possible de tester la connexion LDAPS et l'authenfication.

Ces 2 tests doivent aboutir :

Ensuite, en haut à droite de la page, bien s'assurer que cette fédération soit enabled. Puis dans action (1), déclencher la synchronisation (2) de tous les utilisateurs :

L'importation des utilisateurs aboutie :

Dans les utilisateurs du royaume Keycloak, je retrouve bien les utilisateurs contenus dans l'OU définit dans la fédération.

Mappers

Dans ce contexte, l'utilisateur "Julien LOUIS", se retrouve avec un username contenant des espaces. Cela est dû au faites que l'attribut cn de l'annuaire a été mappé vers l'attribut username de Keycloak.

Pour voir tous les utilisateurs du royaume keycloak (fédération incluse), rechercher ***** comme utilisateur.

De plus, pour l'utilisateur final, cela ne correspondra pas au login auquel il est habitué d'utiliser.

Pour modifier ce comportement, il faut mapper l'attribut sAMAccountName de l'anuaire Active Directory vers l'attribut username de Keycloak.

Se rendre sur les paramétrages de la fédération précédement réalisée, puis dans l'onglet Mappers (1), éditer le mapper username (2) :

Modifier le champ LDAP Attribute pour y inscrire sAMAccountName :

Puis, enregistrer la modification en bas de page.

Ensuite, dans l'onglet Settings, modifier l'Username LDAP attribute en y inscrivant sAMAccountName :

Puis, enregistrer la modification en bas de page.

En relançant la synchronisation de tous les utilisateurs de l'annuaire vers Keycloak, les utilisateurs sont mis à jour :

A présent, le login des utilisateurs importés dans Keycloak est correctement paramétré.

Docker Swarm : Stack Keycloak (v19 latest)

Mon, 22 Aug 2022 10:39:09 +0200

Informations importantes

Nécéssite le stack pour traefik voir ici : /docker-swarm-stack-traefik/
Cette stack est faites pour du développement (avec persistance des données) et non de la production
Bien modifier ce qu'il faut dans le stack (voir commentaires)

Fichier stack.yml

version: '3.3'

services:

 app:
 image: quay.io/keycloak/keycloak:latest
 security_opt:
 - no-new-privileges:true
 command: start-dev
 environment:
 PROXY_ADDRESS_FORWARDING: "true"
 KC_FEATURES: token-exchange
 KC_PROXY: passthrough
 KEYCLOAK_ADMIN: admin
 # Indiquer un mot de passe pour le compte admin sur l'application keycloak
 KEYCLOAK_ADMIN_PASSWORD: MotDePasseTresSecure

 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 # Indiquer les volumes à monter. Si le volume est inexistant, il sera créé automatiquement. Attention si contexte de cluster (swarm), penser à placer une contrainte de label.
 - conf:/opt/keycloak/conf
 - data:/opt/keycloak/data
 - providers:/opt/keycloak/providers
 - themes:/opt/keycloak/themes
 networks:
 # Indispensable pour communiquer avec traefik
 - traefik-public
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 placement:
 constraints:
 - node.labels.keycloak_quay-io_conf == true
 - node.labels.keycloak_quay-io_data == true
 - node.labels.keycloak_quay-io_providers == true
 - node.labels.keycloak_quay-io_themes == true
 labels:
 # Activation de traefik
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Indiquer l'URL de l'application (keycloak.example.com)
 - traefik.http.routers.keycloak_quay-io-http.rule=Host(`keycloak.example.com`)
 - traefik.http.routers.keycloak_quay-io-http.entrypoints=http
 - traefik.http.routers.keycloak_quay-io-http.middlewares=https-redirect
 # Indiquer l'URL de l'application (keycloak.example.com)
 - traefik.http.routers.keycloak_quay-io-https.rule=Host(`keycloak.example.com`)
 - traefik.http.routers.keycloak_quay-io-https.entrypoints=https
 - traefik.http.routers.keycloak_quay-io-https.tls=true
 - traefik.http.routers.keycloak_quay-io-https.tls.certresolver=le
 - traefik.http.middlewares.hsts-headers.headers.stsSeconds=315360000
 - traefik.http.middlewares.hsts-headers.headers.stsPreload=true
 - traefik.http.middlewares.hsts-headers.headers.stsIncludeSubdomains=true
 - traefik.http.middlewares.hsts-headers.headers.customFrameOptionsValue=SAMEORIGIN
 - traefik.http.middlewares.hsts-headers.headers.sslRedirect=true
 - traefik.http.middlewares.hsts-headers.headers.forceSTSHeader=true
 - traefik.http.middlewares.hsts-headers.headers.referrerPolicy=same-origin
 - traefik.http.routers.keycloak_quay-io-https.middlewares=hsts-headers
 - traefik.http.services.keycloak_quay-io.loadbalancer.server.port=8080

networks:
 traefik-public:
 external: true

volumes:
 conf:
 driver: local
 data:
 driver: local
 providers:
 driver: local
 themes:
 driver: local

Déploiement

docker stack deploy -c stack.yml keycloak

Docker Swarm : Stack Keycloak (v16 depreciated)

Thu, 18 Aug 2022 11:47:44 +0200

Changelog

22/08/2022 : Ajout information depreciated

Informations importantes

Nécessite le stack pour traefik voir ici : /docker-swarm-stack-traefik/
Bien modifier ce qu'il faut dans le stack (voir commentaires)

Ce stack utilise une image docker provenant de jboss qui est un keycloak en v16. La dernière version actuelle est la v19. Stack disponible ici : /docker-swarm-stack-keycloak-v19-latest/

Fichier stack.yml

version: '3.3'

services:
 postgres:
 image: postgres
 environment:
 POSTGRES_DB: keycloak
 POSTGRES_USER: keycloak
 # Indiquer le mot de passe souhaité
 POSTGRES_PASSWORD: MotDePasseTresSecure
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 - postgres_data:/var/lib/postgresql/data
 networks:
 - net
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 placement:
 constraints:
 # Label à appliquer au noeud (A retirer si utilisation de glusterfs / ceph)
 - node.labels.keycloak_postgres_data == true

 keycloak:
 image: jboss/keycloak:latest
 environment:
 PROXY_ADDRESS_FORWARDING: 'true'
 DB_VENDOR: POSTGRES
 DB_ADDR: postgres
 DB_DATABASE: keycloak
 DB_USER: keycloak
 # Indiquer le mot de passe inscrit dans le service postgre
 DB_PASSWORD: MotDePasseTresSecure
 KEYCLOAK_USER: admin
 # Indiquer le mot de passe souhaité
 KEYCLOAK_PASSWORD: MotDePasseTresSecure
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock:ro
 - /etc/localtime:/etc/localtime:ro
 networks:
 - net
 # Réseau utilisé par le conteneur traefik
 - traefik-public
 deploy:
 #resources:
 #limits:
 #cpus: '0.50'
 #memory: 1024M
 #reservations:
 #cpus: '0.25'
 #memory: 512M
 labels:
 # Activation de traefik
 - traefik.enable=true
 - traefik.docker.network=traefik-public
 - traefik.constraint-label=traefik-public
 # Modifier le domaine de l'application keyclaok
 - traefik.http.routers.keycloak-http.rule=Host(`keycloak.example.com`)
 - traefik.http.routers.keycloak-http.entrypoints=http
 - traefik.http.routers.keycloak-http.middlewares=https-redirect
 - traefik.http.routers.keycloak-https.rule=Host(`keycloak.example.com`)
 - traefik.http.routers.keycloak-https.entrypoints=https
 - traefik.http.routers.keycloak-https.tls=true
 - traefik.http.routers.keycloak-https.tls.certresolver=le
 # Indiquer le port utiliser de l'application
 - traefik.http.services.keycloak.loadbalancer.server.port=8080

networks:
 net:
 driver: overlay
 attachable: true
 traefik-public:
 external: true

volumes:
 postgres_data:
 driver: local

Déploiement

docker stack deploy -c stack.yml keycloak

Docker-Compose : Keycloak

Mon, 13 Dec 2021 11:30:58 +0100

docker-compose.yml

version: '3.3'

services:
 postgres:
 restart: unless-stopped
 image: postgres
 container_name: keycloak_postgres
 volumes:
 - ./postgres_data:/var/lib/postgresql/data
 environment:
 POSTGRES_DB: keycloak
 POSTGRES_USER: keycloak
 POSTGRES_PASSWORD: password
 keycloak:
 container_name: keycloak
 restart: unless-stopped
 image: jboss/keycloak:latest
 environment:
 PROXY_ADDRESS_FORWARDING: 'true'
 DB_VENDOR: POSTGRES
 DB_ADDR: postgres
 DB_DATABASE: keycloak
 DB_USER: keycloak
 DB_PASSWORD: password
 KEYCLOAK_USER: admin
 KEYCLOAK_PASSWORD: password
 ports:
 - 8083:8080
 depends_on:
 - postgres

Keycloak : Integration LDAP externe

Thu, 04 Nov 2021 17:33:31 +0100

Introduction

La solution Keycloak est embarqué avec la possibilité de joindre un annuaire LDAP/AD. Il est possible de fédérer plusieurs serveurs d'annuaires au sein d'un même royaume keycloak. Les attributs utilisateurs de l'annuaire LDAP peuvent être mappé dans un model d'utilisateur keycloak. Par défaut, les attributs username, email, first name, last name sont mappés mais d'autres attributs peuvent l'être également.

Cet article fait suite à :

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

OpenLDAP : Installation avec FusionDirectory

Prérequis

Un serveur Keycloak fonctionnel
Un serveur OpenLDAP/FusionDirectory fonctionnel

Toute la procédure fera référence aux configuration déployées dans les articles cités en introduction.

Configuration

Se rendre sur la WebUI du serveur Keycloak : https://keycloak.example.com
Se rendre dans la partie User Federation et ajouter ldap en provider :

Paramétrage - 1ère partie

Stockage

Par défaut, Keycloak importe les utilisateurs de l'annuaire LDAP dans sa base locale d'utilisateurs. Cette copie des utilisateurs peut être synchronisée soit manuellement soit automatiquement toutes les x minutes par exemple. Seul les mots de passes ne sont pas synchronisés. Dans le processus d'identification de l'utilisateur, la validation du mot de passe est délégué au serveur LDAP. L'avantage de cette approche est que toutes les fonctionnalités de Keycloak fonctionneront avec des attributs utilisateurs supplémentaires qui sont stockés localement sur Keycloak. Cela permet également de réduire la charge sur le serveur LDAP.

Il est possible de ne pas importer les utilisateurs de l'annuaire LDAP dans Keycloak en décochant Import Users. Cela aura pour effet d'augmenter les requêtes vers le serveur LDAP car aucune information utilisateur ne sera stockée localement sur Keycloak. L'autre conséquence de ce choix est que si une fonctionnalité de Keycloak repose sur une partie non supporté par l'annuaire LDAP, celle-ci ne fonctionnera pas. En revanche, l'avantage est de ne pas avoir à gérer la synchronisation des comptes.

Edition

L'Edit Mode permet aux utilisateurs et aux administrateurs, à travers leurs consoles respectives sur Keycloak, de modifier les metadas utilisateur.

READONLY : Les attributs utilisateurs resteront inchangés. Une erreur apparaitra si une modification d'attribut est faites. Cela est également valable pour la modification d'un mot de passe utilisateur.
WRITABLE : Tous les attributs utilisateurs modifiés seront synchronisés automatiquement avec l'annuaire LDAP.
UNSYNCED : Tous les changements d'attributs seront stockés localement dans la base de Keycloak. La synchronisation des modifications au sein de Keycloak vers l'annuaire LDAP devra être faites manuellement.

Vendor

Plusieurs choix sont possibles suivant le type d'annuaire LDAP en face :

Active Directory
Red Hat Directory Server
Tivoli
Novell eDirectory
Other

L'annuaire installé étant OpenLDAP, other est le choix à faire.

Paramétrage - 2nd partie

Connection URL : Indiquer le chemin d'accès au serveur LDAP
Users DN : Indiquer le chemin d'accès aux utilisateurs dans l'annuaire.
Bind DN : Indiquer un compte dans l'annuaire ayant des droits d'écriture.
Bind Credential : Le mot de passe du compte spécifié dans "Bind DN".

Synchronisation

Un peu plus bas de la page de configuration de la connexion au serveur LDAP, un menu Sync Settings est disponible :

Batch Size : Le nombre de compte utilisateurs qui seront traités en une synchronisation.
Periodic Full Sync : La planification en secondes de la synchronisation totale / complète.
Periodic Changed Users Sync : La planification en secondes de la synchronisation des changements apportés aux attributs utilisateurs.

Après avoir sauvegarder tous les paramètres, il est possible de déclencher manuellement une première synchronisation des utilisateurs de l'annuaire LDAP dans Keycloak :

Mappers

Par défaut, des Mappers sont mis en place. Un mapper va permettre de mapper un attribut utilisateur de l'annuaire LDAP à un attribut utilisateur de Keycloak :

Dans mes différents essais, en déployant cette solution de SSO avec un OpenLDAP, il est apparu que l'attribut firstName de Keycloak est mappé avec l'attribut cn de l'annuaire LDAP. L'attribut cn dans l'annuaire (avec la couche FusionDirectory) est une concaténation du prénom et du nom de l'utilisateur :

Au lieu de modifier la configuration de l'annuaire LDAP, modifier le mapper first name dans Keycloak :

Modifier LDAP Attribute pour indiquer givenName.

givenName est le nom de l'attribut prénom au sein de l'annuaire LDAP dans notre configuration.

OpenProject : Mise en place du SSO avec Keycloak

Thu, 28 Oct 2021 14:40:22 +0200

Introduction

Par défaut, OpenProject utilise une base locale d'utilisateurs pour gérer l'authentification. Afin de centraliser l'authentification sur un serveur dédié (avec OpenID-Connect) Keycloak, une configuration SSO est nécessaire sur OpenProject.

OpenProject va utiliser OpenID-Connect pour faire du SSO. Ca tombe bien Keycloak aussi ! Un paramétrage concernant cela est disponible via la web UI d'administration d'OpenProject mais celle-ci ne concerne que Google et Azure. Fort heureusement, c'est tout de même possible en éditant un fichier.

Référence :

OpenProject : Installation

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

Pré-requis

Pour mener à bien cette procédure, il faut :

Un serveur OpenProject installé avec une licence Entreprise
Un serveur Keycloak installé

Pour la licence OpenProject Entreprise, il est possible de faire un essai de 14 jours gratuitement. Sans licence Entreprise, le SSO n'est pas pris en charge par OpenProject. Lorsque l'essai de la version Entreprise arrive à son terme et que celle-ci n'est pas prolongé, alors la licence repasse automatique en Community Edition (Free).

Configuration partie Keycloak

Création d'un royaume :

Création d'un client :

Root URL : L'URL d'accès au serveur OpenProject.

Dans les propriétés du client nouvellement créer, définir l' Access Type sur confidential afin de générer un secret :

Bien penser à sauvegarder la modification en bas de la page.

Un nouvel onglet Credentials est apparu dans les propriétés du client. Un secret a été généré :

Créer un compte utilisateur si le serveur Keycloak est fraichement installé :

Attention : Sur l'illustration, seul le champ Username est indiqué comme obligatoire. Lorsque qu'un utilisateur s'authentifiera avec son compte Keycloak sur OpenProject, les champs Email , First Name , Last Name seront obligatoires. Ces propriétés ne peuvent en cas cas être communes à un autre compte.

Une fois l'utilisateur créé, dans l'onglet Credentials , définir son mot de passe :

Configuration partie OpenProject

Pour qu'un utilisateur puisse utiliser son compte Keycloak pour s'authentifier sur OpenProject, celui-ci doit être activé dans OpenProject. Par défaut l'activation se fait manuellement. Pour automatiser ce processus, une option d' activation automatique du compte existe dans OpenProject.

Se connecter en admin sur OpenProject puis "Administration -> Authentification", modifier l'option Auto-enregistrement comme suit :

Pour la suite des opérations, se connecter en SSH sur le serveur OpenProject.

Modifier le fichier /opt/openproject/config/configuration.yml afin d'ajouter la possibilité de s'authentifier sur OpenProject au travers du serveur SSO Keycloak. Ajouter les lignes suivantes dans la section default :

default:

# omniauth_direct_login_provider: openid

 openid_connect:
 openid:
 host: "keycloak.example.fr"
 identifier: "MonOpenProject"
 secret: "af90aced-0000-0000-0000-0959e6fd5226"
 icon: "openid_connect/auth_provider-google.png"
 display_name: "SSO"
 authorization_endpoint: "https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/auth"
 token_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/token'
 userinfo_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/userinfo'
 end_session_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/logout'
 check_session_iframe: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/login-status-iframe.html'
 sso: true
 issuer: 'https://keycloak.example.fr/auth/realms/MonRoyaume'
 discovery: false

Adapter les valeurs suivantes :

host : Le FQDN du serveur Keycloak
identifier : Le nom du client créé dans Keycloak
secret : Le secret du client généré dans Keycloak

# Les URLS suivantes peuvent facilement être obtenues dans Keycloak
# Realm Settings -> Endpoints : OpenIP Endpoint Configuration

authorization_endpoint: "https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/auth"
token_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/token'
userinfo_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/userinfo'
end_session_endpoint: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/logout'
check_session_iframe: 'https://keycloak.example.fr/auth/realms/MonRoyaume/protocol/openid-connect/login-status-iframe.html'
issuer: 'https://keycloak.example.fr/auth/realms/MonRoyaume'

La directive omniauth_direct_login_provider indique que seul l'authentification passera par keycloak. Commenter cette directive pour avoir le choix d'authentification entre keycloak (SSO) ou la base locale d'OpenProject.

OpenProject : Redémarrer le service openproject

sudo systemctl restart openproject

Vérification du fonctionnement

Dorénavant lors de la connexion sur OpenProject, une option de connexion SSO est disponible :

Le serveur Keycloak prends le relais pour demander les credentials :

Après la 1ère connexion d'un utilisateur au travers du SSO, celui-ci est présent dans OpenProject avec un fournisseur d'authentification OpenID :

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

Mon, 25 Oct 2021 17:37:16 +0200

Introduction

Keycloak est une solution opensource permettant d'implémenter du SSO (Single-Sign-On) au sein d'une infrastructure. Il est compatible avec les principaux protocoles d'authentification (OAuth2.0, OpenID-Connect). Il peut être couplé à un annuaire LDAP.

Dans cet article, Keycloak, va être déployé sur une Debian 10 conteneurisé dans 2 images dockers. Docker-Compose va orchestrer le tout. Un serveur nginx sera en frontal en tant que reverse-proxy.

Prérequis

1 serveur Debian 10 à jour qui sera dédié à hébergé le serveur Keycloack
1 serveur web Nginx opérationnel
Certificats SSL générés pour votre nom de domaine

Voir article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS

Installation

Installation des paquets

Installer docker :
```
sudo apt install docker
```
Installer docker-compose :
```
sudo apt install docker-compose
```
Vérifier l'installation de docker-compose :
```
docker-compose --version
```

Création du docker-compose

Créer un répertoire afin d'y stocker le fichier docker-compose :
```
sudo mkdir keycloak
```
Se positionner dans le répertoire nouvellement créé :
```
cd keycloak
```
Créer un fichier docker-compose.yml :
```
sudo vi docker-compose.yml
```

Attention, le fichier doit être au format YAML ce qui signifie que la tabulation est interdite (il faut mettre des espaces pour l'indentation).

Copier / Coller le fichier suivant :

version: '3.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: jboss/keycloak:latest
 environment:
 PROXY_ADDRESS_FORWARDING: 'true'
 DB_VENDOR: POSTGRES
 DB_ADDR: postgres
 DB_DATABASE: keycloak
 DB_USER: keycloak
 DB_PASSWORD: password
 KEYCLOAK_USER: admin
 KEYCLOAK_PASSWORD: Mon_mot_de_passe
 ports:
 - 9090:8080
 depends_on:
 - postgres

Le numéro de version indiqué en 1ère ligne peut varier suivant votre version de docker-compose. Dans mon cas, j'ai une version de docker-compose en 1.21.0.

Le port de keycloak dans le conteneur est le 8080, il sera bind sur le 9090 du serveur.

La directive PROXY_ADDRESS_FORWARDING est très importante dans le cas d'une utilisation de reverse proxy.

Lancement du docker-compose

Exécuter le docker-compose :

sudo docker-compose -f ~/keycloak/docker-compose.yml up

Pour lancer le docker-compose en arrière-plan :

sudo docker-compose -f ~/keycloak/docker-compose.yml up -d

Vérifier que les conteneurs docker soient bien démarrés :
```
sudo docker ps
```

Le résultat soit être similaire à :

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
643f26101b75 jboss/keycloak:latest "/opt/jboss/tools/do…" About a minute ago Up 52 seconds 8443/tcp, 0.0.0.0:9090->8080/tcp keycloak_keycloak_1
6789a8285283 postgres "docker-entrypoint.s…" About a minute ago Up 52 seconds 5432/tcp keycloak_postgres_1

Configuration reverse-proxy SSL avec Nginx

Un serveur Nginx doit être opérationnel.

S'appuyer sur cet article : Nginx : Installation d’un Reverse Proxy
Les certificats SSl doivent être générés.

S'appuyer sur cet article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS
Créer le fichier de configuration du virtual host :
```
sudo vi /etc/nginx/sites-available/keycloak.conf
```

Copier / Coller le fichier suivant :

server {
 listen 80;
 server_name keycloak.example.com;
 rewrite ^ https://keycloak.example.com permanent;
}

server {
 listen 443 ssl;
 server_name keycloak.example.com;
 ssl_certificate /etc/letsencrypt/live/keycloak.example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/keycloak.example.com/privkey.pem;
 ssl_session_cache builtin:1000 shared:SSL:10m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
 ssl_prefer_server_ciphers on;

 location / {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_pass http://IP_MON_SERVEUR_KEYCLOACK:9090;
 }

}

Remplacer keycloak.example.com par le nom de domaine pour le serveur keycloak. Le nécessaire doit être fait au sein de la zone DNS.

Vérifier les chemins d'accès aux certificats SSL.

Modifier la directive proxy_pass pour correspondre avec le serveur keycloak.

Créer un lien symbolique pour activer le virtual host :

sudo ln -s /etc/nginx/sites-available/keycloak.conf /etc/nginx/sites-enabled/keycloak.conf

Vérifier la configuration de Nginx avec :
```
sudo nginx -t
```
Redémarrer le service nginx :
```
sudo systemctl restart nginx
```

Accès administrateur à Keycloak

Se rendre à l'adresse : https://keycloak.example.com
Accéder à Administration Console :

Les credentials à entrer sont ceux définit dans le fichier docker-compose.yml aux lignes suivantes :
 KEYCLOAK_USER: admin
 KEYCLOAK_PASSWORD: Mon_mot_de_passe

Démarrage automatique avec le système

Avec la configuration actuelle au redémarrage du serveur keycloak, le docker-compose ne sera pas lancé.
Pour activer le démarrage automatique des conteneurs Postegresql et Keycloak au boot du serveur, modifier le docker-compose.yml et ajouter cette ligne dans chaque services qui doit démarrer avec le service docker :
```
restart: always
```
Si les conteneurs sont arrêtés à la main, ils ne démarreront pas automatiquement. Docker comprend que c'est une action manuelle et que c'est l'état désiré.
Pour que cela soit fonctionnel, le service docker.service doit être en status enable :
```
sudo systemctl status docker.service
```

Le résultat doit être le suivant :

Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)

Si cela n'est pas le cas :
```
sudo systemctl enable docker.service
```