Tutoriel
Keycloak

version 0.99.100

Créé le 22 Juillet 2025

Auteur

José Mans

But

Raison

Uniformiser la connexion des services Web de l'entreprise avec MediaWiki, Nextcloud toute en continuant d'utiliser l'annuaire LDAP.

Il est question dans ce document d'utiliser une seule interface d'identification pour être autoriser à utiliser les deux services Nextcloud et le Wiki (Mediawiki) de l'entreprise.

Une seule identification pour accéder à tous les services.

Approche

L'idée ici est de permettre à votre service Keycloak de fonctionner dans un conteneur géré par "Docker" et ceci dès que vous lancez le "compose up". C'est pourquoi la préparation est mise en avant par rapport à l'installation dans ce document.

Temps estimé pour une installation et configuration complète : 1 heure.

Prérequis

Base de données : Mysql ou Mariadb
Docker-ce
Apache2
Certificat SSL

Optionnel

OpenLDAP ou Active Directory

Conseil

Télécharger "Fichier:Keycloak:Dockerfile" et "Fichier:Keycloak:docker-compose.yml" avant de continuer à lire et changer les paramètres/variables dès que c'est énoncé.

Autre tutoriel

Starter in Docker

Préparation

Base de données externe

Mariadb / Mysql

Depuis la version 20 de keycloak le format utf8mb4 est employé malgré l'avertissement de la doc : https://www.keycloak.org/server/db (2025 09 05).

Il faut donc créer une table avec ce format pour avoir des indexes long.

Remplacer simplement utf8mb4_unicode_ci par utf8mb4_bin si vous souhaitez de meilleurs performance au détriment des comparaison avec accent comme "Èric = eric" qui ne fonctionneront pas.

CREATE DATABASE keycloak CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'kuser'@'%' IDENTIFIED BY 'UnMotDePassTrèsFort';
GRANT ALL PRIVILEGES ON keycloak.* TO 'kuser'@'%';
FLUSH PRIVILEGES;

L'utilisation d'une base SQL externe est obligatoire pour un usage en production, autrement toute la configuration effectuée est perdue du fait que par défaut la base de donnée est volatile (H2).

Syntaxe KC_DB

Une fois la table et l'utilisateur créé le Fichier:Keycloak:docker-compose.yml doit contenir ces informations par le biais des variables KC_DB comme décrit ci-dessous :

Exemple

#KC_DB_URL_DATABASE: keycloak # Pas utile de préciser avec la forme
KC_DB_URL_PORT: 3306
KC_DB_URL: jdbc:mariadb://172.17.0.1/keycloak?characterEncoding=UTF-8&useSSL=false
KC_DB_USERNAME: kuser
KC_DB_PASSWORD: "UnMotDePassTrèsFort" # Le mot de passe d'accès à la base de données

L'ip 172.17.0.1 est celle paramétrée par défaut à l'installation de l'application docker, pour en être certain un :

ip a show dev docker0

ou

docker network inspect $(docker network ls | grep -P "^.*bridge.*bridge.*local" | sed -E 's/^([a-zA-Z0-9]+)\s+(bridge).*/\1/')

Pour information, les variables liées à la gestion d'une base de données sont accessible à :

https://www.keycloak.org/server/db

Parfeu

Avant de vouloir des connexions à la base SQL depuis le docker à installer, il faut s'assurer que keycloak pourra se connecter au serveur mysql/mariadb externe.

Il faut donc vérifier le parfeu afin qu'il autorise les connexions du bridge docker0 et le dit serveur mariadb.

Dans mon cas le parfeu n'accepte pas les interfaces réseau étrangères à sa configuration. Je lui ai donc ajouté quelques lignes :

DOCKER=docker0
CHAIN=dock-me

Iptables

iptables -N ${CHAIN}
iptables -A INPUT -i $DOCKER -j ${CHAIN}
/usr/sbin/iptables -A ${CHAIN} -p TCP --dport 3306 -j ACCEPT
/usr/sbin/iptables -A ${CHAIN} -j RETURN

nft

nft add chain inet filter ${CHAIN} {}\;
nft add inet filter input iifname "${DOCKER}" counter jump ${CHAIN}
nft add rule inet filter ${CHAIN} tcp dport 3306 counter accept
nft add rule inet filter ${CHAIN} counter return

Certificats SSL

Droits d'accès pour keycloak et utilisation d'un certificat Let's Encrypt renouvelé tous les 90 jours.

L'image de keycloak est volontairement réduite au strict minimum pour des raisons de sécurité. Il n'est donc pas question d'ajouter des outils pour permettre de renouveler le certificats SSL du serveur.

