WebSSO de la plateforme : Keycloak ou LemonLDAP::NG

Navin Enterprise (portail, Control Plane, agents sectoriels) authentifie ses utilisateurs par OpenID Connect. Le Manager installe le fournisseur choisi par la banque, ou se branche sur celui qu'elle exploite déjà. Contrat des liaisons : navin-manager/CONTRACT.md (section 10, paramètres générés et liaisons OpenID Connect).

Choisir le fournisseur

Choix	Quand le prendre	Ce que le Manager fait
Keycloak (par défaut)	Aucune préférence de la banque. Licence Apache-2.0.	Installe le service keycloak, importe le royaume enterprise-ai (clients portal, control-plane, cli, rôles, TOTP), fédère l'annuaire LDAP ou Entra ID.
LemonLDAP::NG	La banque exploite déjà LemonLDAP::NG ou exige un WebSSO de l'OW2. Licence GPL-2.0-or-later : exception LEX-034, en attente de la décision du client.	Installe le service lemonldap-ng : portail OpenID Connect sur l'annuaire LDAP ou Active Directory de la banque, rôles calculés depuis les groupes, TOTP, sessions dans PostgreSQL.
LemonLDAP::NG déjà installé	La banque exploite déjà son LemonLDAP::NG.	Rien à installer : ajouter le service existant lemonldap-ng (Ajouter un service, service existant) avec un client confidentiel du portail ; le Manager vérifie ce client et donne à Navin Enterprise l'émetteur et le JWKS que le portail publie.
Autre fournisseur existant	Un autre WebSSO OpenID Connect déjà en place.	Rien à installer : déclarer une connexion de type oidc (émetteur en https) et la choisir pour la liaison oidc de Navin Enterprise.

Quand Keycloak et LemonLDAP::NG sont tous deux installés sur le cluster, le Manager garde Keycloak ; le choix explicite de l'assistant d'installation (liaison oidc, service géré lemonldap-ng) l'emporte toujours.

Installer LemonLDAP::NG

1. Déclarer l'annuaire comme connexion ldap (Administration, Connexions) : URL ldaps://annuaire:636, ou ldap://annuaire:389 avec StartTLS, DN du compte de service, son mot de passe, et le certificat de l'autorité de l'annuaire. Le portail ne parle jamais LDAP sans TLS et vérifie toujours le certificat.
2. Dans l'assistant d'installation, ajouter lemonldap-ng : liaison database vers PostgreSQL (installé ou connexion), liaison directory vers la connexion de l'étape 1.
3. Renseigner au minimum le DN de base des utilisateurs (users_base), le type d'annuaire (openldap ou active_directory), l'URL du portail Navin Enterprise (portal_url) et l'URL publique du WebSSO (public_url).
4. Mode cluster : au moins deux nœuds de portail derrière un répartiteur ; public_url est alors l'adresse du répartiteur. Les nœuds partagent les sessions dans PostgreSQL et reçoivent la même configuration.

Le Manager rend toute la configuration du portail (lmConf-1.json) : l'interface de gestion de LemonLDAP::NG n'est pas installée et la configuration ne se modifie que par les paramètres du service. Une tâche ponctuelle crée les tables des sessions (sessions, psessions, oidcsessions) si elles n'existent pas.

Connecter un LemonLDAP::NG déjà installé

1. Dans le LemonLDAP::NG de la banque, déclarer un client OpenID Connect confidentiel pour le Manager (identifiant, secret, authentification client_secret_basic). Il n'a besoin d'aucun grant : le Manager vérifie seulement que le point token du portail accepte ce secret.
2. Dans le Manager, Ajouter un service, service existant, LemonLDAP::NG : URL du portail (par exemple https://auth.banque.example), identifiant et secret de ce client, et le certificat de l'autorité du portail s'il n'est pas émis par une autorité publique. Le Manager lit le document de découverte (/.well-known/openid-configuration) et vérifie le secret au point token (/oauth2/token) : un mauvais secret est refusé et rien n'est enregistré. Le secret est scellé et n'est jamais réaffiché ; le contrôle se refait chaque minute.
3. Installer navin-enterprise : sa liaison oidc propose le LemonLDAP::NG connecté. Le Control Plane reçoit l'émetteur (issuer) et le JWKS (jwks_uri) exactement tels que le portail les publie, relus à chaque contrôle.
4. Côté LemonLDAP::NG, l'équipe de la banque déclare le client portal de Navin Enterprise : client public, PKCE S256 obligatoire, URI de redirection <portail Navin Enterprise>/auth/callback, audience supplémentaire control-plane dans des jetons d'accès au format JWT, et les réclamations roles (tableau des rôles de la plateforme), groups, tenant et clearance. Le Control Plane lit les rôles dans roles comme dans realm_access.roles.

Brancher Navin Enterprise

Dans l'assistant, la liaison oidc de navin-enterprise propose keycloak, lemonldap-ng ou une connexion oidc. Avec lemonldap-ng, le Manager donne au Control Plane :

Variable	Valeur
EAI_OIDC_ISSUER	public_url du WebSSO
EAI_OIDC_JWKS_URL	public_url suivi de /oauth2/jwks
EAI_OIDC_AUDIENCE	control-plane (paramètre audience du WebSSO, oidc_audience de Navin Enterprise)

Le client portal (identifiant portal_client_id) est public, avec PKCE S256 obligatoire, une seule URI de redirection (portal_url suivi de /auth/callback) et l'audience control-plane ajoutée à ses jetons d'accès. D'autres clients (le BFF d'un agent sectoriel, par exemple) se déclarent dans extra_clients ; un client avec un secret est confidentiel (client_secret_basic).

