Single sign-on (SSO)

Fédération bilatérale d’identités pour une transition transparente entre applications

Une fédération bilatérale d’identités est adaptée lorsqu’il n’est pas nécessaire de mettre en place un domaine SSO complet, mais qu’une transition ciblée et transparente d’une application A déjà authentifiée vers une application B doit être possible.

AGOV n’est ni étendu ni configuré spécialement à cette fin. En particulier, aucun domaine SSO n’est créé dans AGOV et aucune session AGOV n’est relayée entre les applications concernées.

Principe architectural

AGOV authentifie la personne physique auprès de l’application A ou de son IAM. L’authentification déjà effectuée peut ensuite servir de base à l’application A ou à son IAM pour émettre à l’intention de l’application B une nouvelle assertion d’identité spécifiquement destinée à B.

La chaîne de confiance est donc la suivante :

AGOV
  |
  | authentifie la personne physique
  v
IAM / application A
  |
  | émet pour l’application B une assertion
  | d’identité propre et destinée à B
  v
Application B
  |
  | ouvre sa propre session
  v
Application cible

Deux relations de confiance distinctes sont créées :

• AGOV -> application A
• Application A / IAM A -> application B

La seconde relation de confiance est entièrement exploitée en dehors d’AGOV.

Pas de reprise de jetons AGOV

L’application B ne fait pas confiance à un jeton AGOV initialement émis pour l’application A. Un jeton émis pour une relying party donnée n’est pas automatiquement destiné à une autre relying party. En particulier, le contrôle de l’audience ne doit pas être affaibli afin d’accepter malgré tout un tel jeton.
Le schéma suivant n’est donc pas prévu :

AGOV
  |
  | jeton pour l’application A
  v
Application A
  |
  +-> Application B

À la place, A ou son IAM émet une nouvelle assertion spécialement pour B :

AGOV
  |
  v
IAM A
  |
  | nouvelle assertion signée
  | Audience = application B
  v
Application B

L’authentification AGOV initiale ne constitue que la base sur laquelle l’émetteur de l’application A produit sa propre assertion.

Rôles

AGOV
AGOV authentifie la personne physique dans le cadre du processus de connexion existant de l’application A. AGOV n’a pas besoin de savoir que la personne appelle ensuite l’application B, quelles applications sont fédérées entre elles, quelle session est créée auprès de l’application B ou quelle assertion d’identité l’application A transmet ensuite à B.

Émetteur de l’application A
L’émetteur constitue l’ancre de confiance technique et organisationnelle du côté de l’application A. Idéalement, il s’agit d’un IAM ou d’un Security Token Service, et non d’un code applicatif quelconque. Il ne peut émettre des assertions d’identité pour l’application B que sur la base d’une session authentifiée valide.

Application B
L’application B tient une liste des émetteurs explicitement autorisés. Elle vérifie intégralement chaque assertion d’identité reçue et crée ensuite sa propre session applicative. Il n’est pas nécessaire que l’application B connaisse déjà la personne concernée.

Déroulement possible

1. La personne est déjà connectée à l’application A. L’authentification sous-jacente peut, par exemple, avoir été effectuée avec AGOV. Après une authentification réussie, l’IAM A dispose de sa propre session.
2. La personne sélectionne dans l’application A une fonction menant à l’application B. L’application A reconnaît la session existante et demande à son propre émetteur une assertion d’identité spécifiquement destinée à l’application B.
3. L’émetteur crée une assertion signée cryptographiquement. Elle ne contient que les informations convenues nécessaires à B et est explicitement destinée à B. Elle peut, par exemple, contenir l’émetteur, l’audience, le subject, les instants d’émission et d’expiration, un identifiant de transaction unique, l’instant de l’authentification sous-jacente ainsi que les informations d’identité et de qualité convenues.
4. L’assertion d’identité est de préférence transmise côté serveur à l’application B. La connexion peut en outre être protégée au moyen d’une authentification TLS mutuelle (mTLS).