C'est pourquoi la méthode par montage est choisie, car moins gourmande en manipulation dans le docker. Le hôte hébergeur se charge de renouveler avec certbot les certificats.

Méthode d'accès par montage

Cette méthode est adoptée parce que le serveur peut recharger les nouveaux certificats sans interruption de service, au pire, voire un simple docker restart.

Réattribué les droits d'accès aux certificats SSL

Par défaut le conteneur est lancé avec UID=1000 et GID=0. Autrement dit il possède le droit de lire/écrire/exécuter tous les fichiers et dossiers "appartenant au groupe" root du conteneur mais surtout celui de l'hôte (host) lors du montage de volume.

Sans rentrer dans les détails il me parait préférable d'attribuer un autre GID au conteneur afin de lui permettre d'accéder aux certificats SSL.

# sur le hôte du docker, où sont enregistrés les certificats.
addgroup ssl-access
getent group ssl-access
# affiche le gid '''5020'''
chown root:'''5020''' /etc/letsencrypt/{archive,live} /etc/letsencrypt/archive/domain.tld/priv*.pem
chmod 650 /etc/letsencrypt/archive/domain.tld/priv*.pem /etc/letsencrypt/{archive,live}
## Ceci est ajouté dans la crontab qui gère le renouvellement des certificats :
## vi /usr/local/sbin/crontab_re_hash.sh afin de remodifier les droits à chaque changement par certbot...

Le même GID a été choisi dans Fichier:Keycloak:docker-compose.yml.

Méthode pkcs12

Juste pour la culture, depuis peu Keycloak gère les certificats au format pkcs12.

Cette méthode n'est pas conseillée, mais si pas d'autres choix, voici comment convertir les certificats :

openssl pkcs12 -export -in /etc/letsencrypt/live/domain.tld/fullchain.pem -inkey /etc/letsencrypt/live/domain.tld/privkey.pem -out server.keystore -name server -passout pass:password

Apache proxy

Pour éviter d'avoir plusieurs certificats SSL, avec domaine différent, la solution d'utiliser un Proxy a été choisie.

L'utilisation du domaine "domain.tld" est donc faite avec un chemin dédié, l'url d'accès de Keycloak depuis le serveur ouvert à internet se fait avec l'url :

https://domain.tld/auth/

cookie_not_found

Une erreur récurrente entre Keycloak et un serveur HTTP comme Nginx ou Apache.

L'usage d'un proxy génère très souvent cette erreur : error="cookie_not_found"

A l'aide de "curl" ou "http toolkit" on peut mieux comprendre pourquoi elle arrive. Dans mon cas il s'agissait d'une redirection de cookie d'une règle précédente où était ajouté "Path: /TrucMuche/" dans le "Set-Cookie:".

Pour éviter cela il faut simplement localiser la règle ProxyPassReverseCookiePath avec les tags <Location "/auth/">... et hop :)

Voici les directives Apache2 à adapter et placer dans votre configuration du site web afin que les redirections soient opérationnelles :

# --- Keycloak START ---

ProxyRequests off
ProxyPreserveHost On

ProxyPass /auth/ https://domain.tld:8086/
ProxyPassReverse https://domain.tld:8086/(.*)$ https://domain.tld/auth/$1

# En-têtes X-Forwarded essentiels
Header always set X-Forwarded-Proto "https"
Header always set X-Forwarded-Port "443"
RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Port "443"
RequestHeader set X-Forwarded-For %{REMOTE_ADDR}s
<Location "/auth/">
# Gestion des cookies sécurisés
ProxyPassReverseCookieDomain domain.tld domain.tld
ProxyPassReverseCookiePath / /auth/
</Location>
#CAS DECOLE: Header edit Set-Cookie "^(.*)$" "$1; Secure; SameSite=None"
# --- Keycloak END ---

Installation

La version de keycloak utilisée est celle optimisée pour Docker. Il faut donc que "docker" soit installé avant d'aller plus loin (tutoriel d'installation)

Penser à Télécharger "Fichier:Keycloak:Dockerfile" et "Fichier:Keycloak:docker-compose.yml" afin de les modifier pendant la lecture des chapitres suivants.

Création de l'image

Le fichier Fichier:Keycloak:Dockerfile fourni contient les éléments essentiels à la création de l'image, ce qui est nécessaire pour construire le conteneur final.

soit :

FROM quay.io/keycloak/keycloak:26.3.2 AS builder

# Enable health and metrics support
# RAPPEL: non prit en charge : d'où les options --.* dans le RUN
#ENV KC_HEALTH_ENABLED=true
#ENV KC_METRICS_ENABLED=true

WORKDIR /opt/keycloak

