Groupes SSO BTB

BTB – Vue d’ensemble du Single Sign-On (SSO) et du Single Logout (SLO)]]

Terminologie :

• BTB : Bundestrustbroker
  
• SSO : Single Sign-On
  
• SLO : Single Logout
  
• QoA : Quality of Authentication (Infolink)

SSO (Single Sign-On)

Caractéristiques des groupes SSO/SLO :

• Une application peut être associée à exactement un seul groupe SSO/SLO ; les groupes sont disjoints.

• Au sein d'un groupe, toutes les applications doivent utiliser le même fournisseur d'identité (IdP) ainsi que le même niveau minimal de Quality of Authentication (QoA).
  
  Des IdP différents ou des niveaux de QoA divergents nécessitent une nouvelle authentification, même si une session SSO via le BTB est déjà active.
  
  
• Lors du passage d'une application à une autre au sein du groupe, les adhésions aux rôles sont relues à partir du mandant cible. Cela garantit que la deuxième application reçoit un jeton correct avec les informations de rôle appropriées.

• Les applications peuvent utiliser différents protocoles de fédération (par exemple, SAML, OIDC).

• Les applications ne doivent pas nécessairement être hébergées dans le même mandant d'accès.

PEP SSO hérité (non basé sur BTB):

Limitation : Un Step-Up* au sein de la session n'est pas possible. Toutes les applications impliquées doivent supposer le même niveau de QoA.

SLO (Single Logout)

Déclencheurs de déconnexion :

• Déconnexion manuelle via un bouton de déconnexion
  
• Fermeture de toutes les fenêtres du navigateur
  
• Expiration de la session :
  • 12 heures pour une session active
    
  • 2 heures d'inactivité

Comportement de déconnexion :

• Lors de la déconnexion, une requête SLO est envoyée à toutes les applications participantes du groupe SSO.
  
• Toutes les applications doivent être capables de traiter cette requête de déconnexion et d'y répondre de manière appropriée (des problèmes techniques ont été rencontrés avec des applications comme Easygov).

Exigences pour les applications

• Prise en charge de la connexion, déconnexion et reconnexion avec les IdP configurés et le niveau minimal de QoA défini
  
• Implémentation d'un bouton de déconnexion fonctionnel avec la logique de déconnexion appropriée
  
• Capacité à recevoir et traiter correctement les requêtes SLO
  
• Assurer que les adhésions aux rôles sont correctement relues lors du passage entre les applications

Processus de commande & gouvernance

1. Commande d'un nouveau groupe SSO/SLO
   
   • Le client/partenaire PL remplit le formulaire officiel (lien dans le dossier eIAM) et le télécharge dans le dossier eIAM correspondant
     
   • L'approbation de tous les ISBO concernés doit être obtenue par le client/partenaire PL
     
   • La composition du groupe (applications participantes) est définie par le client/partenaire PL
     
   • Le responsable de l'application doit assurer et tester le bon fonctionnement (SSO & SLO)
   
   
2. Ajout d'une application à un groupe SSO/SLO existant
   
   • Même procédure que pour une nouvelle création :
     
     • Remplir le formulaire et le télécharger dans le dossier
       
     • Approbation par les ISBO(s) concernés
   • eIAM INT peut aider à identifier les ISBO et membres du groupe pertinents, mais la responsabilité incombe toujours au client/partenaire PL
     
   • Les responsables d'application doivent s'assurer que l'intégration fonctionne sans problème
   
   
3. Suppression d'une application d'un groupe existant
   
   • Aucun nouveau formulaire requis
     
   • Toutes les parties concernées (eIAM INT, ISBOs, responsables d'application) doivent être informées
     
   • L'intégrité technique des membres restants du groupe doit être assurée

Conséquences financières pour les clients

• La mise en œuvre du SSO au sein d'un même nom de domaine entièrement qualifié (FQDN) (par exemple, www.gate.bit.admin.ch) fait partie de l'implémentation standard (Remedy CRQ)
  
• Pour le SSO sur plusieurs FQDN, un consulting payant est requis en fonction de l'effort

Informations d'utilisation pour les utilisateurs finaux (FAQ)