Deux mécanismes de sécurité indépendants peuvent ainsi être combinés :

Niveau transport : La partie appelante est-elle réellement le client technique enregistré ?

et

Niveau message : L’assertion d’identité a-t-elle réellement été signée par l’émetteur enregistré ?

Validation par l’application B

L’application B n’accepte l’assertion d’identité que si tous les contrôles prévus sont réussis. Il convient notamment de vérifier que :

• le client technique est autorisé ;
• l’émetteur est enregistré ;
• la signature est valide ;
• la clé de signature est attribuée à cet émetteur ;
• le type de jeton ou d’assertion est celui attendu ;
• l’audience correspond exactement à l’application B ;
• les instants d’émission et d’expiration sont plausibles ;
• la durée de vie maximale autorisée est respectée ;
• l’identifiant de transaction unique n’a pas déjà été utilisé ;
• l’instant de l’authentification sous-jacente satisfait à la policy ;
• la qualité d’authentification et d’identité déclarée est suffisante pour le cas d’utilisation ;
• le schéma et les informations obligatoires sont valides.

Il ne suffit expressément pas de vérifier qu’une signature est mathématiquement valide. La relation de confiance enregistrée dans son ensemble doit être vérifiée : client technique, émetteur, clé attribuée, type d’assertion correct, audience correcte, signature valide et fenêtre temporelle valide.

Code de handover à usage unique

Après validation, l’application B peut générer un code de handover aléatoire, non devinable et de très courte durée de vie. Ce code ne contient lui-même aucune donnée personnelle et ne peut être utilisé qu’une seule fois.

L’application B associe côté serveur le hash de ce code à l’assertion d’identité déjà validée, à l’émetteur, au subject, aux informations d’authentification, aux instants de création et d’expiration ainsi qu’au statut UNUSED.

Le code doit posséder une forte entropie, n’être valable que très brièvement et ne pouvoir être utilisé qu’une seule fois. Pour une transition immédiate via le navigateur, une durée de validité de quelques secondes à environ une minute au maximum est appropriée.

Transmission via le navigateur

Le navigateur reçoit uniquement ce code à usage unique. La transmission s’effectue de préférence au moyen d’un POST HTTPS vers un point de terminaison prévu à cet effet dans l’application B.

Le navigateur ne transporte notamment pas :

• de jeton AGOV ;
• d’Access Token de l’application A ;
• de cookie de session de l’application A ;
• de cookie de session AGOV ;
• l’assertion d’identité complète ;
• des données personnelles inutiles.

Les informations de confiance et d’identité proprement dites ne sont ainsi pas transportées entre les applications par le navigateur.

Utilisation du code

Lors de la réception du code de handover, l’application B vérifie que le code existe, qu’il est encore valable, qu’il n’a pas déjà été utilisé et qu’il est associé à une transaction validée avec succès. Il est ensuite marqué atomiquement comme USED et une session propre à l’application B est ouverte.

L’utilisation doit être atomique. Même deux requêtes arrivant simultanément ne doivent pas pouvoir utiliser deux fois le même code.

Session propre à l’application B

L’application B ouvre sa propre session. Celle-ci est indépendante de la session AGOV, de la session de l’application A et, le cas échéant, de la session de l’IAM de l’application A.

Il n’en résulte donc pas automatiquement un Single Logout interorganisationnel. Une déconnexion de l’application A ne termine pas nécessairement la session de l’application B, et inversement.

Modèle de confiance

L’application B maintient un enregistrement explicite pour chaque émetteur autorisé. Celui-ci définit au minimum :

• un identifiant d’émetteur unique ;
• l’identité du client technique autorisé, le cas échéant mTLS ;
• les clés publiques de signature autorisées ou une source de clés contrôlée ;
• l’audience attendue ;
• le type d’assertion attendu ;
• les algorithmes cryptographiques autorisés ;
• les claims autorisés et obligatoires ;
• la durée de validité maximale.