# for demonstration purposes only, please make sure to use proper certificates in production instead
#RUN keytool -genkeypair -storepass password -storetype PKCS12 -keyalg RSA -keysize 2048 -dname "CN=domain.tld" -alias server -ext "SAN:c=DNS:localhost,IP:127.0.0.1" -keystore conf/server.keystore
#COPY /opt/keycloak/ /opt/keycloak/

FROM quay.io/keycloak/keycloak:26.3.2
COPY --from=builder /opt/keycloak/ /opt/keycloak/

RUN /opt/keycloak/bin/kc.sh build --db=mariadb --health-enabled=true --metrics-enabled=true --features="user-event-metrics,persistent-user-sessions"

ENTRYPOINT ["/opt/keycloak/bin/kc.sh"]

Si une autre base de données est utilisée, remplacer --db=Driver par celle employée.

ex: si mysql alors --db=mysql

voir les différent drivers supportés : https://www.keycloak.org/server/db

Une fois le fichier prêt, la création de l'image s'opère ainsi :

 docker . build -t keycloak   # Le Dockerfile doit-être dans le dossier courant...

Options Pré-Image

Options utilisables uniquement pendant la création de l'image. Elles déterminent le comportement du serveur Keycloak.

RUN /opt/keycloak/bin/kc.sh build ... --features="Option1,Option2"

<!> aucuns espace n'est permis entre chaque option, uniquement la virgule ","

La liste complète des features : https://www.keycloak.org/server/features

Création du conteneur final

Le fichier Fichier:Keycloak:docker-compose.yml contient les informations essentielles du serveur keycloak.

Bien évidement il faut l'adapter aux besoins spécifiques de votre entreprise. Voici son contenu :

services:
  keycloak:
    container_name: keycloak2
    user: "keycloak:5020" # UID and GID from /etc/passwd container / image
    image: keycloak:26.3.4
    #image: quay.io/keycloak/keycloak:26.3.2
    ports:
    #- ":8084:8080"
    #- ":8087:9000"
    - ":8086:8443"
    volumes:
    - /etc/letsencrypt/:/etc/letsencrypt/:ro

    environment:
    # BASE DBASE
    #KC_DB: mariadb # Already declared in the image!
    KC_DB_URL: jdbc:mariadb://172.17.0.1/keycloak?characterEncoding=UTF-8&useSSL=false
    KC_DB_URL_PORT: 3306
    KC_DB_USERNAME: kuser
    KC_DB_PASSWORD: "UnMotDePassTrèsFort" # The database password

    # Paramètres d'administration de Keycloak
    #Déclassé: KEYCLOAK_ADMIN: admin
    #Déclassé: KEYCLOAK_ADMIN_PASSWORD: admin
    KC_BOOTSTRAP_ADMIN_USERNAME: admin
    KC_BOOTSTRAP_ADMIN_PASSWORD: *********

    # Hostname and Proxy Configuration
    # Base URL where Keycloak can be accessed from a local network or the internet
    KC_HOSTNAME: https://domain.tld/auth/ # ou l'option: command: ... --hostname=https://domain.tld/auth/

    # Health Settings and Metrics
    #KC_HEALTH_ENABLED: "true"
    #KC_METRICS_ENABLED: "true"

    # LOGs
    KC_LOG: console
    KC_LOG_LEVEL: info
    KC_LOG_COLOR: true
    # Too verbose :
    #KC_LOG_CONSOLE_LEVEL: all
   

    #Valid SSL certificates and hourly reloading
    KC_HTTPS_CERTIFICATE_FILE: /etc/letsencrypt/live/domain.tld/fullchain.pem
    KC_HTTPS_CERTIFICATE_KEY_FILE: /etc/letsencrypt/live/domain.tld/privkey.pem
    KC_HTTPS_CERTIFICATES_RELOAD_PERIOD: 1h


    # Version for tests
    #command: start-dev --hostname-strict=false --proxy-headers forwarded --verbose
    command: start --verbose --http-enabled=true --proxy-trusted-addresses='''IP_SERVEUR'''/32,127.0.0.0/8 --proxy-headers=xforwarded --optimized

Adapter les variables :

KC_HOSTNAME (v2)
- Contient le nom que doit avoir le serveur keycloak.
- il peut aussi contenir l'url d'accès du serveur depuis l'extérieur.
  - Dans mon cas, je souhaite que keycloak soit accessible depuis internet, avec le certificat SSL valide du domaine principal. Ce qui induit l'usage d'un proxy afin que les demandes externes de https://domain.tld/auth parviennent à Keycloak de manière transparente et SURTOUT que les requêtes soient adaptées aux chemins dans le code de réponse en HTML...
