BTB: SSO/SLO Overview

(BTB: Bundes Trustbroker, SSO: Single Sign-On, SLO: Single Logoff)

This page contains a detailed description of the SSO/SLO functionality including descriptions from the user perspective.

BTB: SSO/SLO Overview

Single Sign-On (SSO)

The BTB SSO allows the configuration of SSO groups. An SSO group defines a trusted group of services and applications within which a performed user authentication is no longer required once the user has successfully logged in to an application of the SSO group.
  • An application can belong to only one SSO group → SSO groups are intersection-free (disjoint).
  • Each successful login generates one SSO session. It may happen that although applications belong to the same SSO group, multiple logins are still necessary. See Example
    ×

    An SSO group is defined with application A and B.
    For application A, a user login via identity providers FED-LOGIN and CH-LOGIN is possible, for application B only CH-LOGIN.
    If the user first logs in for application A using the FED-LOGIN, an SSO session FED-LOGIN is generated. When application B is accessed , the user must log in using CH-LOGIN, so another SSO session CH-LOGIN is created.
    However, if the user initially logs in using the CH-LOGIN in this scenario, an SSO Session CH-LOGIN is created. When the other application is accessed, no new login is then required.

Single Logout (SLO)

Using BTB SLO, all applications within the same SSO session are terminated compliantly when the user;
  • actively logs out of an application using the "Logout" button
  • closes all browser instances (windows)
  • reaches the configured session lifetime (session lifetime, with active session Max 12 hours, with inactive sessions 2 hrs).
Application requirement:
  • The login, logout and re-login with the IdPs set and the Minimum QoA level on the application works.
  • A logout button to a logout page has been implemented in the application.

Order, set up and maintain SSO/SLO groups

Here it should be described how and where the customer can order the feature and how the stakeholders can then maintain them.

Cost implications for customers

SSO under a common Fully Qualified Domain Name (FQDN; e.g. www.gate.bit.admin.ch) can be easily realised today and is included in an eIAM standard implementation (Remedy CRQ). Requirements for SSO via multiple FQDNs require a consulting charge on a time basis.

SSO/SLO Usage Information

This section answers the most common questions about BTB SSO/SLO usage from a user perspective.

Can I view my active SSO sessions?
No, this is not possible.

What happens if my QoA of an SSO session is not sufficient to access an application?
If a valid SSO session exists and the user wants to access an application associated with that SSO group, but the application requires a higher QoA than the SSO session has, then the user must authenticate using the appropriate method to achieve the required QoA. If authentication is successful, the QoA of the existing SSO session is adjusted to the higher authentication strength.

How can I avoid joining an SSO session?
If a user also wants to log in to an application that is defined in the same SSO/SLO group and does not want to use this service, they can bypass this by using a different browser (Edge, Chrome, Firefox, etc.) for this application.

I want to go in with CH-LOGIN but I always get logged in on FED-LOGIN SSO?
Use an Incognito Window or other browser, preferably with Private Notebook instead of Federal-Workplace.