Session setup SAML 2.0 with STS-PEP

For applications outside the Federal Administration networks, the session between the user's web browser and the application is managed by the application itself, since the HTTP requests between the web browser and the application do not run via the STS-PEP.

Session Setup between Web Browser and STS-PEP

This chapter describes the session setup process between the user's web browser and the application using eIAM STS-PEP.

SP initiated Web SSO - Introduction
When processing the first request in the application, the application does not yet know which user it is dealing with, as no security context has yet been established. It is therefore up to the application to decide whether a security context must be established for the selected access.

If the application decides that authentication and authorisation must take place for the request, it can initiate this using the "SP initiated Web SSO" scenario. This scenario is also colloquially referred to as "SP-First".

Service Provider First

SP initiated Web SSO - Advantages
The SP initiated Web SSO scenario was chosen for connecting applications to eIAM because it offers some weighty advantages over other methods (e.g. IdP initiated Web SSO).

  • The procedure is supported by all current SAML 2.0 implementations and is well documented in these products.
  • The procedure allows the application itself to decide whether a security context is required for access to the resource, without having to violate the enforcement of the policy on the STS-PEP (only allow authenticated and authorised requests to the application). This logic does not have to be statically implemented on the PEP. Thus, no changes are necessary on the STS-PEP when changes are made in the application.
  • If the security context on the application is lost, e.g. due to a session time-out in the application or due to a restart of the application, the application can request a new SAML assertion from the STS-PEP at any time.
  • Does not require any backchannel connections between service provider and identity provider, as the entire communication takes place via the user's browser. This is particularly important for applications that are hosted outside the networks of the Federal Administration.

Session setup between applications and STS-PEP

Introduction
In contrast to the scenario in which the application is hosted within the Federal Administration's networks and can therefore only be accessed via the RP-PEP as the front door, the application can be accessed directly outside the Federal Administration's networks without first involving the STS-PEP.

Procedure
The following describes the process of establishing sessions between the user's web browser, the STS-PEP and the applications hosted outside the Federal Administration's networks.

Session Setting up applications outside the networks of the Federal Administration
Session Setting up applications outside the networks of the Federal Administration


  1. The user's web browser invokes the application.
  2. The application determines that authorisation is required to access the resource and checks whether a session with the user already exists.
  3. Since no session exists yet, the application issues a SAML AuthnRequest signed by it for the attention of the STS-PEP and embeds it in a self-submitting HTML form. In addition, the URL requested by the user in the original request in step 1 is specified in the "RelayState" parameter so that the user's browser can be redirected to this URL after the authentication has been completed.
  4. The web browser sends the AuthnRequest via HTTP POST to the SSO URL of the STS-PEP.
  5. The STS-PEP checks the SAML AuthnRequest for validity and whether the request originates from a trusted application. If this is the case, the STS-PEP checks whether a session already exists with the user's web browser.
  6. If there is no session with the user's web browser on the STS-PEP, the STS-PEP in turn issues a SAML AuthnRequest signed by itself for the attention of the eIAM Trustbroker. This is embedded in a self-transmitting HTML form and transmitted to the user's web browser as an HTTP response.
  7. The user's browser sends the SAML AuthnRequest of the STS-PEP via HTTP POST to the eIAM-Trust Broker.
  8. The eIAM Trustbroker checks the SAML AuthnRequest for validity and whether it comes from a trusted STS-PEP. If this is the case, the eIAM Trustbroker starts the so-called Home Realm Discovery. It generates a list of identity providers available to authenticate the user. This list can be defined differently for users from the Federal Administration network and for users outside the Federal Administration networks.
  9. If several options are available for authentication in the same network zone, a selection is displayed to the user.
  10. The user sends the choice of the identity provider to be used via HTTP POST to the eIAM trust broker.
  11. The eIAM Trustbroker creates a SAML AuthnRequest signed by the user for the IdP selected by the user. This is embedded in a self-submitting HTML form and transmitted to the user's web browser as an HTTP response.
  12. The user's web browser sends the SAML AuthnRequest of the eIAM Trustbroker via HTTP POST to the Identity Provider.
  13. The Identity Provider checks the SAML AuthnRequest for validity and whether it comes from a trusted eIAM Trustbroker. If this is the case, the IdP performs authentication with the user.
  14. .
  15. Authentication on the IdP. The process of the actual authentication varies from IdP to IdP and is not part of this description.
  16. After successful authentication of the user, the IdP issues a SAML response to the eIAM Trustbroker. This SAML response contains an assertion with information about the user and attributes. The amount and type of attributes can vary from IdP to IdP. The assertion in the SAML response is signed by the IdP. The SAML response is embedded in a self-submitting HTML form and transmitted to the user's web browser as an HTTP response.
  17. The user's web browser sends the SAML Response via HTTP POST to the eIAM Trust Broker.
  18. The eIAM Trust Broker checks the SAML Response and validates the assertion to ensure that it was signed by a trusted IdP and has not been subsequently modified.
  19. The eIAM Trustbroker searches for the subject (user) reported by the IdP in the SAML assertion in the eIAM-AM superclient using the identity reference.
  20. -If a user with a corresponding identity reference is found in the eIAM-AM superclient, the user's account is searched for in the eIAM-AM access client of the department that administers the permissions for the departmental application.
  21. The eIAM Trustbroker enriches the SAML assertion from the IdP with further attributes (e.g. authorisation roles) from the query in the eIAM-AM. The eIAM Trustbroker creates a SAML response for the attention of the STS-PEP. The response contains a SAML assertion signed by the eIAM Trustbroker.
  22. The SAML response is embedded in a self-submitting HTML form and delivered to the user's web browser as an HTTP response.
  23. The web browser sends the SAML response to the STS-PEP via HTTP POST.
  24. The STS-PEP checks the validity of the SAML response and validates the assertion to ensure that it comes from an eIAM Trustbroker that it trusts. It also checks that the assertion has not been modified after it was signed. If the check is successful, the STS-PEP creates a session with the user's web browser. In the session on the STS-PEP, the user's attributes are stored for later reuse. A session cookie is issued to track this session. The STS-PEP creates a SAML response with an assertion signed by it. This assertion contains attributes of the user, which he has received from the IdP and from eIAM-AM.
  25. The SAML response is embedded in a self-submitting HTML form and delivered to the user's web browser as an HTTP response.
  26. The web browser sends the SAML response to the application via HTTP POST. In the process, the parameter "RelayState" is also passed on again.
  27. The application checks the SAML response for validity and validates the assertion contained therein to ensure that it was issued by a trusted STS-PEP and has not been subsequently changed after signing. The application creates a session with the user's web browser. In the session, it lists the user's attributes (claims) from the SAML assertion.
  28. The application sends a redirect to the address stored in the "RelayState" with the HTTP response to the web browser. The web browser is thus sent back to the URL requested in step 1. The application sets a session cookie with this HTTP response to track the session of the web browser.
  29. The web browser calls up the address on the application to which it was redirected.
  30. Since there is now a session between the web browser and the application, and the user's authorisation check is positive, the requested resource is sent back to the user as an HTTP response.
  31. This sequence shows the access of the same user with the same web browser to a second application in the same SSO domain (both applications use the same STS-PEP). Here, the steps on the eIAM Trustbroker and the IdP are omitted. Since an SSO session already exists on the STS-PEP, it can directly issue a SAML assertion for the application.