Tutoriel
Keycloak

version 1.0

Créé le 22 Juillet 2025
Mise en ligne 21 Septembre 2025.
Mise à jour le 26 Septembre 2025.
Langue English - French

Auteur

José Mans

But

Raison

Uniformiser la connexion aux services Web de l'entreprise dont MediaWiki et Nextcloud toute en continuant d'utiliser l'annuaire LDAP (AD).

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

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 v11
Docker-ce
Apache2
Certificat SSL

Optionnel

OpenLDAP ou Active Directory

Conseil

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

Les fichiers sont dispinible avec les noms 'Dockerfile.txt et docker-compose.7z', il est évident qu'il faut les renommer et décompresser en Dockerfile et docker-compose.yml 😉

Autre tutoriel

Tutoriel officiel : [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) et du fonctionnement propre à Docker.

Syntaxe KC_DB

Une fois la table et l'utilisateur créé le 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 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 "Dockerfile" et "docker-compose.yml" afin de les modifier pendant la lecture des chapitres suivants.

Création de l'image

Le fichier 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.4 AS builder

# Enable health and metrics support
# RAPPEL: non pris 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.4
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érents 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 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 de Keycloak...
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.

Premier lancement

Une fois 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.

Pandant le processus il y aura des avertissements concernant mariadb et ce qui ne supporte pas suivi d'une longue attente (2 minutes...).

Voici un extrait de message qui confirme que le serveur s'est correctement lancé :

keycloak2  | 2025-09-24 13:22:15,825 INFO  [io.quarkus] (main) Profile prod activated.
keycloak2  | 2025-09-24 13:22:15,825 INFO  [io.quarkus] (main) Installed features: [agroal, cdi, hibernate-orm, jdbc-mariadb, keycloak, micrometer, narayana-jta, opentelemetry, reactive-routes, rest, rest-jackson, smallrye-context-propagation, smallrye-health, vertx]

[+] Screenshoot

Accès à la console

Une fois le docker compose up lancé, la console admin est accessible: Accès console -> https://domain.tld/auth/.

Les identifiants du super admin sont précisés dans le fichier 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' (Normalement déjà sélectioné)
- Users
- Add user et renseigner les champs
  - Email verified : On
  - 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
  - Create

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) indique que le realm créé est sélectionné.

Contrairement à qui montre que le realm 'master' du serveur est sélectionné.

Groupes

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

Un groupe administrateur doit-être créé pour Gyptis :

Manage realms
'master'
Groups
- Create group
  - Name: Gadmins
  - Description : Groupe pour les Admins de Gyptis
  - Create

Attribution des droits Admins pour Gadmins

Groups
- Gadmins
- Role mapping
- Assign role
- Client roles
  - Search : Saisir Gyptis-realm et valider
    - afin de n'afficher que les roles liés au royaume
  - Sélectionner tous les roles Gyptis-*
  - Assign

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 pour le royaume Gyptis.

L'accès Administrateur servira à l'entreprise 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...

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 'Gadmins'
    - 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/realms/Gyptis/account

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

Accès utilisateur

Uniquement pour effectuer les premiers essais...

Manage realms
Gyptis
- Users (du royaume Gyptis!)
  - Create new user (ou Add user)
    - Email vérifié : On
    - Username : Guser
    - Email : un_autre_vrai_email@domain.tld
    - First Name :
    - Last name :
    - Create
- Credentials (nouvel onglet)
- Set password
  - Saisir le mot de passe 2 fois...
  - Temporay : Off
  - Save
  - Save password

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/auth/realms/Gyptis/account.

