OIDC
NomaUBL embarque une intégration OIDC prête à l'emploi qui permet aux utilisateurs de s'authentifier contre un fournisseur d'identité externe (Keycloak, Auth0, Azure AD / Microsoft Entra, Okta, Google Workspace…) en remplacement ou en complément du couple identifiant + mot de passe local.
L'intégration utilise le flux standard Authorization Code + PKCE, récupère les métadonnées du fournisseur depuis son /.well-known/openid-configuration, et identifie les utilisateurs NomaUBL par leur claim e-mail.
Le comportement de l'écran de connexion est piloté par le champ Auth Mode du template Global :
| Auth Mode | Écran de connexion |
|---|---|
internal (défaut) | Formulaire local nom d'utilisateur + mot de passe. |
oidc | Bouton de connexion unique (SSO). |
both | Bouton SSO au-dessus du formulaire local — voie de secours pour un accès administrateur quand le fournisseur d'identité est indisponible. |
Un template OIDC par défaut est créé automatiquement sur les nouvelles installations et lors des mises à jour, et peut aussi être créé en un clic depuis le bouton + Add OIDC de l'en-tête du Configuration Manager.
Le SSO est une nouvelle capacité — sur une mise à jour, vérifier la liste Mise en service en bas de cette page avant de faire basculer authMode hors de internal.
Ouvrir l'éditeur
- Menu → Configuration → System → OIDC.
- L'éditeur est découpé en cinq sections — Identity provider, Claim mapping, Domain allow-list, Provisioning et Switching on.
En un coup d'œil
Fournisseur d'identité
| Champ | Description |
|---|---|
| Issuer URL | URL de base du fournisseur OIDC — par exemple https://idp.example.com/realms/myrealm pour un realm Keycloak, l'URL du tenant Auth0 ou l'endpoint Azure AD. NomaUBL récupère les métadonnées via <issuer>/.well-known/openid-configuration : les endpoints individuels (autorisation, token, userinfo, JWKS) n'ont jamais à être saisis manuellement. |
| Client ID | Identifiant du client OIDC déclaré côté IdP pour NomaUBL. |
| Client secret | Optionnel pour les clients publics PKCE (le fournisseur peut être configuré sans). Stocké en Base64 sur disque. |
| Redirect URI | Doit correspondre exactement à l'URI de redirection enregistrée côté IdP. Valeur typique : https://<votre-hôte>/api/auth/oidc/callback. |
| Scopes | Séparés par des espaces. Par défaut openid profile email. Ajouter ici les scopes spécifiques au fournisseur quand des claims supplémentaires sont nécessaires. |
Mapping des claims
NomaUBL identifie les utilisateurs OIDC par leur e-mail — le claim email est comparé à la colonne USEMAIL de F564250. La colonne courte USUSER reste la clé d'audit et de session (convention JDE 10 caractères) ; à l'auto-provisionnement, elle est dérivée de la partie locale de l'e-mail.
| Champ | Description |
|---|---|
| Email claim | Claim de l'ID token qui transporte l'e-mail de l'utilisateur. Défaut email — fonctionne tel quel pour Google, Microsoft, Keycloak et Auth0. |
| Full-name claim | Sert à renseigner USFULLNAME à la première connexion, puis rafraîchi à chaque nouvelle connexion. Défaut name. |
| Username claim (fallback) | Utilisé uniquement quand le claim e-mail est absent du ID token (rare). La plupart des installations laissent ce champ vide. |
Liste blanche de domaines
Restreint qui peut se connecter via SSO à un ensemble de tenants e-mail soigneusement choisi. Utile quand l'IdP émet aussi des tokens pour des comptes grand public (le cas Gmail étant l'exemple type).
| Champ | Description |
|---|---|
| Allowed email domains | Liste séparée par des virgules. Laisser vide pour autoriser n'importe quel e-mail vérifié. Renseigné, seules les adresses dont le domaine figure dans la liste peuvent se connecter — un compte Google personnel ou un tenant différent est refusé au callback. |
Require Google Workspace domain (claim hd) | Spécifique Google. Si renseigné, le ID token doit porter un claim hd égal à cette valeur — refuse un Gmail personnel qui partagerait par hasard une adresse avec un utilisateur Workspace. Laisser vide pour ignorer le contrôle ; le champ n'a pas de sens pour les IdP non-Google. |
Provisionnement
Contrôle ce qui se passe quand un utilisateur inconnu réussit pour la première fois à s'authentifier contre l'IdP.
| Champ | Description |
|---|---|
| Auto-create accounts | Y / N. À Y, la première connexion crée la ligne F564250 avec le rôle par défaut ci-dessous — l'utilisateur arrive directement sur le tableau de bord. À N, les utilisateurs inconnus sont refusés avec un message contacter l'administrateur, même après une authentification réussie. |
| Default role | Rôle attribué aux comptes auto-provisionnés. Alimenté depuis la liste réelle des rôles (pas de défaut codé en dur). Les comptes existants conservent leur rôle actuel et ne sont pas réaffectés aux connexions suivantes. |
L'identifiant auto-provisionné est un handle court à 10 caractères dans le style JDE, dérivé de la partie locale de l'e-mail — par ex. john.doe@example.com → JOHNDOE. En cas de collision, un suffixe numérique est ajouté.
Sessions OIDC dans NomaUBL
Les sessions ouvertes via OIDC se comportent un peu différemment des sessions locales :
- La fenêtre Profil verrouille l'onglet Sécurité — la rotation des mots de passe se fait côté IdP.
- Les champs d'identité (e-mail, nom complet) sont en lecture seule dans la fenêtre Profil — ils sont rafraîchis depuis le ID token à chaque connexion.
- Rôles, droits et filtres de lignes restent gérés dans NomaUBL — l'IdP ne fait que vérifier l'identité. L'utilisateur OIDC hérite du rôle attribué à son compte dans
F564250, exactement comme un utilisateur local. - La déconnexion invalide la session NomaUBL ; elle n'appelle pas par défaut l'
end_session_endpointde l'IdP.
Mise en service
Une fois le template OIDC rempli, le champ Auth Mode du template Global contrôle le comportement de l'écran de connexion :
| Mode | Effet |
|---|---|
internal (défaut) | Formulaire local uniquement. OIDC est configuré mais pas exposé. |
oidc | Bouton SSO uniquement. Formulaire local masqué. |
both | Bouton SSO au-dessus du formulaire local — recommandé pendant le déploiement pour que les comptes admin conservent une voie de secours. |
Un déploiement sans surprise suit en général ces étapes :
- Remplir le template OIDC et enregistrer.
- Mettre Auth Mode à
both. Tester de bout en bout avec un compte SSO. - Vérifier que la ligne
F564250auto-provisionnée a le rôle et leUSEMAILattendus. - Faire basculer Auth Mode à
oidcune fois que chaque compte s'est connecté au moins une fois (ou que chaque compte a reçu manuellement le bon rôle si l'auto-provisionnement est àN).
Quand Auth Mode est à oidc, le formulaire local est masqué — il n'existe plus de voie de secours si l'IdP est injoignable. Conserver au moins un compte admin local dans F564250 et rester sur both si le risque opérationnel d'une panne IdP est inacceptable.
Dépannage
| Symptôme | Cause probable |
|---|---|
| Connexion refusée au callback avec un message sur le domaine. | Le domaine de l'e-mail n'est pas dans Allowed email domains, ou le claim hd Google ne correspond pas à la valeur requise. |
| Connexion refusée avec « utilisateur introuvable ». | Auto-create accounts est à N et l'utilisateur n'a pas de ligne F564250 préexistante — provisionner manuellement l'utilisateur ou activer l'auto-création. |
| La connexion reboucle sur l'écran de l'IdP. | L'URI de redirection dans NomaUBL ne correspond pas exactement à celle déclarée côté IdP (slash final, schéma, nom d'hôte). |
| 401 / erreur de récupération des métadonnées au démarrage. | L'Issuer URL est erronée, inaccessible depuis l'hôte NomaUBL, ou son /.well-known/openid-configuration est protégé par authentification. |
| L'opérateur se connecte mais arrive sur un tableau de bord vide. | Le rôle par défaut attribué au provisionnement n'a aucun droit de page. Affecter le compte à un rôle plus complet dans Configuration → Security → Utilisateurs. |
Conseils et bonnes pratiques
- Utiliser
bothpendant le déploiement. Le formulaire local reste actif comme voie de secours pendant la mise au point du SSO. Basculer versoidcuniquement quand chaque compte est confirmé fonctionnel via l'IdP. - Renseigner Allowed email domains quand l'IdP peut émettre des tokens pour des comptes grand public (Google Workspace, Microsoft Entra avec B2B). C'est peu coûteux et écarte toute une famille d'erreurs.
- L'auto-provisionnement fait gagner du temps à l'administrateur — à condition d'être couplé à un rôle par défaut volontairement peu privilégié. Choisir
viewer(ou un rôle nouveau-venu dédié) pour que les comptes fraîchement créés soient revus avant d'obtenir des permissions plus larges. - Les permissions de l'utilisateur OIDC vivent dans NomaUBL. Même SSO activé, accorder l'accès à une page reste un acte NomaUBL — l'IdP ne fait qu'attester l'identité.