BTB SSO Gruppen

BTB – Übersicht zu Single Sign-On (SSO) und Single Logout (SLO)

Begrifflichkeiten:

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

SSO (Single Sign-On)

Eigenschaften von SSO/SLO-Gruppen:

• Eine Anwendung kann jeweils nur genau einer SSO/SLO-Gruppe zugeordnet werden; die Gruppen sind dabei disjunkt.

• Innerhalb einer Gruppe müssen alle Anwendungen denselben Identity Provider (IdP) sowie denselben minimalen Quality-of-Authentication-Level (QoA) verwenden.
  
  Unterschiedliche IdPs oder abweichende QoA-Level führen dazu, dass eine erneute Authentifizierung erforderlich ist – auch wenn bereits eine SSO-Sitzung über den BTB besteht.
  
  
• Beim Wechsel von einer Anwendung zur anderen innerhalb der Gruppe werden die Rollenmitgliedschaften erneut aus dem Ziel-Mandanten ausgelesen. So wird sichergestellt, dass die zweite Applikation ein korrektes Token mit den passenden Rolleninformationen erhält.

• Anwendungen dürfen unterschiedliche Föderationsprotokolle (z. B. SAML, OIDC) verwenden.

• Anwendungen müssen nicht im gleichen Access-Mandanten geführt werden.
  

Legacy PEP SSO (nicht BTB-basiert):

Einschränkung: Ein Step-Up* innerhalb der Session ist nicht möglich. Alle beteiligten Anwendungen müssen denselben (einheitlichen) QoA-Level voraussetzen.

SLO (Single Logout)

Auslöser für einen Logout:

• Aktives Abmelden über einen Logout-Button
  
• Schließen aller Browserfenster
  
• Erreichen der Session-Laufzeit:
  • 12 Stunden bei aktiver Sitzung
    
  • 2 Stunden bei Inaktivität

Logout-Verhalten:

• Beim Logout wird ein SLO-Request an alle beteiligten Anwendungen der SSO-Gruppe geschickt.
  
• Alle Anwendungen müssen in der Lage sein, diesen Logout-Request zu verarbeiten und entsprechend zu reagieren (bei Anwendungen wie Easygov gab es diesbezüglich technische Probleme).

Anforderungen an Anwendungen

• Unterstützung von Login, Logout und Re-Login mit den konfigurierten IdPs und dem festgelegten minimalen QoA-Level.
  
• Implementierung eines funktionalen Logout-Buttons mit entsprechender Logout-Logik.
  
• Fähigkeit, SLO-Requests korrekt zu empfangen und zu verarbeiten.
  
• Gewährleistung, dass beim Sprung zwischen Applikationen die Rollenmitgliedschaften korrekt neu ausgelesen werden.

Bestellprozess & Governance

1. Bestellung einer neuen SSO/SLO-Gruppe
   
   • Der PL-Kunden/Partner füllt das offizielle Formular (Link im eIAM-Dossier) aus und lädt es im entsprechenden eIAM-Dossier hoch.
     
   • Die Genehmigung durch alle betroffenen ISBOs ist durch den PL-Kunden/Partner einzuholen.
     
   • Die Zusammensetzung der Gruppe (Teilnehmende Applikationen) wird durch den PL-Kunden/Partner definiert.
     
   • Der Applikationsverantwortliche muss die korrekte Funktionalität (SSO & SLO) sicherstellen und testen.
   
   
2. Aufnahme einer Applikation in eine bestehende SSO/SLO-Gruppe
   
   • Gleiches Verfahren wie bei der Neuanlage:
     • Formular ausfüllen und im Dossier ablegen
       
     • Genehmigung durch relevante ISBO(s)
   • eIAM INT kann unterstützend bei der Identifikation relevanter ISBOs und Gruppenmitglieder helfen, jedoch liegt die Verantwortung weiterhin beim PL-Kunden/Partner.
     
   • Applikationsverantwortliche müssen sicherstellen, dass die Integration reibungslos funktioniert.
   
   
3. Entfernung einer Applikation aus einer bestehenden Gruppe
   
   • Kein neues Formular erforderlich.
     
   • Die betroffenen Stellen (eIAM INT, ISBOs, Applikationsverantwortliche) müssen informiert werden.
     
   • Technische Korrektheit der verbleibenden Gruppenmitglieder muss sichergestellt bleiben.

Kostenfolgen für Kunden

• Die Realisierung von SSO innerhalb eines gemeinsamen Fully Qualified Domain Names (FQDN) (z. B. www.gate.bit.admin.ch) ist Teil der Standardimplementierung (Remedy CRQ).
  
• Für SSO über mehrere FQDNs hinweg ist ein kostenpflichtiges Consulting nach Aufwand erforderlich.

Nutzungsinformationen für Endanwender (FAQ)