Session Setup SAML 2.0 with RP-PEP

1. The session between the user's web browser and the RP-PEP.
2. The session between the RP-PEP and the application.

Session Setup between Web Browser and RP-PEP

Service Provider initiated Web SSO - Introduction
From the user's point of view, the RP-PEP together with the application behind the RP-PEP form a SAML Service Provider (SP). The user's initial request is sent to this Service Provider without the user having authenticated himself beforehand. The RP-PEP decides via the defined policy whether prior authentication of the user is necessary for processing and forwarding the request. The RP-PEP as SAML SP initiates the authentication if necessary. We also speak of a so-called service provider initiated scenario or "SP First" for short.

Service Provider initiated Web SSO - Procedure
The figure below shows the security context (SSO session) on the RP-PEP in the open architecture with the actors involved. The RP-PEP itself does not keep any information about the user. It delegates the authentication of the user to the eIAM Trustbroker as Federation Provider (FP), which in turn delegates the authentication of the user to an Identity Provider (IdP) defined for the called application. The eIAM Trustbroker has access to the Attribute Provider (AP) eIAM-AM, which holds the roles and other attributes of the user required for access management.

The structure of the session between application and RP-PEP is described below under "Session structure between application and RP-PEP".

Session Setup Web Browser PEP

1. The unauthenticated user calls the URL of the web application on the RP-PEP. Request is "intercepted" by the RP-PEP.
2. The RP-PEP determines that a security context is necessary for the request, but no such context exists. RP-PEP determines via the stored policy that the user making the request must be authenticated and that a certain authorisation is required for access.
3. The RP-PEP issues a SAML 2.0 AuthnRequest, which is sent to the user's web browser in a selfsubmitting HTML form with the destination eIAM Trustbroker. With this form, the URL that the user originally called up is included in another parameter RelayState, so that the user can be redirected to this URL by the PEP after successful authentication. Furthermore, a temporary cookie is set to track requests from this client.
4. The user's web browser automatically sends the HTML form with the AuthnRequest to the eIAM Trustbroker via Java Script.
5. The eIAM-Trustbroker checks whether the AuthnRequest originates from an issuer with whom a trust relationship exists.
6. The eIAM-Trustbroker sends the user an HTML form with the selection of the IdP available for authentication if the AuthnRequest check was successful.
7. The user sends the IdP selection to the eIAM Trustbroker.
8. The Trustbroker issues a SAML 2.0 AuthnRequest which is sent to the user's web browser in a selfsubmitting HTML form with the destination IdP.
9. The user's web browser automatically sends the HTML form with the AuthnRequest to the Identity Provider (IdP) via Java Script.
10. The identity provider checks the AuthnRequest to see whether it comes from an issuer with whom a relationship of trust exists.
11. If the AuthnRequest check is successful, the IdP authenticates the user.
12. The user is authenticated by the Identity Provider - The authentication process varies depending on the IdP selected and is not in the scope of this description.
13. -Check the authentication means(s) on the IdP - The detailed authentication procedure varies depending on the IdP selected and is not in the scope of this guide.
14. On successful authentication of the user, the IdP issues a SAML 2.0 response with an assertion. The SAML response is sent to the user's web browser in a selfsubmitting HTML form.
15. The user's web browser automatically sends the HTML form with the SAML response to the eIAM Trustbroker via Java Script.
16. The eIAM Trustbroker checks the incoming SAML response and consumes the attributes contained therein.
17. The Trustbroker searches for the user authenticated by the Identity Provider in the eIAM-AM and requests additional attributes from this user, which are maintained in the eIAM-AM via the user, such as user ID, departmental affiliation, authorisation roles, etc.
18. The Trustbroker issues a SAML 2.0 response with an assertion containing attributes that originate from the Identity Provider on the one hand and from the eIAM-AM on the other.
19. The SAML response is sent to the user's web browser in a selfsubmitting HTML form.
20. The user's web browser automatically sends the HTML form with the SAML response to the PEP via Java Script.
21. The RP-PEP checks the received SAML Response and the contained assertion. If the check is successful, the attributes from the assertion are consumed by the PEP and a security context (session) is created.
22. The RP-PEP sends the user's web browser an HTTP redirect to the URL originally called up by the user (URL from the RelayState). With this HTTP response, a permanent (for the duration of the browser session) session cookie of the RP-PEP is set on the user's browser.
23. The user's web browser calls up the URL to which it was redirected.
24. The RP-PEP checks whether the defined policy is adhered to. To do this, the request must originate from an authenticated user, the authentication must have been carried out with the strength required to access this resource and the user must have the coarse-grained role required to access the resource. If the check was successful, the RP-PEP sends the request on to the application.

