Résumé

  • Kenneth J. Klingenstein a aidé l’enseignement supérieur à transformer des accords d’accès bilatéraux en une infrastructure où authentification locale, attributs communs, métadonnées signées et autorisation distante restent séparables.
  • La fédération ne fabrique pas la confiance toute seule : elle répartit des obligations vérifiables entre fournisseur d’identité, fournisseur de service et opérateur de fédération.

Le navigateur masque admirablement les frontières administratives. Il quitte le site d’une bibliothèque numérique, affiche la page de connexion de l’université, puis revient avec l’accès demandé. Pour l’usager, cette parenthèse dure quelques secondes. Pour les institutions, elle engage au moins trois autorités et plusieurs états de configuration.

L’université atteste qu’une authentification a eu lieu. Elle peut joindre des attributs, par exemple une affiliation ou un droit précis. Le service distant vérifie l’assertion, puis applique sa propre règle. Entre les deux, il faut savoir où envoyer les messages, avec quelle clé les contrôler et selon quel vocabulaire interpréter les attributs. Aucune organisation ne décide seule de toute la transaction.

C’est à cette couture que se situe l’apport de Klingenstein. L’Internet Hall of Fame rappelle d’abord son rôle dans le déploiement du réseau dans l’Ouest américain, puis son travail, à partir de 1998, sur les couches d’identité et de confiance. En 1999, alors qu’il était chief technologist à l’université du Colorado à Boulder, il a pris la direction de l’Internet2 Middleware Initiative. Internet2 associe cette période à Shibboleth, InCommon, eduPerson et à d’autres outils communautaires.

L’attribution doit rester collective. Dans son récit des vingt ans d’InCommon, Klingenstein place R. L. « Bob » Morgan à la tête du petit groupe initial. Shibboleth a mobilisé des architectes de campus, des développeurs, des bibliothèques, des organismes de recherche et des spécialistes des standards. Klingenstein a donné une continuité institutionnelle à cette coopération ; il n’a pas inventé seul ses protocoles.

La formule du groupe était d’« authentifier localement et agir globalement ». Elle répondait à une réalité : les universités possédaient déjà leurs annuaires, leurs comptes et leurs pratiques de sécurité. Un répertoire mondial central aurait déplacé la garde des identités et imposé un même modèle à des établissements autonomes. La fédération cherchait au contraire à faire circuler des assertions utilisables tout en laissant l’authentification à l’organisation d’origine.

Issu de l’initiative middleware d’Internet2 en 2000, Shibboleth s’est rapproché la même année du travail d’OASIS sur SAML. La version 1.0 est arrivée en 2003. Un article de 2004 signé par Morgan, Scott Cantor, Steven Carmody, Walter Hoehn et Klingenstein décrit deux composants distincts : l’Identity Provider de l’établissement d’origine et le Service Provider placé devant la ressource.

L’IdP effectue ou constate la connexion familière, puis émet une assertion. Le SP vérifie celle-ci et remet les attributs utiles à l’application. C’est enfin l’application qui autorise ou refuse selon sa règle locale. La réussite cryptographique du message ne prouve donc pas la justesse de l’autorisation. Une assertion authentique peut alimenter une règle trop large, ancienne ou mal interprétée.

Les attributs ont permis d’éviter qu’un identifiant permanent soit la seule monnaie d’échange. Une revue scientifique peut avoir besoin de savoir qu’une personne appartient à un établissement abonné. Une plateforme de calcul peut attendre un entitlement spécifique. Elle n’a pas nécessairement besoin du nom, de l’adresse électronique ou du matricule de campus.

Encore faut-il que les mots aient le même sens. Le schéma eduPerson fournit des noms et des définitions adaptés à l’enseignement supérieur. Sa spécification précise qu’un attribut d’affiliation n’a de valeur pratique entre établissements que si sa définition et son usage font l’objet d’un large accord. Elle distingue notamment portée, persistance, unicité, réattribution et propriétés de confidentialité.

Ce détail est un dispositif de sûreté. Deux universités peuvent écrire « membre » et viser des populations différentes. Un identifiant réattribuable peut rattacher un nouvel usager à l’historique d’un ancien. Une valeur persistante peut faciliter le suivi dont un service a besoin, mais aussi la corrélation que l’usager n’attend pas. Le dictionnaire d’attributs doit donc être versionné et gouverné comme les clés.

Shibboleth prévoyait aussi des politiques de libération d’attributs adaptées au destinataire. Des identifiants opaques ou temporaires permettaient de réduire l’exposition d’un login connu. Il s’agissait de capacités, pas d’une promesse absolue de confidentialité. Les réglages par défaut, les décisions de l’administrateur, le consentement compréhensible et les journaux du service déterminent ce qui reste observable.

La compatibilité SAML ne suffisait pas davantage. Les participants devaient s’accorder sur les mécanismes de sécurité, les définitions d’attributs, la localisation des serveurs, la qualité de gestion des comptes, le traitement des données personnelles et les organisations admissibles. Répéter cet accord pour chaque paire établissement-service aurait produit une toile de conventions fragiles.

InCommon a rendu l’accord commun réutilisable aux États-Unis. Dans son souvenir de 2024, Klingenstein insiste sur le moment où l’équipe comprend qu’un relying party a besoin d’un mécanisme organisationnel pour croire l’information reçue. La réponse combine vérification des organisations et de leurs responsables, traitement des métadonnées, attentes minimales, exploitation de services, résolution des différends et possibilité de mettre fin à une participation.

Les métadonnées rendent une partie de cette institution lisible par les machines. La norme OASIS peut y décrire le rôle d’une entité, ses points d’accès, ses bindings et les clés nécessaires à la vérification ou au chiffrement. La politique d’InCommon prévoit de recueillir les données des participants, d’examiner les modifications, de signer numériquement l’ensemble et de le publier pour récupération par les membres.

Dans ce contexte, même un certificat autosigné peut être utile : sa valeur provient de l’enregistrement contrôlé et de la distribution signée de la métadonnée, non du certificat isolé. Inversement, la présence d’une clé dans l’agrégat ne certifie pas toutes les pratiques de l’établissement. Les Baseline Expectations distinguent précisément ce que doivent l’IdP, le SP et l’opérateur.

Le registre situé entre les domaines n’est donc pas une base centrale de personnes. Il décrit les systèmes et les délégations qui permettent à des décisions locales de se rencontrer. L’IdP reste responsable de l’authentification et de ce qu’il divulgue. Le SP reste responsable de la validation et du droit accordé. L’opérateur reste responsable du tissu commun.

L’intérêt historique de ce montage est d’avoir réduit les intégrations improvisées sans supprimer les différences. Les métadonnées remplacent une partie des échanges manuels de clés et d’adresses. eduPerson réduit les traductions sémantiques. Les règles communes réduisent la renégociation de la confiance. Le logiciel ouvert offre une mise en œuvre inspectable. La confiance demeure un jugement, mais son trajet devient nommable.

« Single sign-on » décrit ainsi l’ergonomie, pas la preuve. Après un accès contesté, il faut retrouver l’IdP, le moment et le contexte d’authentification ; l’émetteur, l’audience et la durée de l’assertion ; les attributs remis et leur définition ; la politique de libération ; la version des métadonnées et de la clé ; enfin la règle locale qui a transformé ces éléments en permission.

Une page ouverte ne conserve pas nécessairement ce reçu. L’héritage le plus exigeant de Klingenstein est d’avoir aidé à transformer des frontières invisibles en interfaces de confiance gouvernables. Deux domaines pouvaient rester souverains, à condition que la décision commune ne perde pas la trace de ses composants.

Sources