---
# Emission du claim `groups` dans le jeton des CLIENTS — extrait de `groupes-ldap.yml`
# le 2026-08-08, pour la meme raison que `roles-realm.yml` une heure plus tot.
#
# Ce mapper se pose sur des clients OIDC, donc il exige que `clients-oidc.yml` soit
# passe. Il vivait pourtant au milieu de la projection des groupes, execute AVANT.
# Invisible tant que les clients existaient d'un passage precedent ; sur un realm neuf,
# la tache cherche des clients qui n'ont pas encore ete crees.
#
# Trouve par la reconstruction from-zero, une etape apres le defaut des roles de realm.
# La lecon est la meme et vaut d'etre retenue : un fichier de taches nomme d'apres un
# SUJET (« les groupes ») rassemble des etapes aux dependances differentes, et l'ordre
# qui en resulte n'est correct que par accident. Ce qui doit gouverner le decoupage,
# c'est ce dont chaque etape a BESOIN — pas ce dont elle parle.
- name: Émettre le claim de groupes dans le jeton des clients
  ansible.builtin.shell:
    executable: /bin/bash
    cmd: |
      set -euo pipefail
      KC={{ serveur_keycloak_home }}/bin/kcadm.sh
      "$KC" config credentials --server http://localhost:8080 --realm master \
        --user {{ serveur_keycloak_admin_user }} --password "$KC_ADMIN_PW" >/dev/null
      CID=$("$KC" get clients -r {{ serveur_keycloak_realm }} -q clientId={{ item }} 2>/dev/null \
            | grep -oP '"id"\s*:\s*"\K[^"]+' | head -1)
      if [ -z "$CID" ]; then echo "SETOPS_OK client absent"; exit 0; fi
      if "$KC" get clients/$CID/protocol-mappers/models -r {{ serveur_keycloak_realm }} 2>/dev/null \
          | grep -q '"groupes-membres"'; then
        echo SETOPS_OK
      else
        # `full.path=false` : le claim porte `sysadmin`, pas `/sysadmin`. Les
        # services comparent un nom de groupe, pas un chemin.
        "$KC" create clients/$CID/protocol-mappers/models -r {{ serveur_keycloak_realm }} \
          -s name=groupes-membres -s protocol=openid-connect \
          -s protocolMapper=oidc-group-membership-mapper \
          -s 'config."claim.name"={{ serveur_keycloak_groupes_claim }}' \
          -s 'config."full.path"=false' \
          -s 'config."id.token.claim"=true' \
          -s 'config."access.token.claim"=true' \
          -s 'config."userinfo.token.claim"=true' >/dev/null
        echo SETOPS_CHANGED
      fi
  environment:
    KC_ADMIN_PW: "{{ serveur_keycloak_admin_password }}"
  loop: "{{ serveur_keycloak_groupes_mapper_clients }}"
  register: serveur_keycloak_grp_mapper
  changed_when: "'SETOPS_CHANGED' in serveur_keycloak_grp_mapper.stdout"
  no_log: true
  when:
    - serveur_keycloak_groupes_mapper_clients | length > 0
    - not ansible_check_mode

# --- Rendre le changement de mot de passe EXPLICITE ---------------------------
# OpenLDAP marque `pwdReset` et refuse les operations au niveau du PROTOCOLE ;
# Keycloak a son propre systeme d'actions requises et NE LIT PAS `pwdReset`. Les
# deux mecanismes ne se parlent pas : l'utilisateur entre avec son jeton, atterrit
# dans la console de compte, et rien ne lui dit pourquoi ni quoi faire. Constate le
# 2026-08-07 par l'operateur : « ce n'est pas du tout explicite ».
#
# On aligne donc Keycloak sur l'annuaire : tant que `pwdReset` est vrai, l'action
# `UPDATE_PASSWORD` est posee et Keycloak affiche un ecran qui l'explique. Elle
# disparait d'elle-meme quand le mot de passe change — l'annuaire retire `pwdReset`,
# et la condition cesse d'etre vraie.