Session setup between application and RP-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".

Note:
The application cannot force re-authentication of the user of a running PEP session via the RP-PEP (by setting the 'ForceAuthn' attribute in the AuthnRe-quest).

SP initiated Web SSO - Procedure
The following describes the structure of the security context (session) between the SAML 2.0-capable application within the networks of the Federal Administration and the RP-PEP. The starting point is an existing session of the user on the RP-PEP. From the application's point of view, the PEP is in the role of a SAML 2.0 Identity Provider (IdP). From the RP-PEP's point of view, the application is a SAML 2.0 Service Provider (SP). If several applications are integrated behind the RP-PEP, each of the applications must set up a security context for itself with the described procedure if such a context is required by the application.

Session Structure Application PEP

1. Request from the user within an already established session on the RP-PEP.
   
2. Request is forwarded to the application.
3. The application checks the request and determines that a security context (session) is needed but none exists yet.
4. The application creates a SAML 2.0 AuthnRequest and transmits it to the RP-PEP in a selfsubmitting HTML form
5. .
   
6. The RP-PEP forwards the SAML 2.0 AuthnRequest to the user's web browser.
7. The user's web browser automatically sends the HTML form via Java Script to the URL defined in the form on the eIAM-Web PEP.
8. The RP-PEP checks the AuthnRequest and if the check is successful creates a SAML 2.0 response which contains an assertion with information about the user (subject) and attributes. The source of this information is the user's existing session on the RP-PEP.
   
9. The SAML response is packed into a selfsubmitting HTML form and sent to the user's web browser.
10. The user's web browser automatically sends the HTML form via Java Script to the destination defined in the form on the eIAM-Web PEP. The URL to which this form must be posted is the URL of the application's Assertion Consumer Service as accessed via the RP-PEP.
11. The RP-PEP forwards the HTML form to the URL of the application's assertion consumer service.
12. The application checks the SAML 2.0 response and the assertion and, if successful, creates a security context (session).
13. The application redirects the user's web browser to the URL from the RelayState or to another URI defined by it. With this response, the application sets a session cookie which is cached on the RP-PEP (application cookies are cached on the RP-PEP by default and only exchanged between RP-PEP and the application).
14. The RP-PEP sends the response with the application's redirect on to the web browser.
15. The web browser calls up the URL to which it was redirected.
16. The RP-PEP forwards the request of the web browser to the application. In the process, cookies that the application has set in earlier steps are also sent.
17. The response HTTP response of the application is sent to the RP-PEP.
18. The HTTP response is sent from RP-PEP to the web browser.
19. And the following - Follow-up Requests now run as described in points 14 - 17.

• The procedure is supported by all current SAML 2.0 implementations and is well documented for 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 RP-PEP (only allow authenticated and authorised requests to the application). This logic does not have to be statically implemented on the RP-PEP. Thus, no changes are necessary on the RP-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 RP-PEP at any time.
• Requires no backchannel connections between service provider and identity provider, as the complete communication takes place via the user's browser. This is particularly important for applications that are hosted outside the networks of the Federal Administration.