KC_BOOTSTRAP_ADMIN_PASSWORD
- Le mot de passe d'accès à la console
KC_HTTPS_CERTIFICATE_FILE
- Certificat publique
KC_HTTPS_CERTIFICATE_KEY_FILE
- Clef privée
--proxy-trusted-addresses
- Remplacer les IPs autorisées à accéder directement au serveur keycloak 'dont' IP_SERVEUR.

Une fois Fichier:Keycloak:docker-compose.yml modifié la création et lancement s'effectue avec :

 docker compose up

Le conteneur devrait donc être créé et se lancer sans problème.

Accès à la console

Une fois le docker compose up lancé, la console admin est accessible: Accès console.

Les identifiants du super admin sont précisés dans le fichier Fichier:Keycloak:docker-compose.yml, soit par les variables :

KC_BOOTSTRAP_ADMIN_USERNAME: admin

KC_BOOTSTRAP_ADMIN_PASSWORD: ********* # Donc ce que vous avez mis à la place des étoiles ;)

Avant tout

La première connexion à Keycloak positionne l'utilisateur admin dans le realm "master".

Il est conseillé d'ajouter un compte d'administrateur et de désactiver l'actuel, ici 'admin'.

Sécurité

Création d'un nouveau compte admin du royaume (realm) 'master' et donc tous les nouveaux à venir...

Manage realms
- 'master'
- Users
- Add user et renseigner les champs
  - Username : kadmin
  - Email : EmailSUperValide!@domain.tld
  - Create
    - Credentials
      - Set password et saisir le mot de passe
      - Temporary : Off
      - Save
      - Save password
    - Role mapping
    - Assign role
    - Realm roles
      - admin
      - create-realm
      - Assign

Avant de désactiver le compte par défault 'admin', vérifier le nouvel accès depuis un autre navigateur ou connexion privé à : https://domain.tld/auth/admin/. Si vous avez le même affichages qu'avec l'accès 'admin' alors ce compte peut-être désactivé (ou supprimé)

Désactivation compte par défaut 'admin'

Avant tout, déconnectez votre navigateur du compte par défaut 'admin' et se reconnecter avec le nouveau compte 'kadmin'

Manage realms
- 'master'
- Users
  - 'admin'
  - cliquer sur 'Enable' afin que le bouton passe en 'disable'
  - disable

Création

A partir de ce chapitre l'espace dédié à l'entreprise (realm), ses groupes, utilisateurs et services (nommés clients) devront être créés. Sans oublier d'utiliser l'annuaire LDAP pour synchroniser les groupes et utilisateurs déjà existant et ainsi éviter de devoir recréer les accès des employés...

Realm / Royaume / Ferme / Organisation

Se nome "realm" et représente un groupement de services.

Cela pourrait être représenté comme un accès à une entreprise où elle peut gérer les identifications pour ses services (appelé client) et ses utilisateurs.

Chaque realm est unique et cloisonné. Donc une entreprise gère ses propres rêgles sans interférer avec un autre "realm" (entreprise)

Création de Gyptis, comme entreprise (realm), avec modifications de certains paramètre :

Manage realms
- Create realm
  - Realm name : Gyptis
  - Enable : On

Après la validation de création du realm, les sections "Manage" et Configure" seront dédiés à l'entreprise créée.

Précision importante, sauf information contraire, toutes les manipulations proposées dans ce document devront être effectuées dans le Royaume (realm) qui vient d'être crée.

Le repaire (en haut à gauche) Fichier:Keycloak:scr:realm Gyptis.jpg indique que le realm créé est sélectionné.

Contrairement à Fichier:Keycloak:scr:realm Master.jpg qui montre que le realm 'master' du serveur est sélectionné.

Journal des connexions

La création du nouveau 'realm' étant terminée, nous pouvons effectuer quelques réglages concernant l'activité de connexions dans l'ensemble du nouveau royaume.

Pour commencer nous voulons que toutes connexions, via keycloak, des services soient gardées dans le journal (log) pendant 1 heure :