C'est le cas pour Guser et non admin-Gyptis

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 : (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 : Nextclound Client (optionnel)
- Access settings
  - Root URL : laisser vide
  - Home URL : https://domain.tld/NextCloud/index.php
  - Valid redirection URIs : https://domain.tld/NextCloud/*
  - Valid post logout redirects URIs: https://domain.tld/NextCloud/*
  - Web Origin : +
  - Admin URL : https://domain.tld/Nextcloud/index.php/settings/admin
- 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/Nextcloud/index.php/apps/user_oidc/backchannel-logout/Keycloak
      - 'Keycloak' représente le nom du provider dans la configuration de Nextcloud/user_oidc...
    - Backchannel logout session required : On
    - Backchannel logout revoke offline sessions : Off
- 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
- General settings
  - Client ID : mediawiki
  - Name : Mediawiki client (optionnel)
  - Root URL : laisser vide
  - Valid redirection URIs : https://domain.tld/MediaWiki/*
  - Valid post logout redirects URIs: https://domain.tld/MediaWiki/*
  - Web Origin : +
  - Admin URL : https://domain.tld/MediaWiki/Special:UserLogin
- Login settings
- Capability config
  - Client authentification : On
  - Authorization : On
    - Standard flow
- Logout settings
  - Front channel logout : Off
  - Backchannel logout URL : https://domain.tld/MediaWiki/rest.php/pluggableauth/v1/logout
  - Backchannel logout session required : On
  - Backchannel logout revoke offline sessions : Off
- 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, Add predefined mapper ou selon : 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, Add predefined mapper ou selon : From predefined mapper et choisir "client roles" Add

Partie 'groups'

Autorisation d'utiliser l'identification unique au groupe.

Méthode par groupe, valable pour ceux appartenant à Keycloak mais aussi ceux importés avec LDAP ou Kerberos...

Création du groupe

Groups
- Create group
  - Name: Gyptis_Group
  - Create

Attribution applicative pour le groupe

Groups
Gyptis_Group (ou n'importe quel autre...)
- Role mapping
  - Assign role
  - client roles et sélectionner :
    - access-nextcloud
    - access-mediawiki
  - Assign

Pour un utilisateur existant

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

Précision importante: Lorsque la base LDAP sera connectée, ses groupes seront importés et donc visibles dans le menu Groups de la console. Il faudra donc effectuer les mêmes manipulations que ci-dessus afin d'autoriser les membres du groupe(s) LDAP à utiliser acces-mediawiki et access-nextcloud.

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

Connecter les services à Keycloak

Les comptes clients étant créés il est temps de configurer Mediawiki et Nextcloud afin qu'il puissent utiliser Keycloak pour identifier les utilisateurs.

L'installation n'est pas très exigeante et ne mérite pas un énième tutoriel, aussi voici les liens des Tutos aidant à installer les modules OpenId Connect des deux services :

Mediawiki : https://www.mediawiki.org/wiki/Extension:OpenID_Connect/fr

Nextcloud : https://github.com/nextcloud/user_oidc

Récupérer client_secret

Lors de la création de chaque client, un mot de passe 'unique' est créé. Celui-ci est prévu pour être utilisé par le client de chaque service.

Client->[Nextcloud & mediawiki ] -> Credentials -> Copiez 'Client secret' et placez-le ci-dessous.

Configuration coté client

Mediawiki

Méthode depuis un shell

Edit LocalSetting.php

wfLoadExtension( 'OpenIDConnect' );

# uri de vérification, si json apparait OK : https://domain.tld/auth/realms/Gyptis/.well-known/openid-configuration
$wgPluggableAuth_Config["Gyptis"] = [
    'plugin' => 'OpenIDConnect',
    'data'  => [
            'providerURL'           => 'https://domain.tld/auth/realms/Gyptis',
            'clientId'              => 'mediawiki',
            'clientSecret'          => '*********',
            'codeChallengeMethod'   => 'S256',
            'scope' => [ 'openid', 'profile', 'email', 'firstName', 'address', 'organization', 'phone', 'profile', 'roles', 'web-origins' ],
                ],
];

$wgOpenIDConnect_SingleLogout      = true; # déconnecter l'user aussi sur KeyC

# Change la redirection, idéale pour aller au Portail quand déco.
#$wgHooks['UserLogoutComplete'][] = function ( $user, &$inject_html, $old_name ) {
#   // Redirige vers l'URL préférée après déconnexion.
#   header( "Location: https://Portail-Entreprise/" );
#   exit;
#};

# Variables pour forcer l'identification et donc empêcher la lecture des articles par les anonymes.
$wgPluggableAuth_EnableAutoLogin = true; # False permet la navigation, 'true' oblige à s'identifier. Mais ne fonctionne pas sans celle ci-dessous!
$wgGroupPermissions['*']['read'] = true;    # Oblige l'identification pour lire les articles.

Si on veut que Keycloak devienne le seul moyen d'identification, il faut désactiver tous les autres, ldap, celui de MW...

$wgPluggableAuth_EnableLocalLogin	= false;
$wgPluggableAuth_Config				= array(); # <!> Ce qui implique que count( $wgPluggableAuth_Config[] ) ne contienne qu'un seul champ!
$wgPluggableAuth_Config["..."]  placer ici la config pour Open ID...
...

cd /var/www/MediaWiki
sudo -u www-data -g www-data php maintenance/run.php --conf /var/www/MediaWiki/LocalSettings.php update --quick --force

Si des caches existent :

# Adaptez selon la configure de votre serveur!
systemctl restart "php*" 
systemctl restart redis-server memcached 
redis-cli FLUSHDB
redis-cli -n DB_NUMBER FLUSHDB
redis-cli -n DB_NUMBER FLUSHDB ASYNC
redis-cli FLUSHALL
redis-cli FLUSHALL ASYNC
(echo "flush_all" )

Nextcloud

Ajouter l'extention OpenID Connect (user_oidc)

Installation de OpenID Connect
- Entrer dans la console admin de Nextcloud
- Ouvrir le menu Application et aller dans Sécurité.
- Rechercher "OpenID Connect user backend", téléchargez-le et activez-le.
Retourner dans la console admin, puis ouvrir le nouveau menu "OpenID Connect"
- Registered Providers ou Fournisseurs enregistrés

Méthode depuis un shell

Ligne de commande occ :

Minimaliste :

sudo -u www-data -g www-data php occ user_oidc:provider Keycloak --clientid="nextcloud" \
    --clientsecret="***********" \
	--discoveryuri="https://domain.tld/auth/realms/Gyptis/.well-known/openid-configuration"

Complète :

sudo -u www-data -g www-data php occ user_oidc:provider Keycloak \
    --clientid="nextcloud" \
    --clientsecret="***********" \
	--discoveryuri="https://domain.tld/auth/realms/Gyptis/.well-known/openid-configuration" \
	--scope="openid email address organization phone profile roles web-origins organization groupOfNames-scope" \
	--mapping-display-name="displayName" \
	--mapping-email="email" \
	--mapping-uid="entryUUID | username | email" \
	--mapping-groups="groupOfNames" \
	--mapping-language="preferredLanguage" \
	--mapping-website="labeledURI" \
	--mapping-avatar="jpegPhoto" \
	--mapping-phone="phone" \
	--unique-uid=false \
	--check-bearer=true \
	--send-id-token-hint=true \
	--bearer-provisioning=true \
	--group-provisioning=true \
	--group-whitelist-regex="^(cloud|dedie|famille)\$" \
	--resolve-nested-claims=false \
	--group-restrict-login-to-whitelist=true # false for test...

Méthode depuis console WEB

Configuration

Client configuration
- Identifier : Keycloak
- Client ID: nextcloud
- Client secret : à récupérer
- Discovery endpoint : https://domain.tld/auth/realms/Gyptis/.well-known/openid-configuration
- Custom end session :
- Scope : openid email address organization phone profile roles web-origins groupOfNames-scope entryUUID-scope
  - Les deux champs en gras sont essentiels si on compte utiliser LDAP (voir plus bas), Sinon, ne pas les ajouter.
    - leurs création est détaillée à Champs renvoyés aux clients
- Extra claims :
Attribute mapping
- Enable nested and fallback ... :
- User ID mapping : entryUUID | sub
  - ou celui adapté à votre config, ex: uid
    - entryUUID => user from Ldap
    - sub => user from Keycloak

Avant d'utiliser Keycloak, si vous utilisiez Nextcloud/owncloud + LDAP, il est très probable que les noms de dossiers portent le nom contenu dans entryyUUID de chaque propriétaire.
Si vous voulez avoir des noms de dossiers plus humain, remplacer 'sub' par autre chose comme 'email'. Évidement si l'utilisateur quitte l'entreprise et qu'un homonyme prends sa place, il aura l'email de l'ancien, ce qui nécessite de penser à supprimer de Nextcloud le salarié désembauché...

Quota mapping :
Groups mapping : groups

Extra attributes mapping
- Email mapping : email
- Language mapping : preferredLanguage
- Phone mapping : phone
- Website mapping : labeledURI
- Avatar mapping : jpegPhoto
Authentication and Access Control Settings
- Use unique user ID :
- Use provider identifier as prefix for IDs :
- Use group provisionning :
  - Group whitelist regex : ^(nextcloud|mediawiki|ceux de votre entreprise... ET présent dans Keycloak)$ Explication détaillée...
    - Une fois ce chapitre terminé, penser à consulter Champ renvoyé
- Restrict login for users that are not in any whitelist group :
  - Autorise l'accès qu'aux utilisateurs étant dans le(s) groupe(s) ci-dessus (Group whitelist)
- Check Bear token on API and WebDAV .... :
- Auto provision user when accessing API and WebDAV :
- Send ID token hint on logout :
Submit ou Updater provider

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 ; le principe est le même pour Active Directory...

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

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

Recherche de la base DN :

base=$(ldapsearch -LLL -Q -Y EXTERNAL -H "ldapi:///" "(&(objectClass=organization)(objectClass=dcObject))" "dn:"| sed -re 's/^dn: *(.*)/\1/')

à utiliser avec les commandes ci-dessous...

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:///" -b "$(ldapsearch -LLL -Q -Y EXTERNAL -H "ldapi:///" -b "ou=groups,${base}"   "(&(objectClass=posixGroup)(memberUid=$(whoami)))" cn | grep -E "^dn: cn=.*groups.*" | sed -re 's/^dn: *(.*)$/\1/g' | head -1)" objectClass

ou

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

si le groupe "$(whoami)" existe !

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 mot de passe 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
Trust Email : On
Connection trace : Off

Save

Importer les groupes LDAP / AD dans Keycloak.

Mapper

User federation
- entrer dans la configuration créée ci-dessus, par défaut son nom est 'ldap'
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 sur AD)
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 : /
Save

Utiliser : Sync LDAP groups to Keycloak, du bouton Action au coin supperieur droite.

Si la récupération des groupes est effectuée, la confirmation doit se faire après avoir effectuer le choix.

A ce stade, on peut attribuer, à certains groupes LDAP, le droit d'utiliser l'authentification unique en applicant la procédure Partie 'groups'

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 ses bases de données.

Il faut donc rendre certains champs disponibles, aux clients, en déclarant leurs roles et les mapper. Dans la déclaration de LDAP on créait des 'mappers' en précisant ce qui doit-être récupérer. Ces données sont en mémoire dans Keycloak.

Cependant cela ne sert à rien si on ne rend pas disponible leurs noms et contenus aux clients qui en ont besoins. Ici on décide quel client pourra avoir accès au contenu de ces valeurs.

groupOfNames et entryUUID

La plupart des services ont besoin de connaître les groupes auxquels appartiennent un utilisateur. Mais aussi son identifiant unique que pas même un homonyme peut avoir. Il s'agit souvent du champ 'uid'.

Les champs 'groupOfNames' et 'entryUUID' sont nécessaires au bon fonctionnement des deux services et leurs 'roles' sont à définir comme décrit ci-dessous.

Particularité à Nextcloud

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.

entryUUID-scope

groupOfNames-scope

Client scopes
- Create client scope
  - Name : entryUUID-scope
  - Type: Default
  - Display on consent screen : Off
  - Include in token scope : On
  - Display order : 30
  - Save
- Mappers
  - Configure a new mapper
    - si d'autres existent alors : Add mapper
    - puis By configuration
  - User Attribute
    - Name : entryUUID
    - User attribute : entryUUID
      - L'attribut qui sera envoyé par Keyc
        On pourrait faire renvoyer l'email, username, ...
    - Token Claim Name : entryUUID
      - Ce qui est demandé par le client nextcloud à User ID mapping de "Attribute mapping". du client
      - l'attribut demandé par le client
    - Claim JSON Type : String
    - Add to ID token : On
    - Add to access token : On
    - Add to lightweight access token : Off
    - Add to userinfo : On
      - userinfo (userinfo_endpoint) représente les informations reçues par le client, il n'y a donc pas besoin d'ajouter entryUUID-scope dans le scope de la demande quand c'est sur 'On'...
    - Add to introspection : On
    - Le reste à Off
  - Save && Cancel

Client scopes
- Create client scope
  - Name : groupOfNames-scope
  - Type: Default
    - Default indique de fournir ce champ sans devoir le préciser dans le 'scope' (soit par authorization_endpoint)
  - Display on consent screen : Off
  - Include in token scope : On
  - Display order : 30
  - Save
- Mappers
  - Configure a new mapper
    - si d'autres existent alors : Add mapper
    - puis By configuration
  - Group Membership
    - Name : groupOfNames
    - Token Claim Name : groupOfNames
    - Full group path : Off
      - A on, le nom du groupe est envoyé avec le chemin. Si aucun n'est précisé, c'est "/" qui en ajouté au nom, soit : /VotreGroup...
    - Add to ID token : On
    - Add to access token : On
    - Add to lightweight access token : Off
    - Add to userinfo : On
    - Add to introspection : On
  - Save && Cancel

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...

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
Ldap, 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
  - 'Save

Coté Groups

Il faut penser à attribuer les applications autorisées aux groupes de la base LDAP qui ont été importés depuis User fédération.

La procédure a déjà été abordée pour l'attribution de l'utilisateur, au Group_Gyptis, servant aux essais (guser).

Voici donc le raccourci :

Groups->(sélection groupe LDAP pour membre du cloud...)->Role mapping->Assign role->client roles->[entryUUID-scope | groupOfName-scope ]->Assign

Cependant il faudra effectuer les ajouts aux groupes importés depuis la base LDAP. Donc autre chose que 'Group_Gyptis'. Dans notre entreprise les utilisateurs ayant plein droit à utiliser l'application Nextcloud sont dans le groupe portant le même nom, soit 'nextcloud'. Il faut donc juste suivre la procédure, ci-dessus Attribution applicative pour le groupe, et configurer les groupes de votre organisation.

Coté Client scopes

Clients
Nextcloud
Client scopes
- Add client scope
  - les deux nouveaux 'client scopes', créés ci-dessus, doivent apparaitre dans la liste
  - Sélectionner groupOfName-scope et entryUUID-scope
  - Add
  - Default

Faire pareil pour mediawiki, excepté entryUUID qui ne lui servira pas.

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 affiché 'sub' ! )
- On peut combiner comme décrit à Attribute mapping dans le cas où deux bases users sont utilisées.

