BTB SSO Groups

BTB – Overview of Single Sign-On (SSO) and Single Logout (SLO)]]

Terminology:

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

SSO (Single Sign-On)

Characteristics of SSO/SLO groups:

• An application can be assigned to exactly one SSO/SLO group; groups are disjoint.

• Within a group, all applications must use the same Identity Provider (IdP) and the same minimum Quality-of-Authentication level (QoA).
  
  Different IdPs or differing QoA levels will require a reauthentication – even if a BTB SSO session already exists.
  
  
• When switching from one application to another within the group, role memberships are re-read from the target tenant. This ensures that the second application receives a correct token with the appropriate role information.

• Applications may use different federation protocols (e.g., SAML, OIDC).

• Applications do not need to reside in the same access tenant.

Legacy PEP SSO (not BTB-based):

Limitation: A Step-Up* within the session is not possible. All participating applications must assume the same (uniform) QoA level.

SLO (Single Logout)

Triggers for logout:

• Manually logging out via a logout button
  
• Closing all browser windows
  
• Session timeout:
  • 12 hours for active sessions
    
  • 2 hours of inactivity

Logout behavior:

• Upon logout, an SLO request is sent to all participating applications in the SSO group.
  
• All applications must be capable of handling this logout request and responding appropriately (applications such as Easygov encountered technical issues here).

Application requirements

• Support for login, logout, and re-login with the configured IdPs and the defined minimum QoA level
  
• Implementation of a functional logout button with appropriate logout logic
  
• Ability to correctly receive and process SLO requests
  
• Ensure that role memberships are correctly re-read when switching between applications

Ordering process & governance

1. Ordering a new SSO/SLO group
   
   • The PL customer/partner fills out the official form (link in the eIAM dossier) and uploads it to the relevant eIAM dossier
     
   • Approval from all relevant ISBOs must be obtained by the PL customer/partner
     
   • The group composition (participating applications) is defined by the PL customer/partner
     
   • The application owner must ensure and test proper functionality (SSO & SLO)
   
   
2. Adding an application to an existing SSO/SLO group
   
   • Same procedure as for new setup:
     
     • Complete the form and upload to the dossier
       
     • Approval from relevant ISBO(s)
   • eIAM INT can assist with identifying relevant ISBOs and group members, but responsibility remains with the PL customer/partner
     
   • Application managers must ensure smooth integration
   
   
3. Removing an application from an existing group
   
   • No new form required
     
   • All stakeholders (eIAM INT, ISBOs, application owners) must be informed
     
   • Technical integrity of the remaining group members must be ensured

Cost implications for customers

• Implementing SSO within a common Fully Qualified Domain Name (FQDN) (e.g., www.gate.bit.admin.ch) is part of the standard implementation (Remedy CRQ)
  
• For SSO across multiple FQDNs, paid consulting is required based on effort

Usage information for end users (FAQ)