Session Termination STS-PEP

For applications outside the networks of the Federal Administration, only the scenario session termination by logout is possible, since the STS-PEP has no way of informing the participants of the SSO session without a SAML single logout being initiated by the user.

Session termination by logout applications with STS-PEPs.
The following sequence explains the session termination process for applications which are not hosted behind an STS-PEP but somewhere else (BV-Net, Cloud). Since these applications do not use the STS-PEP as a front door for all connections between the web browser and the application, the STS-PEP cannot be the master over all sessions. However, as the SAML IdP from the application's point of view, the STS-PEP is the only entity that knows all service providers used within the SSO session and can inform them about the end of a session.

The initial situation is an existing session of the user's browser with the STS-PEP. In the SSO session, application A and application B were used by the user. Both applications have subsequently sent a SAML AuthnRequest to the STS-PEP and received a SAML response from it.

Session termination by logout for applications outside the networks of the Federal Administration
Session termination by logout for applications outside the networks of the Federal Administration

  1. The user sends an HTTP request to the logout URI of application A.
  2. Application A creates a signed SAML logout request to the STS-PEP. It embeds the SAML LogoutRequest in a self-submitting HTML form and sends it as HTTP response to the web browser.
  3. The Web Browser sends the LogoutRequest via HTTP POST to the Single Logout Lo-cation URL of the STS-PEP.
  4. The STS-PEP as IdP checks the SAML LogoutRequest for its signature and searches for the corresponding SSO session. It forms a list of all service providers to be informed about the logout. The STS-PEP creates a signed SAML LogoutRequest for the attention of application B.
  5. The STS-PEP transmits the SAML Logout Request via a self-submitting HTML form in the HTTP response to the Web Browser.
  6. The Web Browser sends the LogoutRequest via HTTP POST to the SingleLogout Location URL of Application B.
  7. Application B checks the SAML LogoutRequest, identifies the session and generates a signed SAML LogoutResponse. The session on application B is terminated.
  8. The LogoutResponse is transmitted to the web browser via a self-submitting HTML form in the HTTP response.
  9. The Web Browser sends the LogoutResponse via HTTP POST to the STS-PEP.
  10. The STS-PEP checks the LogoutResponse. If other applications were used in the SSO session, they will be informed of the end of the session in the same way. If application B was the last application that did not initiate the SAML Single-Logout, the STS-PEP creates a signed SAML Logout Response for the attention of application A.
  11. The logout response is embedded in a self-submitting HTML form and sent to the user's browser in the HTTP response.
  12. The web browser sends the LogoutResponse via HTTP POST to application A.
  13. Application A checks the LogoutResponse and terminates the user's session.
  14. Application A sends confirmation to the user's web browser in the HTTP response that the logout has been performed and the SSO session has been terminated.

Session termination due to session inactivity

Another possibility why the user's session on the STS-PEP is invalidated and terminated is due to prolonged inactivity on the session. The termination of inactive sessions is done on the one hand for security reasons and on the other hand to free up system resources that are not needed.

The termination of the session initiated by the STS-PEP due to a longer period of inactivity is described in the following procedure. Since the logout was not initiated by a user re-request, no information about the logout can be displayed to the user. If the user sends a request to the STS-PEP again after ending the session on the STS-PEP due to too long inactivity, a new session is started with the user's web browser.

Session termination due to session inactivity
Session termination due to session inactivity


  1. The web browser sends an HTTP request for application A to the STS-PEP in the running session.
  2. The STS-PEP sends the HTTP request to application A in the current session.
  3. The application A sends the HTTP response to the STS-PEP.
  4. The STS-PEP sends the response to the Web Browser.
  5. The web browser sends an HTTP request for application B to the STS-PEP in the current session.
  6. The STS-PEP sends the HTTP request to application B in the current session.
  7. The application B sends the HTTP response to the STS-PEP.
  8. The STS-PEP sends the HTTP response to the web browser.
  9. After the Inactivity Interval defined on the STS-PEP has expired (time period in which no more requests were received from the PEP on this session), the STS-PEP initiates the logout on application A on its own and sends an HTTP request to the logout URL of the application, together with the session cookie issued by the application.
  10. Application A invalidates the user's session.
  11. Application A sends an HTTP response to the STS-PEP. This HTTP response is not forwarded to the web browser because the browser did not make an HTTP request.
  12. The STS-PEP sends an HTTP request to the logout URL of application B together with the session cookie that application B has issued.
  13. The application B sends an HTTP response to the STS-PEP. This HTTP response is not forwarded to the web browser because the browser has not made an HTTP request.
  14. The STS-PEP invalidates the user's session. The termination of the session on the PEP occurs regardless of the applications response to the call to the logout URL.

Session termination by reaching the maximum session duration

Another possibility why the user's session on the STS-PEP is invalidated and terminated is when the maximum allowed session lifetime is reached. If this is reached, the session is automatically invalidated on the STS-PEP and all applications used during the session are notified by the STS-PEP that the session has been invalidated. The session will be invalidated even if there is still activity on the session. The maximum session duration on the STS-PEP is limited.

The termination of the session initiated by the STS-PEP when the maximum session duration is reached is as described below. SAML 2.0 Single Logout (SLO) is not supported.

Session Scheduling Max. Session Lifetime
Session Scheduling Max. Session Lifetime


The initial situation is an already existing session between the user's web browser and the STS-PEP. Applications A and B are used during the session.
  1. The web browser sends an HTTP request to the STS-PEP for application A.
  2. The STS-PEP forwards the HTTP request to application A after checking it.
  3. Application A processes the HTTP request and sends the HTTP response to the STS-PEP.
  4. The STS-PEP sends the HTTP response to the Web Browser.
  5. The web browser sends an HTTP request to the STS-PEP for application B.
  6. The STS-PEP sends the HTTP request to application B after checking it.
  7. Application B processes the HTTP request and sends the response to the STS-PEP.
  8. The STS-PEP sends the HTTP response to the web browser.
  9. The user's session on the STS-PEP reaches the maximum lifetime.
  10. The STS-PEP sends an HTTP request to the logout URL of application A together with the session cookie of application A.
  11. Application A invalidates the user's session.
  12. Application A sends the HTTP response to the PEP. This HTTP response is not passed on to the user's web browser.
  13. The STS-PEP sends an HTTP request to the logout URL of application B together with the session cookie of application B.
  14. Application B invalidates the user's session.
  15. Application B sends the HTTP response to the STS-PEP. This response is not forwarded by the STS-PEP to the user's browser.
  16. The STS-PEP invalidates the user's session.
  17. The user's web browser sends a new HTTP request to the STS-PEP together with the now invalid STS-PEP session cookie.
  18. The STS-PEP checks the HTTP request and detects that a new security context needs to be established.
  19. The STS-PEP redirects the web browser to the STS-PEP login URL. A new session cookie is set in the web browser with the HTTP response.
  20. The web browser sends the HTTP request to the STS-PEP login URL.
The further establishment of the session and the forwarding of the requests are carried out as described above.