Cette modification permettra aux utilisateurs de la base LDAP de se connecter et revoir le contenu de leur cloud. Cependant, les utilisateurs qui ne sont pas dans la base LDAP ne pourront pas utiliser Nextcloud sans combiner les deux ainsi : entryUUID | 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?"

Congrulation !

Une fois toutes les étapes, ci-dessus, appliquées, l'identification unique devrait être opérationnelle.

Chaque connexion ou déconnexion à un des services, se fera aux autres.

Pour toutes questions vous pouvez me contacter par le formulaire web en mentionnant le sujet Keycloak afin de ne pas être filtré par l'anti-spam ;)

Annexes

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...

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.

LDAP Group whitelist regex

En adaptant les exemples de l'interface user_oidc (cf: Group whitelist regex) et avec l'option "Restrict login", nous avons obtenu des résultats incohérent.

This will create and update the users groups depending on the groups claim in the ID token. The Format of the groups claim value should be [{gid: "1", displayName: "group1"}, …], ["group1", "group2", …] or "group1,group2"

En effet, un utilisateur a été autorisé à ouvrir nextcloud alors qu'il ne fait pas partie des groupes "Nextcloud" et "mediawiki" mais d'un autre qui correspond à l'ancien cloud de l'entreprise et dont son nom diffère légèrement, ici "cloud".

