Un responsable achats invite une collègue sur l’extranet d’un fournisseur. Six mois plus tard, il quitte l’entreprise, son adresse est désactivée et personne ne sait qui peut encore administrer les comptes. La collègue conserve l’accès à deux filiales, une ancienne invitation reste réutilisable et le support réattribue le rôle principal après un simple e-mail. Le login fonctionne ; le problème et le risque de fuite restent cachés dans la chaîne de confiance.
L’authentification prouve qu’un utilisateur contrôle un moyen de connexion. Elle ne prouve ni son appartenance actuelle à une organisation, ni son droit à consulter un contrat, ni sa capacité à déléguer. Un SSO peut renforcer la première preuve tout en laissant intactes les erreurs de rattachement et d’habilitation. Une invitation pratique peut au contraire créer un accès durable sans propriétaire.
Le vrai enjeu consiste à rendre chaque accès explicable pendant tout son cycle de vie : qui a invité, pour quelle organisation, avec quel rôle, sur quelle preuve, jusqu’à quand et comment le retirer. Le système doit aussi survivre au départ de l’administrateur, à une fédération indisponible et à une adresse e-mail réattribuée.
Dans une démarche de développement web sur mesure, identité, SSO et invitation forment donc un workflow métier, pas une page de connexion isolée. Ce guide ferme les frontières, les états, les contrôles et le run nécessaires à un extranet B2B réellement opérable.
Séparer identité, compte et habilitation
Nommer quatre objets distincts
L’identité représente la personne ou le sujet reconnu. Le compte porte ses moyens de connexion. Le rattachement relie ce sujet à une organisation dans une période. L’habilitation autorise une action sur un périmètre. Fusionner ces quatre objets dans une ligne user rend la révocation imprécise : désactiver le login supprime parfois trop, changer l’e-mail conserve parfois trop.
Un même utilisateur peut appartenir à plusieurs organisations avec des rôles différents. Une organisation peut utiliser plusieurs fournisseurs d’identité. Un compte local de secours peut coexister avec une fédération, sans devenir une seconde identité. Les identifiants externes sont enregistrés avec leur émetteur ; l’e-mail reste un attribut mutable, jamais une clé de sécurité universelle.
La décision d’accès prend en entrée sujet, organisation active, ressource, action, contexte et version de politique. Elle produit autorisé ou refusé avec un motif stable. L’interface masque les actions inutiles, mais l’API répète le contrôle. Un filtre visuel ne protège ni un export direct, ni une URL conservée, ni un appel automatisé.
Choisir le rôle exact du SSO
OpenID Connect fournit une couche d’identité au-dessus d’OAuth 2.0 ; la spécification OpenID Connect Core décrit notamment l’émetteur, le sujet et la validation des jetons. Le couple iss/sub identifie le sujet dans ce contexte. Utiliser seulement l’e-mail expose aux changements, alias et réattributions.
Le SSO décide que l’identité s’est authentifiée auprès d’un fournisseur accepté. L’extranet conserve la décision d’habilitation : organisation autorisée, rôle, contrat, délégation et statut. Un groupe présent dans le jeton peut alimenter une règle, mais sa sémantique, son périmètre et sa fraîcheur doivent être contractualisés. « Membre du domaine » ne signifie pas « administrateur de tous les contrats ».
La fédération est configurée par organisation : issuer attendu, client, clés, algorithmes, audiences, redirections et politique de secours. La validation refuse un jeton destiné à une autre application ou provenant d’un émetteur homonyme. La rotation des clés est testée. Les secrets ne sont jamais journalisés avec les revendications utiles au diagnostic.
Prévoir l’indisponibilité sans contourner la confiance
Lorsque le fournisseur d’identité ne répond plus, l’extranet ne crée pas automatiquement un mot de passe local pour chaque utilisateur. Il applique une politique décidée : sessions existantes bornées, compte de secours fortement protégé pour quelques rôles, ou fermeture temporaire. Le mode dégradé indique ce qui reste lisible et interdit les opérations sensibles si la preuve devient insuffisante.
Construire une invitation à usage borné
Une invitation n’est pas un compte précréé. Elle représente une intention : une personne autorisée propose d’accorder un rôle sur une organisation. Elle porte l’invitant, le destinataire attendu, le périmètre, le rôle maximal, l’échéance, un statut et un jeton à usage unique. Le jeton stocké côté serveur est haché afin qu’une fuite de base ne suffise pas à accepter l’invitation.
L’URL utilise une entropie suffisante, expire et devient inutilisable après consommation, annulation ou remplacement. Le système ne révèle pas publiquement si l’adresse existe déjà. Après ouverture, l’utilisateur s’authentifie puis confirme le rattachement. Si l’identité connectée ne correspond pas à la politique attendue, le dossier entre en revue au lieu de transférer silencieusement l’invitation.
Le renvoi crée un nouveau secret et invalide l’ancien. La consommation est atomique : deux clics concurrents ne produisent pas deux adhésions. Une clé idempotente permet au client de retrouver le verdict après timeout. Le journal conserve la décision, pas le jeton brut. L’e-mail informe ; il n’est pas la preuve unique d’autorisation.
Contre-intuitivement, raccourcir l’expiration ne suffit pas toujours à réduire le risque. Une invitation de quinze minutes que le support recrée sans contrôle peut être plus faible qu’une invitation de trois jours soumise à validation et révocable. La durée est locale, liée au canal, à la sensibilité du rôle et à la capacité réelle d’assistance.
Prouver le rattachement à l’entreprise
Le domaine e-mail constitue un indice, pas une preuve générale. Une agence, un cabinet comptable ou un prestataire peut légitimement utiliser un autre domaine. Inversement, posséder une adresse du domaine ne donne pas accès à toutes les sociétés d’un groupe. Le rattachement s’appuie sur une invitation autorisée, une assertion fédérée maîtrisée, une validation d’administrateur ou une preuve contractuelle.
Pour l’auto-inscription, le système distingue demande et acceptation. Il collecte l’organisation visée, la justification et les références utiles, puis crée un dossier. Une règle déterministe peut accepter certains cas à faible risque. Les autres rejoignent une file avec différences visibles. Le support ne doit pas décider depuis une capture d’écran isolée.
La fusion d’organisations ou le changement de domaine ne réécrit pas l’historique. Les anciens identifiants restent résolvables, les appartenances sont migrées avec une décision et les droits sont recalculés. Un transfert de contrat peut retirer un périmètre sans détruire l’identité ni les traces de consultation antérieures.
Modéliser rôles, périmètres et délégations
Les rôles décrivent des capacités compréhensibles : consulter les factures, déposer un document, gérer les utilisateurs ou valider une commande. Le périmètre précise organisation, établissement, contrat ou dossier. Un rôle global « admin » accordé par confort transforme chaque évolution en risque. Les permissions sensibles restent séparées de l’administration courante.
Une délégation possède délégant, bénéficiaire, capacités, périmètre, motif, début et fin. Elle ne peut pas dépasser les droits du délégant au moment de l’usage. Lorsque celui-ci perd son rattachement, la politique décide si la délégation tombe immédiatement ou rejoint une revue ; ce choix est écrit avant l’incident.
Le moindre privilège ne signifie pas multiplier des centaines de cases. Le modèle propose quelques rôles possédés et testables, complétés par des restrictions explicites. Les combinaisons rares passent par une délégation bornée plutôt que par un rôle permanent créé pour un seul dossier.
Fermer le cycle de vie des accès
Le provisioning couvre création, modification et désactivation. Lorsque l’entreprise utilise SCIM, le RFC 7644 encadre le protocole de gestion des identités ; il ne remplace pas la décision métier sur les droits de l’extranet. Les attributs synchronisés, leurs propriétaires et leur comportement en cas d’absence restent documentés.
Les événements utiles sont arrivée, changement d’équipe, suspension, départ, fusion et fin de contrat. Chacun produit une transition d’appartenance et une réévaluation des droits. Une désactivation reçue en retard ne doit pas restaurer un état plus ancien. La version et la date effective priment sur l’ordre d’arrivée réseau.
Les comptes dormants et invitations en attente sont revus selon une cadence locale. Le seuil dépend du risque et du volume, pas d’un benchmark universel. Le rapport distingue aucune connexion, aucune activité métier et impossibilité de joindre le propriétaire. L’action peut être rappel, suspension ou retrait avec possibilité de contestation.
Traiter sessions, révocation et récupération
Retirer une habilitation doit affecter les nouvelles décisions sans attendre la fin d’une session trop longue. Selon l’architecture, l’API consulte l’état courant, utilise des jetons courts ou invalide les sessions concernées. Un jeton signé n’implique pas que le droit reste valable jusqu’à son expiration maximale.
La récupération de compte vérifie davantage qu’une boîte e-mail pour les rôles sensibles. Elle peut demander une nouvelle authentification fédérée, l’intervention de deux administrateurs ou une vérification contractuelle. Les facteurs sont renouvelés sans exposer les anciens secrets. Chaque récupération déclenche une notification indépendante et une trace consultable.
Le changement d’adresse ne fusionne jamais deux identités par simple égalité de chaîne. Le système vérifie le sujet, les comptes existants et les appartenances. En cas de doute, il suspend l’association. Une réponse générique protège contre l’énumération tout en donnant au demandeur un canal de résolution.
Cas concret : départ d’un administrateur client
Cas hypothétique : un extranet dessert cent vingt sociétés clientes. Chaque société possède un ou deux administrateurs capables d’inviter des collègues. Un administrateur quitte une entreprise vendredi ; le fournisseur d’identité suspend son compte lundi. Entre-temps, une invitation envoyée avant son départ est acceptée pour un rôle donnant accès aux factures de trois établissements.
La cible sépare l’invitation de l’appartenance. Le départ suspend le rattachement de l’administrateur et marque ses invitations non consommées comme à revoir. L’invitation acceptée n’est pas annulée aveuglément : le système vérifie sa date, son périmètre et la politique en vigueur, puis demande à un second administrateur ou au propriétaire contractuel de confirmer.
Le pilote couvre dix entreprises, deux fournisseurs d’identité et les rôles facture, document et administration. Les seuils sont locaux : aucune lecture inter-organisation tolérée, toute révocation sensible visible dans le délai convenu avec la sécurité, aucune invitation consommable deux fois et un diagnostic réalisable sans accès direct à la base.
Par exemple, si une session conserve un droit révoqué au-delà du budget testé, alors le go est suspendu. Le même repli s’applique si le support doit modifier une table ou si plus d’un dossier reste sans propriétaire après la période convenue. Ces seuils commandent une action précise ; ils ne promettent pas une sécurité absolue ni un délai valable pour tout extranet.
Implémenter contrats et journalisation
L’API expose des cas d’usage : inviter, accepter, annuler, déléguer, suspendre et transférer l’administration. Ses entrées, sorties et responsabilités sont contractualisées ; chaque commande porte acteur, organisation active, version et clé d’idempotence. Une contrainte protège l’usage unique du jeton. Les transitions impossibles retournent un motif stable sans divulguer d’information à un acteur non autorisé.
La base relie identité, compte externe, organisation, appartenance, rôle et délégation. Les contraintes ferment unicité et périodes incompatibles lorsque possible. Une boîte d’envoi transactionnelle publie les changements d’accès après la décision locale. Les dépendances, le retry et le seuil de file alimentent le monitoring ; les consommateurs reconstruisent leurs projections et tolèrent les répétitions.
Le journal d’audit conserve sujet, acteur, action, ressource, organisation, décision, motif, version de politique, corrélation et instant. Il évite le jeton d’invitation, les secrets et les attributs inutiles. La consultation du journal suit elle-même des droits et une durée de conservation validée.
Rendre le run exploitable
Le tableau opérationnel montre invitations expirées, comptes sans administrateur, révocations en attente, échecs SSO par organisation et délégations proches de leur fin. Chaque alerte possède une action. Le runbook indique comment distinguer défaut d’identité, de rattachement, de droit ou de session avant toute relance.
Le rollback ferme une nouvelle voie d’invitation ou une règle de mapping sans restaurer les accès déjà retirés. Les décisions prises pendant le pilote restent traçables. Une reprise rapproche le système d’identité, les appartenances et les sessions ; elle ne réactive pas tous les comptes depuis un export ancien.
Tester les scénarios hostiles
La recette rejoue jeton expiré, double clic, redirection manipulée, invitation transférée, utilisateur déjà rattaché, fusion d’organisation, départ de l’invitant, clé SSO tournée et événement SCIM hors ordre. Elle vérifie état final, nombre d’effets, message visible, audit et action du support.
Les tests d’autorisation portent sur chaque API, export et cache. Ils utilisent deux organisations aux identifiants proches afin de détecter les fuites de périmètre. Un administrateur local tente explicitement d’accéder à une URL d’une autre filiale. Le refus est prouvé côté serveur, pas uniquement par l’absence du bouton.
Le support exécute une récupération, un transfert d’administration et une révocation avec ses droits réels. La recette se termine lorsque les sessions, projections et journaux concordent. Un écran correct accompagné d’un ancien jeton encore accepté ne constitue pas un succès.
Pour qui cette architecture devient nécessaire
Le sujet concerne extranets clients, fournisseurs, franchisés ou partenaires où plusieurs organisations administrent leurs propres utilisateurs. Produit, sécurité, juridique, support et propriétaires contractuels doivent participer. Le produit porte la promesse ; la sécurité ferme les preuves ; le métier attribue les responsabilités ; le support valide la reprise.
Un espace limité à quelques comptes nominatifs gérés par une équipe interne peut rester simple. Le SSO et SCIM seraient disproportionnés. Dès que les clients délèguent, que plusieurs filiales coexistent ou que des documents sensibles sont exposés, identité et habilitation doivent avoir des cycles de vie explicites.
Le volume n’est pas le seul déclencheur. Dix partenaires ayant accès à des données financières peuvent exiger davantage de contrôle que dix mille lecteurs d’un contenu public. Le niveau de preuve suit les conséquences d’une erreur, la réversibilité et la capacité d’intervention.
Éviter les erreurs fréquentes
Prendre l’e-mail pour l’identité
Une adresse change et peut être réattribuée. Utilisez un identifiant stable par émetteur, puis traitez l’e-mail comme moyen de contact vérifié. Une égalité d’adresse ne justifie ni fusion de comptes ni récupération de droits.
Confier les droits au seul fournisseur SSO
Les groupes externes n’expriment pas toujours contrats, établissements et délégations. Le SSO authentifie ; l’extranet autorise avec son contexte. Tout mapping possède version, propriétaire, tests et comportement lors d’une valeur inconnue.
Révoquer seulement le mot de passe
Les sessions, jetons, clés d’API et délégations peuvent survivre. La révocation cible les moyens et appartenances concernés, propage le verdict et vérifie les copies. Elle ne détruit pas l’historique nécessaire à l’audit.
Décider SSO, invitation ou vérification
Bloc de décision. Utilisez le SSO lorsque l’organisation possède une identité fédérée fiable et peut gérer son cycle de vie. Utilisez l’invitation pour une délégation explicite et bornée. Ajoutez une vérification métier lorsque l’appartenance ne se déduit ni du fournisseur d’identité ni d’un administrateur déjà autorisé.
Priorisez d’abord l’isolation entre organisations, la révocation et la récupération ; ensuite l’automatisation du provisioning ; enfin le confort de connexion. Différez le SSO si l’émetteur, les sujets ou les groupes ne sont pas maîtrisés. Refusez l’auto-inscription automatique pour un rôle sensible sans preuve de rattachement.
- Fédérer l’authentification, sans externaliser aveuglément l’autorisation.
- Borner toute invitation par rôle, périmètre, usage et échéance.
- Conserver un propriétaire pour les comptes et délégations.
- Tester révocation et récupération avant d’ouvrir à de nouvelles organisations.
Plan d’action sur six semaines
Semaines 1 et 2 : cartographier et fermer les décisions
Choisissez vingt dossiers : arrivée, invitation, changement de rôle, départ, récupération et fusion. Reconstituez identité, compte, appartenance et droits. Nommez les propriétaires et les preuves. Écrivez les politiques d’expiration, de délégation, de session et de transfert d’administration avec leurs exceptions.
Inventoriez fournisseurs SSO, groupes, domaines, comptes locaux et scripts. Mesurez comptes sans propriétaire, invitations actives, sessions longues et corrections support. Définissez les seuils locaux et leurs actions. Le premier livrable est un contrat d’accès, pas un écran de connexion.
Semaines 3 et 4 : implémenter et provoquer
Séparez les objets, ajoutez versions, contraintes, journal et événements. Branchez un fournisseur d’identité et une organisation pilote. Provoquez double consommation, départ de l’invitant, événement hors ordre, session révoquée et panne de fédération. Le support exécute récupération et transfert.
La recette contrôle toutes les routes et tous les exports. Une balance compare fournisseurs d’identité, appartenances et sessions. Les défauts sont classés par identité, rattachement, autorisation ou propagation. Le rollback ferme la nouvelle voie sans réactiver les anciens accès.
Semaines 5 et 6 : ouvrir et gouverner
Ouvrez dix organisations avec des rôles limités. Surveillez invitations, révocations, fuites de périmètre, récupérations et délai de diagnostic. Exécutez une rotation de clés et un départ réel contrôlé. Étendez uniquement lorsque chaque anomalie possède un verdict et un owner.
Le bilan distingue sécurité, adoption et charge support. D’abord, il ferme toute lecture inter-organisation ; ensuite, il réduit les comptes sans propriétaire ; puis il automatise les cas déterministes. Les délégations rares restent assistées si ce canal est financé et respecte le délai annoncé.
- Distinguer identité, compte, appartenance et habilitation.
- Contractualiser SSO, invitation, révocation et récupération.
- Tester les scénarios hostiles avec les droits du support.
- Étendre organisation par organisation depuis des preuves de run.
Approfondir sécurité et exploitation
Le guide de test des workflows à exceptions aide à construire les scénarios de concurrence, de retard et de reprise. L’observabilité métier relie ensuite une décision d’accès au dossier que le support connaît.
Pour les opérations sensibles, le guide performance, monitoring et observabilité complète les métriques de sécurité par des seuils actionnables. Ces lectures doivent être appliquées aux politiques réelles de l’extranet, pas recopiées comme une checklist générique.
- Relier chaque identité à son émetteur et chaque droit à son organisation.
- Vérifier les sessions après une révocation, pas seulement le compte.
- Faire exécuter récupération et transfert par le support avant l’ouverture.
Conclusion : rendre chaque accès explicable
Un SSO réussi ne garantit pas un extranet sûr. La fiabilité vient de la séparation entre identité, compte, appartenance et habilitation, puis d’un cycle de vie qui sait inviter, modifier, révoquer et récupérer sans reconstruire le dossier à la main.
L’invitation doit rester une intention bornée. Le rattachement demande une preuve adaptée au risque. Les rôles et délégations portent un périmètre. La session ne doit pas survivre silencieusement à la décision qui l’autorisait.
Le meilleur test se joue lors d’un départ : l’équipe sait qui conserve quoi, les invitations en attente sont qualifiées, les sessions suivent la révocation et le support retrouve le motif depuis l’identifiant client. Cette capacité vaut davantage qu’un écran de connexion parfaitement fluide.
Dawap peut accompagner la conception et l’épreuve de ces parcours dans une démarche de développement web sur mesure : modèle d’identité, fédération, invitations, droits, journalisation, tests hostiles et préparation du run.