Realms setting
- Events (onglet)
  - Event listeners (sous-onglet d'Events)
    - ajout de email
  - User events settings
    - save event: On
    - 1 hours expiration

ceci pour ne garder les 'events' de connexion pendant 1 seule heure

Admin events settings
- save event: On
- 1 hours expiration
Save

Sauvegarde des 3 onglets modifiés

Conseil: vous devriez effectuer ces mêmes manipulations dans le realm 'master', car par défaut ces logs ne sont pas actives et elles permettent d'avoir un aperçu quand quelque chose ne va pas. En production et sur des sites important peut-être faudra t-il les désactiver...

Accès direct

Une fois le 'realm' créé et configuré ses utilisateurs pourront s'identifier avec l'interface de Keycloak accessible depuis : https://domain.tld/realms/Gyptis/account.

Cette interface permet de voir des détails sur le compte utilisateur identifié : les groupes, les clients...

Groupes

La gestion des groupes est similaire à n'importe quel annuaire (AD, ldap, ...). Créer un groupe est chose aisée.

Un groupe 'admins' doit-être créé :

Groups
- Create group
  - Name: Admins
  - Save

Cependant il est nullement utile d'en créer d'autres pour le moment, car ils vont être importés depuis la base Ldap de l'entreprise depuis le menu User Federation plus bas.

Compte utilisateur

Un compte administrateur et utilisateur sont à créer.

L'accès Administrateur servira à l'entreprise créée pour la gestion de son realm.
- ATTENTION: cet accès devra être créé depuis le realm 'master'
L'accès utilisateur est destiné à effectuer les premiers essais du royaume Gyptis récement créé. Il faudra donc le créer dans son 'realm'
- il pourra être désactivé par la suite...

Création

Accès admin pour Gyptis

Manage realms
'master'
Users
- Add user
  - Email vérifié : On
  - Username : admin-gyptis
  - Email : un_vrai_email@domain.tld
  - First Name :
  - Last name :
  - ~~Join Groups~~
    - ~~Sélectionner 'admin'~~
    - ~~Join~~
  - Create
- Credentials (nouvel onglet)
- Set password
  - Saisir le mot de passe 2 fois...
  - Temporay : Off
  - Save
  - Save password
- Assign role
- Client roles
- Search : Gyptis
  - Cocher : tous les rôles portant le nom Gyptis-* dans la colonne ClientID
  - Assign

Une fois terminé revenir dans le royaume (realm) Gyptis

Fortement conseillé : A partir de ce point, on peut se déconnecter du compte "kadmin" et continuer avec le compte 'admin-gyptis' pour régler les détails du royaume Gyptis soit à : https://domain.tld/auth/admin/

Il est établi que vous suivez se conseil et vous laisse découvrir ce qui a changé...

Accès utilisateur

Manage realms
Gyptis
- Users (du royaume Gyptis!)
  - Add user
    - Email vérifié : On
    - Username : SonNom
    - Email : un_autre_vrai_email@domain.tld
    - First Name :
    - Last name :
    - Create

Compte client

L'authentification d'application d'un site client (tuto officiel)

Le compte client représente les rêgles et informations d'un service du 'realm'.

Pour permettre au Cloud et le Wiki de l'entreprise d'utiliser Keycloak comme moyen d'identification, un 'client' doit-être créé dans la section 'Manage->clients' pour chaque service : nextcloud et mediawiki.

Création de compte client

Il faut créer les deux clients avec le minimum d'information, les détails important seront configurés plus bas.

Manage -> Clients -> Create client

Client ID: nextcloud
Name : ${my_client} (optionnel)
Next
Next (arrivé dans Login settings)
Save

Faire pareil pour mediawiki.

Paramétrage des comptes clients

Nextcloud

Le Cloud est géré par Nextcloud (valable aussi pour owncloud) avec l'application 'OpenID Connect user backend'

Clients -> nextcloud
- General settings
  - Client ID : nextcloud
  - Name : ${my_client} (optionnel)
- Access settings
  - Root URL : https://domain.tld/NextCloud/
  - Home URL : https://domain.tld/NextCloud/index.php
  - Valid redirection URIs : https://domain.tld/NextCloud/index.php/apps/user_oidc/code
  - Valid post logout redirects URIs: https://domain.tld/NextCloud/index.php/apps/user_oidc/logout
  - Web Origin : https://domain.tld/NextCloud/
  - Admin URL :
- Capability config
  - Client authentification : On
  - Authorization : On
    - Standard flow
    - Direct access grants
    - Service accounts roles
    - Standard Token Exchange
    - OAuth2.0 Device Authorization grants
- Login settings
  - Login theme : optionel
  - Consent required : Off
  - Display client on screen : Off
- Logout settings
  - Front channel logout : Off
    - Backchannel logout URL : https://domain.tld/auth/realms/Gyptis/protocol/openid-connect/auth/device
    - Backchannel logout session required : On
    - Backchannel logout revoke offline sessions : On
- Save
- Keys (onglet)
  - Use JWKS URL configs: On
  - JWKS URL : https://domain.tld/NextCloud/index.php/apps/oidc/jwks
  - Save
- Client scopes
  - address
  - firstName
  - organization
  - phone
  - profile
  - roles
  - service-account
  - web-origins : Default

Mediawiki

Le wiki est géré par mediawiki avec extension OpenIDConnect.

Clients -> mediawiki
- Settings
  - Root URL : https://domain.tld/MediaWiki/index.php
  - Valid redirection URIs : https://domain.tld/MediaWiki/*
  - Valid post logout redirects URIs: https://domain.tld/MediaWiki/index.php/Special:UserLogout
  - Web Origin : https://domain.tld/MediaWiki/
  - Admin URL : https://domain.tld/auth/realms/Gyptis/account
- Login settings
- Capability config
  - Client authentification : On
  - Authorization : On
    - Standard flow
- Logout settings
  - Backchannel logout URL : https://domain.tld/MediaWiki/rest.php/pluggableauth/v1/logout
  - Backchannel logout session required : On
  - Backchannel logout revoke offline sessions : On
- Save
- Client scopes
  - les mêmes que pour le client 'nextcloud'

Une fois ces deux clients créés, les services mediawiki et nextcloud pourront utiliser Keycloak pour identifier les utilisateurs de l'entreprise.

Cependant, comme le décrit le But, nous voulons que les utilisateurs puissent avoir accès aux deux services avec une seule identification et que chaque déconnexion d'un services, déconnecte l'utilisateur des autres...

La section suivante décrit comment faire.

Autorisation applicative

C'est ici qu'on règle Keycloak pour qu'il permette l'accès aux trois services comme Nextcloud, Mediawiki et lui-même avec une seule identification.

L'identification sur l'un de ces services donnera l'accès aux autres sans devoir recommencer le processus.

Partie 'clients'

Un Role nominatif doit-être créé dans chaque client

Pour mediawiki et nextcloud les noms seront : access-mediawiki et access-nextcloud, soit en notation logique : access-[mediawiki|nextcloud]. Il faudrait donc assigner le role

Résumé de la configuration à effectuer pour chaque client :

Client->[nextcloud | mediawikip]
- Roles->Create Role : access-[nextcloud | mediawikip]
- puis l'onglet Client Scopes->[nextcloud | mediawikip]-dedicaced
  - Add Mapper, From predefined mapper
  - et choisir "client roles"

Soit précisément

Role de Nextcloud	Role de Mediawiki
Client nextcloud Roles Create Role Role name: access-nextcloud Save & Cancel Client Scopes nextcloud-dedicaced Add Mapper, From predefined mapper et choisir "client roles" Add	Client mediawiki Roles Create Role Role name: access-mediawiki Save & Cancel Client Scopes mediawiki-dedicaced Add Mapper, From predefined mapper et choisir "client roles" Add

Partie 'groups'

Groups
- Create group
  - Name: SonNom
  - Save
Groups
SonNom
- Role mapping
  - Assign role
  - client roles et sélectionner :
    - access-nextcloud
    - access-mediawiki
  - Assign

Pour un utilisateur existant

- Users
- NomUser
  - Role mapping
    - Assign role
    - client role
      - access-nextcloud
      - access-mediawikip

Congrulation !

Toutes les étapes nécessaires ont été créées. Les services peuvent utiliser l'identification unique, mais avant il faut les paramétrer afin de les faire connecter au service Keycloak.

Connecter les services à Keycloak

-- en cours d'écriture --

Configuration LDAP

Keycloak est en mesure de gérer des utilisateurs et des groupes : ajouter, modifier, supprimer, ...

Cependant les entreprises possèdent très souvent un annuaire LDAP (AD ou OpenLDAP) et Keycloak permet de l'utiliser et ainsi éviter une conversion, transfert...

Dans ce qui suit, on trouve des ObjectClass et attributs lié à une base gérée sous Linux avec OpenLDAP.

Les schémas utilisées sont : core, cosine, samba, inetorgperson et nis.

Si on utilise FusionDirectory, les ObjectClass / Attributs seront les mêmes.

Pour connaître les objectClass :

Employer pour connaitre les ObecjtClass des utilisateurs :

ldapsearch -LLL -Q -Y EXTERNAL -H "ldapi:///" "uid=$(whoami)" "objectclass"

Employer pour connaitre les ObecjtClass des groupes :

ldapsearch -LLL -Q -Y EXTERNAL -H "ldapi:///" "cn=$(whoami)" objectClass

En cas d'échec des deux premiers ldapsearch, utiliser :

ldapsearch -LLL -Q -Y EXTERNAL -H "ldapi:///" | less

Et rechercher une fiche d'utilisateur puis celle d'un groupe qui contient cette utilisateur.

Sinon contactez notre ami IA ;)