On comprend mieux pourquoi, car la méthode php (getSyncGroupsOfToken) qui gère la comparaison utilise "preg_match" (PCRE) et, dans l'exemple, l'ancien groupe "cloud" est trouvé dans la chaine :

"Group whitelist regex": ["Nextcloud","mediawiki"]

Aussi pour éviter ce désagrément nous utilisons la forme de regex qu'emploie PCRE et c'est pourquoi il était pertinent d'en informer le lecteur.

FAQ

Q

Après une réinstallation du serveur keycloak et une deuxième tentative d'accès à la console, le navigateur tourne en boucle et le serveur affiche :

keycloak3  | 2025-09-24 13:37:17,883 WARN  [org.keycloak.events] (executor-thread-13) type="REFRESH_TOKEN_ERROR", realmId="******", realmName="master", clientId="security-admin-console", userId="null", ipAddress="*****", error="invalid_token", reason="Invalid refresh token", grant_type="refresh_token", client_auth_method="client-secret"

A

Stopper le navigateur et supprimer tous les cookies qui concernent Keycloak. Ce genre de message d'erreur survient quand on tente de se connecter à deux sessions différentes (ex: gyptis-admin et guser), les cookies portent le même nom et le navigateur ne les isole pas...

Q1

Mot de passe perdu