Rôles, organisation et habilitation

Réclamation	Origine
roles et realm_access.roles	viewer pour tous, plus le rôle de chaque groupe de l'annuaire listé dans role_groups (par défaut navin-platform-admins, navin-tenant-admins, navin-security-officers, navin-finops, navin-developers, navin-auditors)
groups	groupes de l'utilisateur dans l'annuaire (groupes imbriqués avec nested_groups)
tenant	attribut tenant_attribute de l'annuaire, sinon default_tenant
clearance	attribut clearance_attribute de l'annuaire (public, internal, confidential, restricted ou secret)

realm_access.roles est la réclamation du royaume Keycloak de la plateforme : un greffon du catalogue (Navin::LemonLDAP::Claims) la recopie depuis roles, si bien que chaque consommateur lit les mêmes rôles quel que soit le fournisseur. Les réclamations sont données dans les jetons d'accès et d'identité, quelles que soient les portées demandées.

Ce qui a été vérifié

navin-manager/server/tests/test_lemonldap_ng_real.py lance LemonLDAP::NG 2.23.4 (paquets de lemonldap-ng.org) avec la configuration rendue par le catalogue, OpenLDAP avec StartTLS, PostgreSQL et nginx, puis :

• crée les tables des sessions avec la tâche rendue, deux fois de suite ;
• refuse un mauvais mot de passe, puis connecte un utilisateur de l'annuaire par le flux code avec PKCE du client portal, et refuse la réutilisation du code ;
• fait vérifier le jeton d'accès par le code du Control Plane (eai.auth.verify_jwt) : signature RS256 du JWKS publié, émetteur, audience control-plane, rôles viewer et developer issus du groupe navin-developers, realm_access.roles, groupes, organisation et habilitation ;
• constate la session SSO et les sessions OpenID Connect dans PostgreSQL ;
• lance la purge du cache local des sessions que le script de démarrage exécute toutes les heures : les sessions en cours sont gardées ;
• fait valider par nginx la configuration TLS rendue ;
• enregistre ce même portail comme service existant : le client confidentiel est accepté avec le bon secret et refusé avec un mauvais, et l'émetteur et le JWKS publiés par le portail sont ceux que reçoit Navin Enterprise.

Un second essai rend le mode cluster avec deux nœuds de portail derrière un répartiteur sans affinité (chaque requête va au nœud suivant) et le TOTP obligatoire, la valeur par défaut :

• les deux nœuds reçoivent la même configuration, annoncent le même émetteur et publient les mêmes clés ;
• à la première connexion, le portail impose l'enregistrement d'une application TOTP : un mauvais code est refusé, le bon l'enregistre, et la connexion reprend sur l'autre nœud ;
• à la connexion suivante, le code TOTP est demandé : un mauvais code est refusé sans cookie SSO, le bon connecte ;
• un code d'autorisation émis par un nœud est échangé sur l'autre, le cookie SSO ouvre les deux nœuds sans nouveau mot de passe, et le Control Plane accepte les jetons ;
• l'appareil TOTP est dans les sessions persistantes de PostgreSQL ;
• la purge que le script de démarrage lance toutes les heures supprime les sessions expirées et garde les autres.

Ce second essai a trouvé et fait corriger un défaut : le cache local des sessions de chaque nœud servait un jeton d'enregistrement TOTP périmé quand l'autre nœud l'avait mis à jour. En mode cluster, les nœuds lisent désormais chaque session dans PostgreSQL, sans cache local.

test_catalog_lemonldap_ng.py vérifie les rendus (annuaire OpenLDAP et Active Directory, LDAPS et StartTLS, stockage des sessions, clients, secrets absents de la ligne de commande du conteneur) et la liaison de Navin Enterprise.

Limites

• Image officielle docker.io/lemonldapng/lemonldap-ng:2.23.4 pour x86_64 seulement : placer le portail sur des nœuds x86_64.
• Pas de connexion par code d'appareil (RFC 8628) : LemonLDAP::NG 2.23.4 ne la propose pas. La CLI s'authentifie alors par clé d'API ; le client cli du royaume Keycloak n'a pas d'équivalent.
• Les essais réels tournent sans Podman (absent de la machine de développement) : l'image du conteneur n'y est pas lancée, ses fichiers et sa ligne de commande sont vérifiés par les tests de rendu. Le passage du script de démarrage à l'utilisateur www-data pour les purges n'est vérifié que par la syntaxe du script.
• Active Directory n'est vérifié que par les rendus.
• PostgreSQL externe en verify-ca ou verify-full : le portail vérifie le certificat avec les autorités du système de l'image ; une autorité privée de la banque n'y figure pas et la connexion est alors refusée.
• La clé de signature des jetons est générée à l'installation (RSA 3072 bits, scellée). La changer, c'est remplacer le paramètre signing_key puis appliquer avec redémarrage : les jetons en cours deviennent invalides.