Se connecter avec un fournisseur d'identité externe

Une entreprise partenaire a ses propres comptes et son propre fournisseur d’identité OpenID Connect. Ses employés doivent accéder à vos applications protégées par TOSIAM sans recevoir un mot de passe de plus : ils se connectent chez leur entreprise, et TOSIAM leur ouvre une session. TOSIAM délègue l’authentification au fournisseur du partenaire, vérifie la réponse, puis trouve le compte local de l’employé, ou le crée à sa première connexion.

Le code est dans le dépôt tosiam-samples, dossier tosiam-external-idp. Comme un vrai fournisseur (Microsoft Entra ID, Keycloak, Google Workspace…) ne se démarre pas sur un poste de développement, l’exemple contient un petit fournisseur OpenID Connect de démonstration, « Partenaire », en Node.js sans dépendance. Côté TOSIAM, rien ne dépend de ce fournisseur : la même configuration fonctionne avec n’importe quel fournisseur OpenID Connect.

Étape 1 : ce que le fournisseur doit offrir#

TOSIAM est un client du fournisseur du partenaire. Le partenaire déclare TOSIAM chez lui et vous communique :

L’adresse de retour est fixe : c’est la page oauth2c/OAuthProxy.jsp de TOSIAM, qui ramène le navigateur dans la chaîne en cours. Le fournisseur de l’exemple déclare ses utilisateurs et ce client dans fournisseur/partenaire.json, et sert sa découverte :

curl http://localhost:8088/.well-known/openid-configuration

{
  "issuer": "http://localhost:8088",
  "authorization_endpoint": "http://localhost:8088/authorize",
  "token_endpoint": "http://localhost:8088/token",
  "userinfo_endpoint": "http://localhost:8088/userinfo",
  "jwks_uri": "http://localhost:8088/jwks",
  "response_types_supported": ["code"],
  "code_challenge_methods_supported": ["S256"],
  "id_token_signing_alg_values_supported": ["RS256"],
  "authorization_response_iss_parameter_supported": true
}

(extrait)

Étape 2 : l’instance du module OAuth 2.0 / OpenID Connect#

Dans la console legacy (bouton Console legacy de la console), royaume ref, Authentification, Modules, créez une instance de type OAuth 2.0 / OpenID Connect nommée partenaire. Le haut de sa configuration décrit le client et les adresses du fournisseur :

1 2 3 4 5

• PKCE activé, algorithme S256 : TOSIAM envoie un code_challenge et prouve, au point de jeton, qu’il est bien celui qui a demandé le code.
• Portée(s) : avec openid, le module se comporte en client OpenID Connect : il envoie un nonce aléatoire, exige un id_token et le vérifie (signature, iss, aud = l’identifiant du client, nonce identique à celui envoyé). Il vérifie aussi que la réponse userinfo porte le même sub que l’id_token.
• URL du proxy : l’adresse de retour déclarée chez le partenaire.

Plus bas, la vérification de l’id_token :

1 2 3

• Émetteur du jeton : la valeur exacte attendue dans le iss de l’id_token.
• Type de configuration de validation jwk_url et sa valeur : l’adresse de la JWKS du fournisseur, où TOSIAM prend la clé publique qui vérifie la signature.
• Atténuation des confusions OAuth 2.0 : TOSIAM exige au retour les paramètres iss et client_id, et refuse une réponse qui viendrait d’un autre fournisseur que celui qu’il a appelé.

Enfin, la recherche et la création du compte local :

1 2 3 4

sub est l’identifiant stable de l’employé chez le partenaire : il ne change pas quand son nom ou son e-mail changent. Le préfixe sépare les comptes de plusieurs fournisseurs et évite toute collision avec un compte local existant. Sans sub=uid à la création, le compte reçoit un nom aléatoire (un UUID).

Avec ssoadm, l’exemple applique ces réglages depuis tosiam/partenaire-module.properties :

ssoadm create-auth-instance --realm ref --name partenaire --authtype OAuth
ssoadm update-auth-instance --realm ref --name partenaire --datafile partenaire-module.properties

Étape 3 : la chaîne#

Une chaîne connexion-partenaire (Authentification, Chaînes) qui ne contient que le module, Obligatoire :

1 2

ssoadm create-auth-cfg --realm ref --name connexion-partenaire
ssoadm update-auth-cfg-entr --realm ref --name connexion-partenaire --entries "partenaire|REQUIRED"

On l’ouvre avec le paramètre service de la page de connexion :

http://localhost:8080/tosiam/XUI/?realm=/ref&service=connexion-partenaire#login

Un lien « Se connecter avec le compte Partenaire » sur votre portail pointe vers cette adresse.

Étape 4 : se connecter#

cd tosiam-external-idp
./up.sh

Ouvrez l’adresse de l’étape 3. TOSIAM envoie aussitôt le navigateur chez le partenaire, qui affiche sa propre page de connexion :