Q2

Impossible de se connecter dans le realm 'master', le compte (super-admin) Kadmin n'est pas accepté.

A

Solution avec un accès à la base SQL ou en utilisant kc.sh comme détaillé ci-dessous :

Si vous n'avez aucun autre moyen de vous connecter en admin, il est impossible de changer le mot de passe de l'admin, car Keycloak doit valider une identification pour toutes modifications administratives, que ce soit avec CLI (kc.sh) ou la console web.
Il faut donc le faire par SQL : stopper le serveur, modifier la base SQL et le relancer Keycloak.

Solution 1: Sans aucun accès administrateur Solution 2: Avec accès admin

Télécharger le code python keyc-tool.zip dans le dossier où se trouve docker-compose.yml, lequel contient les identifiants pour la base de données.
- en le lançant la première fois il vous indiquera s'il faut installer des modules avec pip.

AVANT TOUT, il est impératif de stopper le serveur avant de modifier le mot de passe par la méthode SQL.

# l'outil 'keyc-tools.py' récupère les identifiants SQL depuis le docker-compose.yml :
python3 keyc-tools.py realm=master user=kadmin password

sans docker-compose.yml, syntaxe complète :

# <!> Si le compte est désactivée, ajouter l'option "activate"

python3 keyc-tools.py dbuser=Nom_UserDB dbname=NameDB dbpassword=XxXxXxXxX dbhost=localhost dbport=3306 dbtype=mariadb realm=master user=kadmin password