Une assertion d’identité provenant d’un émetteur non enregistré est refusée. De même, une signature valide provenant d’un autre émetteur connu ne suffit pas si l’émetteur, la clé, le client technique et l’audience ne correspondent pas à une même relation de confiance enregistrée.

Gestion des clés

Les clés privées de signature restent auprès de l’émetteur concerné. L’application B n’a besoin que des clés publiques pour effectuer la vérification.

Lors d’un changement de clé, une période de chevauchement contrôlée peut être prévue, pendant laquelle l’ancienne et la nouvelle clé publique sont acceptées. L’ancienne clé est ensuite retirée. Un émetteur ou une clé compromis doit pouvoir être bloqué rapidement.

Les modifications concernant les émetteurs, les clés et les clients techniques passent par un processus administratif contrôlé. Une assertion reçue ne doit pas pouvoir déterminer elle-même quelle clé externe arbitraire ou quelle source de clés externe arbitraire doit servir à sa vérification.

Protection contre la réutilisation

L’architecture combine plusieurs couches de protection. L’assertion d’identité est destinée uniquement à l’application B, de courte durée de vie, signée et dotée d’un identifiant de transaction unique. Le code de handover possède une forte entropie, est de courte durée de vie, ne contient aucune donnée personnelle et ne peut être utilisé qu’une seule fois de manière atomique.

L’application B met en œuvre une protection contre la réutilisation des identifiants de transaction déjà utilisés. Un code de handover déjà utilisé est également refusé.

Signification d’une indication telle que auth_source = AGOV

Si l’application B doit savoir que l’authentification initiale a été effectuée par AGOV, le profil de fédération convenu peut prévoir une indication correspondante.
Par exemple :

Issuer = IAM de l’application A
auth_source = AGOV

Cela signifie : l’émetteur de l’application A confirme que la session à la base de cette assertion d’identité a été authentifiée au moyen d’AGOV.

Cela ne signifie pas : cette assertion d’identité a été émise par AGOV.

L’émetteur reste l’IAM de l’application A. Pour cette information, l’application B fait confiance à l’émetteur de l’application A et non directement à AGOV.

Qualité d’authentification et d’identité

L’émetteur ne doit pas déclarer à l’application B une qualité supérieure à celle qui peut être déduite de manière fiable de l’authentification et du contrôle d’identité effectivement réalisés.

La représentation de la qualité d’authentification, de la qualité du contrôle d’identité, de l’instant d’authentification, des moyens d’authentification utilisés et des autres caractéristiques de qualité pertinentes doit donc faire partie du profil de fédération convenu. Les indications de qualité librement interprétables sont à éviter.

Protection des données et minimisation

L’assertion d’identité contient uniquement les informations dont l’application B a besoin pour l’opération concrète. Une fédération bilatérale d’identités n’est pas une interface générale permettant d’échanger toutes les informations disponibles sur une personne.

Il convient de définir sur les plans technique et organisationnel quels attributs peuvent être transmis, à quelle fin ils peuvent être utilisés, combien de temps ils sont nécessaires et quelle entité en assume la responsabilité.

Journalisation

Il convient de ne pas journaliser les assertions d’identité complètes, les codes de handover en clair, les cookies de session, les clés privées ou des données personnelles inutiles.

Pour l’audit de sécurité et la traçabilité, peuvent notamment être consignés l’instant, l’émetteur, un identifiant de transaction pseudonymisé, le résultat de la validation, l’identifiant de clé utilisé, le résultat du handover et la classe d’erreur technique.

Comportement en cas d’erreur

Un handover défaillant ne doit jamais conduire à un affaiblissement des contrôles de sécurité. Un émetteur inconnu, une audience incorrecte, une signature invalide, une assertion expirée, un identifiant de transaction déjà utilisé, un code de handover expiré ou déjà utilisé, une qualité insuffisante ou un client technique non autorisé entraînent un refus.