User federation

Deux choix pour ajouter un provider Kerberos et/ou LDAP

S'il existe déjà un provider enregistré, passez directement à Add LDAP provider pour ajouter un annuaire existant LDAP...

Add LDAP providers

Add new provider->LDAP (Partie settings)

UI display name : Ldap
- Vendor : Other

Connetion and authentification setting

Connection URL : ldap://ldap.domain.tld/
Enable StartTLS : Off
Use Trustore SPI : Always
Connection pooling : On
Connection timeout :
Bid type : simple
Bind DN : cn=ro,dc=gyptis
Bind credentials : le mdp de l'accès ci-dessus

LDAP searching and updating

Edit mode : READ ONLY
Users DN : ou=People,dc=gyptis
Relative user creation DN :
Username LDAP attribute : cn
RDN LDAP attribute : uid
UUID LDAP attribute : entryUUID
User object classes : posixAccount
User LDAP filter : (|(objectclass=gosaMailAccount)(objectclass=inetOrgPerson)(objectclass=organizationalPerson)(objectclass=posixAccount)(objectclass=sambaSamAccount)(objectclass=top))
Search scope : One Level
Read timeout :
Pagination : Off
Referal :

Synchronizations settings

Import users : Off (On en mode production)
Sync Registrations : : On
Batch size : 124000
Periodic full sync : Off
Periodic changed users sync : Off
Remove invalid users during searches : Off