Relancer le serveur docker compose up ou docker start ID...

Depuis le docker avec

docker exec -it ID bash

alias kcadm=/opt/keycloak/bin/kcadm.sh

# S'identifier avant toute chose.
kcadm config credentials --server https://domain.tld/auth/ --realm master --user admin

# Récupérer l'ID de l'utilisateur
kcadm get users -r master --offset 0 --limit 100 --fields 'id,username'

# Changer le mot de passe
# <!> Remplacer ID_RECOVERED par celui de l'utilisateur...
kcadm update users/ID_RECOVERED/reset-password -r master -s  type=password -s value="New pass word" -s temporary=true -n

Solution 3: avec hc.sh (.bat)

Personnellement je ne suis pas fan de la méthode décrite dans le manuel officiel. Surtout avec la méthode de configuration par variables KC_*. La moindre erreur de manipulation peut entraîner un blocage du conteneur. C'est pourquoi je vous recommande la solution N°1 qui ne prend que 2 min de temps pour changer le mot de passe !

Si vous insistez, alors tentez avec le : tutoriel officiel.

Q

Comment s'identifier dans le conteneur, avec le CLI kc.sh, une fois dans le docker ( exec -it ID bash ) ?

A

Identification depuis le shell commande (CLI kc.[sh|bat] :

docker exec -it ID bash

/opt/keycloak/bin/kcadm.sh config credentials --server https://domain.tld/auth/ --realm master --user kadmin

Q

error="cookie_not_found"

A

Trois solutions

Problème de porté dans config "httpd" (lors de l'identification dans keycloak)
- Ajouter une Location dans Apache (idem pour Nginx) comme décrit Apache Proxy
En cas d'accès "kadmin" et "kuser" dans le même navigateur
- Fermer les autres fenêtres/onglets dont l'UI est actif. Si vous avez un https://.../auth/admin/realm/master d'ouvert et https://.../auth/realms/Gyptis, fermez celle qui ne sont pas utiles, car cela pose problème avec les cookies.
Si aucune des deux premières solution ne fonctionnent
- Supprimer tous les cookies KEYCLOAK avec F12 de chrome ou Inspecter de Edge, et aller dans l'onglet Application du débuggeur, +Cookies...

Terminologies

Always display in UI : On
- Par défaut, les clients autorisés à être utilisés sont affichés que s'ils ont été utilisés récement. En activant l'option, ils sont tout le temps visibles dans le menu "Applications" de l'utilisateur.
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.
  - L'erreur suivante sera donc affichée : Invalid parameter: redirect_uri
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. Elle apparait quand Standard flow est sélectioné.
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/Nextcloud/index.php/apps/user_oidc/backchannel-logout/Keycloak
- Pour mediawiki : https://domain.tld/rest.php/pluggableauth/v1/logout
- Backchannel logout session required
  - Force à 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.

web-origins
- indique l'url où renvoyer l'utilisateur après une déconnexion.

LDAP

RDN LDAP
- Relative Distinguished Name, souvent uid. Un identifiant unique mais le plus raccourci...

Anonyme

Rechercher

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 :

Premier lancement

Accès à la console

Avant tout

Sécurité

Désactivation compte par défaut 'admin'

Création

Realm / Royaume / Ferme / Organisation

Groupes

Compte utilisateur

Accès admin pour Gyptis

Accès utilisateur

Accès direct

Compte client

Création de compte client

Paramétrage des comptes clients

Nextcloud

Mediawiki

Autorisation applicative

Partie 'clients'

Partie 'groups'

Pour un utilisateur existant

Connecter les services à Keycloak

Récupérer client_secret

Configuration coté client

Mediawiki

Méthode depuis un shell

Nextcloud

Méthode depuis un shell

Méthode depuis console WEB

Configuration

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

groupOfNames et entryUUID

Coté 'provider / User federation'

Coté Groups

Coté Client scopes

Coté nextcloud

Modification de champs par l'utilisateur

Congrulation !

Annexes

Journal des connexions

Liste des commandes

Concordances