Après un handover échoué, l’application B peut, le cas échéant, proposer son processus de connexion normal.

Onboarding d’une nouvelle relation de confiance

Avant une mise en production, les parties concernées doivent convenir au minimum de l’émetteur, du client technique, des clés et de leur rotation, de l’audience, du type d’assertion, des claims obligatoires et facultatifs, de la qualité d’authentification et d’identité acceptée, de la durée de vie maximale, de la protection contre la réutilisation, des données personnelles autorisées, des contacts d’exploitation, du blocage d’urgence ainsi que des tests de conformité positifs et négatifs.

Tests de sécurité

Avant la mise en service, il convient de tester au minimum les cas négatifs suivants :

• signature falsifiée ;
• algorithme de signature non autorisé ;
• mauvais émetteur ;
• bon émetteur avec mauvaise clé ;
• bonne clé avec mauvaise audience ;
• assertion expirée ;
• assertion avec horodatage non plausible ;
• identifiant de transaction réutilisé ;
• code de handover réutilisé ;
• code de handover expiré ;
• mauvais client technique ;
• assertion provenant d’un autre émetteur ;
• assertion provenant d’un autre service du même émetteur ;
• claims manipulés ;
• clé inconnue ;
• double utilisation simultanée.

Découplage d’AGOV

Une fédération bilatérale d’identités ne crée aucune dépendance d’exécution supplémentaire entre l’application B et AGOV. Lors de la transition proprement dite, les systèmes concernés communiquent directement entre eux :

Application A <-> application B

et non :

Application A <-> AGOV <-> application B

AGOV reste limité à son rôle initial de système d’authentification.

Délimitation par rapport à un domaine SSO

Du point de vue de l’utilisatrice ou de l’utilisateur, le résultat peut ressembler à du SSO : la personne est connectée à l’application A, sélectionne l’application B et accède directement à B sans nouvelle connexion interactive.

Sur le plan architectural, aucun domaine SSO commun n’est toutefois créé dans AGOV. Les responsabilités restent clairement séparées :

• AGOV : authentification de la personne physique.
• Application A / IAM A : session propre et assertion d’identité ciblée.
• Application B : validation, identité propre, session propre et autorisations propres.

Une fédération bilatérale d’identités convient donc particulièrement à des transitions individuelles clairement définies entre applications. Si de nombreuses applications au sein d’une organisation doivent utiliser le SSO entre elles, un IAM intermédiaire ou un véritable domaine SSO organisationnel constitue en règle générale l’architecture la plus appropriée.

Utilisation de standards existants

Si l’IAM de l’application A peut déjà agir comme Identity Provider conforme à un standard vis-à-vis de l’application B, il convient d’utiliser, dans la mesure du possible, un standard établi tel qu’OpenID Connect ou SAML au lieu de définir un mécanisme de transition propre.

Le principe architectural reste identique :

Application B <-> IAM A <-> AGOV

et non :

Application B <-> nouvelle fonction SSO d’AGOV

Le point déterminant n’est pas le protocole concret utilisé, mais la séparation claire des relations de confiance.

Principe architectural final

Une session déjà authentifiée avec AGOV peut être utilisée par un IAM situé en aval comme base d’une fédération bilatérale d’identités vers une autre application.

AGOV n’est pour cela ni étendu ni configuré spécialement. En particulier, aucun domaine SSO n’est créé dans AGOV, aucune session AGOV n’est relayée entre applications, aucun jeton AGOV émis pour une autre relying party n’est transmis et aucune fonction de fédération spécifique à une application n’est ajoutée à AGOV.

Les applications concernées ou leurs systèmes IAM établissent à la place leur propre relation de confiance, explicitement définie et sécurisée. Une transition transparente entre applications individuelles devient ainsi possible sans faire d’AGOV la plate-forme centrale de SSO entre ces applications.