Kerberos integration

Allow Kerberos authentification : Off
Use Kerberos for password authentification : Off

Cache settings

Cache policy : DEFAULT

Advanced settings

Enable the LDAPv3 password modify extended operation : Off
Validate password policy : Off
Traust Email : On
Connection trace : Off

Importer les groupes LDAP / AD dans Keycloak.

Mapper

Mappers->Add mapper

Name : groupOfNames
Mapper type : group-ldap-mapper
LDAP Groups DN : ou=groups,dc=gyptis
Relative creation DN :
Group Name LDAP Attribute : cn
Group Object Classes : groupOfNames,posixGroup,gosaGroupOfNames
Preserve Group Inheritance : On
Ignore Missing Groups : Off
Membership LDAP Attribute : member (ou memberUid)
Membership Attribute Type : DN
Membership User LDAP Attribute : uid
LDAP Filter : (&(|(objectclass=groupOfNames)(objectclass=posixGroup)(objectclass=gosaGroupOfNames)))
Mode : READ_ONLY
User Groups Retrieve Strategy : LOAD_GROUPS_BY_MEMBER_ATTRIBUTE
Member-Of LDAP Attribute : ~~memberOf~~
Mapped Group Attributes :
Drop non-existing groups during sync : Off
Groups Path : /

Champs renvoyés aux clients

Il peut arriver que le client ait besoin d'un champ particulier pour rendre cohérent le nouveau moyen d'identification (avec keycloak) et sa base de données.

C'est le cas ici avec Nextcloud/owncloud qui utilise openLDAP pour identifier les utilisateurs. Le champ 'entryUUID' est employé pour créer le dossier de l'utilisateur.

Or keycloak ne connait pas ce champ et si un utilisateur existant, avant l'usage de keycloak, se connecte pour accéder à son cloud il ne verra plus son contenu avec l'impression que tout a été perdu.

Pour anticiper ce problème il faut donc créer un scope et mapper afin que nextcloud puisse récupérer le champ 'entryUUID' des utilisateurs, sans oublier de configurer son module "user_oidc" pour qu'il demande ce champ.

Cette méthode fonctionne pour n'importe quel champ, il suffit juste de remplacer "entryUUID" par le mot-clef de votre choix et existant dans LDAP...

Client scopes
- Create client scope
  - Name : entryUUID-scopes
  - Type: Default
  - Display on consent screen : Off
  - Include in token scope : Off
  - Display order : 30
- Mappers
  - Add mapper
  - By configuration
    - User Attribute (custom Attribute) : entryUUID
      - L'attribut qui sera envoyé par Keyc
        On pourrait faire renvoyer l'email, username, ...
    - Token Claim Name : entryUUID
      - l'attribut demandé par le client
    - Claim JSON Type : String
    - Add to ID token : On
    - Add to access token : On
    - Add to userinfo : On
    - Add to introspection : On
    - Le reste à Off

Coté 'provider / User federation'

Dans Nextcloud/Owncloud lorsque l'utilisateur est importé depuis LDAP, c'est entryUUID qui est utilisé.

Il faut donc régler le 'provider' LDAP pour qu'il récupère ce champ.

User federation
OpenLDAP, donc un provider existant ;)
- Mappers
- Add mapper
  - Name : entryUUID
  - Mapper type : user-attribute-ldap-mapper
  - User Model Attribute : entryUUID
  - LDAP attribute : entryUUID
  - Read only : On
  - tout le reste à Off