1 2 3

Connectez-vous avec lucie.martin / Lucie-Partenaire-2026. Le partenaire renvoie le navigateur vers TOSIAM, qui échange le code, vérifie l’id_token, lit le profil et ouvre une session dans le royaume ref. À la première connexion, le compte partenaire-p-1002 est créé avec le prénom, le nom et l’e-mail de Lucie :

1 2

Aux connexions suivantes, TOSIAM retrouve le même compte par son uid. Dans la console, royaume ref, Identités :

1 2

Ce compte a un mot de passe aléatoire que personne ne connaît : il ne sert qu’à travers le partenaire. Désactiver l’employé chez le partenaire suffit à lui couper l’accès, à la prochaine connexion.

Le journal du fournisseur (.tosiam/fournisseur.log) montre les quatre étapes vues de l’autre côté, sans aucun secret :

2026-10-11T12:37:56.674Z connexion demandée par tosiam-ref
2026-10-11T12:37:56.694Z lucie.martin connecté, retour vers tosiam-ref
2026-10-11T12:37:56.733Z jetons émis à tosiam-ref pour lucie.martin
2026-10-11T12:37:56.736Z profil lu pour lucie.martin

Si l’employé choisit Annuler chez le partenaire, le partenaire renvoie le navigateur vers TOSIAM avec une erreur (error=access_denied) au lieu d’un code. TOSIAM vérifie que la réponse correspond bien à sa demande (state), puis XUI affiche la raison de l’échec ; Return to Login Page relance la connexion chez le partenaire :

1 2

Relier un compte existant par l’e-mail#

Si vos utilisateurs ont déjà un compte TOSIAM et que le partenaire envoie la même adresse e-mail, on peut vouloir les relier. Ajoutez email=mail à la Configuration du mappeur de compte : TOSIAM cherche alors un compte dont l’uid ou l’e-mail correspond (recherche en OU sur tous les attributs mappés).

Sans ce réglage, l’e-mail ne compte pas : dans l’exemple, donald.duck a chez le partenaire la même adresse que dduck (donald_duck@tosiam.io), et sa première connexion crée un compte partenaire-p-1003, distinct de dduck.

Les clés du fournisseur#

TOSIAM garde en cache la JWKS du fournisseur. Quand un id_token arrive avec un kid qu’il ne connaît pas, il relit la JWKS, au plus une fois par minute. Conséquences :

• une rotation de clé sous un nouveau kid fonctionne : au pire, les connexions échouent pendant moins d’une minute ;
• une nouvelle clé sous le même kid n’est jamais relue : toutes les connexions échouent (« Unable to login to TOSIAM ») jusqu’au redémarrage de TOSIAM.

Le fournisseur de l’exemple crée sa clé une fois (.tosiam/fournisseur-cle.pem) et prend pour kid l’empreinte de la clé (RFC 7638) : une nouvelle clé a toujours un nouveau kid. Après ./delete.sh, qui supprime la clé, comptez une minute avant que la connexion refonctionne.

Pourquoi un serveur séparé#

Pour essayer, on peut être tenté de prendre un second royaume du même TOSIAM comme fournisseur. Dans un navigateur, cela ne fonctionne pas : les deux royaumes partagent le même cookie de session et le même nom d’hôte. Au retour du « fournisseur », XUI voit une session d’un autre royaume, propose d’en changer (#confirmLogin), et la chaîne n’aboutit pas. Le fournisseur doit être un autre serveur, avec ses propres cookies : c’est le rôle du petit fournisseur de l’exemple.

En cas de problème#

En production#

• HTTPS partout : la page de connexion de TOSIAM, l’adresse de retour et tous les points d’accès du fournisseur.
• Le secret du client dans la configuration de TOSIAM seulement, jamais dans un dépôt ; ou, si le fournisseur le permet, une authentification par clé.
• Recherche par sub préfixé, pas par l’e-mail (voir plus haut).
• Un fournisseur qui recopie le nonce dans l’id_token, comme l’exige OpenID Connect : sinon, toutes les connexions sont refusées.
• Les journaux : au niveau message, le module n’écrit ni le code, ni le code_verifier, ni les jetons, ni la réponse userinfo, seulement leur présence. La fiche de l’utilisateur (nom, e-mail…), en revanche, y figure encore : n’activez ce niveau que le temps d’un diagnostic, et purgez le journal ensuite.
• Le cycle de vie : un employé qui quitte le partenaire ne peut plus se connecter, mais son compte partenaire-… reste dans TOSIAM ; prévoyez son nettoyage.

Pour aller plus loin#

• Délégation entre API avec le token exchange : une fois connecté, appeler des API au nom de l’utilisateur.
• Créer un module d’authentification : les modules et les chaînes vus de l’intérieur.
• Nœuds : Social Login / OIDC : la même connexion dans un graphe d’authentification, avec la nouvelle interface de connexion.