Coté nextcloud

Ordonner à Nextcloud / user_oidc de demander le champs désiré :

Editer le provider 'keycloak'.
Dans la partie "User ID mapping" ou "Correspondance de l'ID de l'utilisateur"
Ajouter "entryUUID" (par défaut est affiche 'sub' ! )

Modification de champs

Par l'utilisateur

Par défaut, l'utilisateur peut modifier certains champs comme son email, FirtName, LastName...

Pour un site public comme des forums cela ne pose pas de souci, cependant dans une entreprise le problème est tout autre.

Pour empêcher les modifications de [ email | firstName | lastName ]

Realm settings
User profile
Editer les attributs 1 à 1 soit : email & firstName & lastName

Décocher User à : "Who can edit?"

Annexes

Portail

Regroupement de service

Voir comment s'identifier directement dans Keycloak et le faire aller sur un portail avec tous les services...

https://domain.tld/auth/realms/Gyptis/account

Liste des commandes

Liste des options de configuration lors de la création du conteneur

Concordances

Concordances entre options de lancement, keycloak.conf et variables.

Terminologies

Root Url
- Adresse de base du client, si les autres champs on des chemins relatif, ils seront complété par l'url contenue dans "Root Url"
Home Url
- Indique l'entrée du site client, la page principale.
Valid Redirect URIs
- Liste d'URIs définissent le périmètre autorisé des URLs, elles sont comparées, leurs débuts, avec chaque URL employées lors de redirections.
  - Ex: Si on place une seule URI, dans ce champ, comme "https://my.keycloak.tld/path/*''" et qu'une de vos redirections validant une identification, ou fin de connexion, pointe vers "https://other.domain.com/''" keycloak refusera de l'utiliser. Ce qui réduit le risque de pishing.
Valid post logout redirect URIs
- Liste d'URIs autorisées à être utilisées par keyclock, idem que pour "Valid Redirect URIs" mais pour la déconnexion.
Web origins
- Liste de domaines destinés aux requêtes CORS et "silent refresh" gérés par des connexions via javascript
- Admin URL
- URL où envoyer les notifications d'admin, déconnexion forcée, revocation de token, .... Sa destination doit gérer les endpoint backend autrement peut-être laissée vide.
Backchannel logout URL
- URL permettant à Keycloak de terminer la session utilisateur lorsque celui-ci se déconnecte d'un autre client.
- Généralement l'url ressemble à : https://domain.tld/auth/realms/Gyptis/protocol/openid-connect/auth/device
- https://domain.tld/auth/realms/Gyptis/protocol/openid-connect/auth/device
- Pour mediawiki : https://domain.tld/rest.php/pluggableauth/v1/logout
- Backchannel logout session required
  - Force a ajouter les informations de session dans lA procédure back-channel
- Backchannel logout revoke offline sessions
  - Force la fermeture des sessions persistante comme celles où "Se souvenir de moi" est cochée.

LDAP

RDN LDAP
- Relative Distinguished Name

Anonyme

Rechercher

Modèle:Keycloak:Tutorial

But

Raison

Approche

Prérequis

Optionnel

Conseil

Autre tutoriel

Préparation

Base de données externe

Mariadb / Mysql

Syntaxe KC_DB

Exemple

Parfeu

Iptables

nft

Certificats SSL

Méthode d'accès par montage

Réattribué les droits d'accès aux certificats SSL

Méthode pkcs12

Apache proxy

Installation

Création de l'image

Options Pré-Image

Création du conteneur final

Adapter les variables :

Accès à la console

Avant tout

Sécurité

Désactivation compte par défaut 'admin'

Création

Realm / Royaume / Ferme / Organisation

Journal des connexions

Accès direct

Groupes

Compte utilisateur

Création

Accès admin pour Gyptis

Accès utilisateur

Compte client

Création de compte client

Paramétrage des comptes clients

Nextcloud

Mediawiki

Autorisation applicative

Partie 'clients'

Partie 'groups'

Pour un utilisateur existant

Congrulation !

Connecter les services à Keycloak

Configuration LDAP

User federation

Add LDAP providers

Connetion and authentification setting

LDAP searching and updating

Synchronizations settings

Cache settings

Advanced settings

Importer les groupes LDAP / AD dans Keycloak.

Mapper

Champs renvoyés aux clients

Coté 'provider / User federation'

Coté nextcloud

Modification de champs

Par l'utilisateur

Annexes

Portail

Liste des commandes

Concordances

Terminologies

Navigation

Outils wiki

Outils de la page

Liste des catégories