WS-Federation in the Federal Administration Network
This document is intended for project managers, application managers, developers, architects and integration managers who integrate applications with the eIAM service within the Federal Administration network on the basis of the WS-Federation identity protocol.
WS-FED Integration
The following figure shows the simplified process and the components involved when a user who has not yet been authenticated accesses a web application in the networks of the Federal Administration that is protected via the eIAM web component. The individual steps are described below.-
- eIAM user access to a protected resource with WS-Federation
| No. | Action | Description |
|---|---|---|
| 1 | User attempts to access the protected resource of a web application | The eIAM-Web PEP detects that the resource to be accessed is protected and that the access is from a user who is not yet authenticated. |
| 2 | SAML AuthnRequest to user's web browser | The eIAM-Web PEP issues a signed SAML 2.0 Authn-Request to the eIAM Trustbroker and sends it as a self-submitting form to the user's web browser. |
| 3 | SAML AuthnRequest to eIAM Trustbroker | The user's browser automatically sends the form to the eIAM Trustbroker via Browser POST using Java Script. |
| 4 | Home Realm Discovery and SAML AuthnRequest to the user's web browser | The eIAM Trustbroker performs a Home Realm Discovery and determines the IdP to be used for authentication. The eIAM Trustbroker issues a signed SAML 2.0 Auth-nRequest to the IdP and sends it as a self-submitting form to the user's web browser.
|
| 5 | SAML AuthnRequest to IdP | The user's browser automatically sends the form to the IdP via browser POST using Java Script. |
| 6 | Authentication of the user | The IdP carries out an authentication of the user, which varies depending on the specification. If the authentication is successful, the IdP creates a SAML response containing a signed assertion with information about the subject and attributes of the subject (also called claims); |
| 7 | SAML Response to the user's web browser | The IdP sends the SAML Response as a self-transmitting form to the user's web browser. |
| 8 | SAML Response to eIAM Trustbroker | The user's browser automatically sends the form to the eIAM Trustbroker via Browser POST using Java Script. The eIAM Trustbroker searches for the subject from the SAML assertion in the eIAM-AM. The eIAM Trustbroker enriches the SAML assertion of the IdP with further attributes (e.g. UserId and authorisation roles) from the eIAM-AM and creates a SAML response with a SAML assertion for the attention of the eIAM-Web PEP; |
| 9 | SAML Response to user's web browser | The eIAM-Trustbroker sends the SAML Response as a self-submitting form to the user's web browser. |
| 10 | SAML Response to eIAM-Web PEP | The user's browser automatically sends the form via Brow-ser POST to the eIAM-Web PEP using Java Script. |
| 11 | Check SAML assertion and redirect to RelayState | The eIAM-Web PEP checks the SAML response and the assertion. If successful, the eIAM-Web PEP creates a session with the user. The eIAM-Web PEP redirects the user to the URL from the RelayState. This is the URL the user originally called (before authentication). With this response, a session cookie is issued to track the session between the client and the PEP. |
| 12 | The user's web browser tries to access the protected resource of the web application again | With this request, there is now a session with the user. The PEP checks whether the user is authorised to access this resource and, if successful, forwards the user's re-request to the application. |
| 13 | Application checks user's authorisation | The application recognises that the user wants to access a protected area, but from its point of view the user is not yet authenticated. The application redirects the user's web browser to the WS-Federation interface of the eIAM-Web PEP |
| 14 | wsignin Request to PEP | The user's web browser calls the WS-Federation interface of the eIAM-Web PEP with the necessary parameters. |
| 15 | WS RequestSecurityToken response for application | The eIAM-Web PEP checks the incoming wsignin request and connects it to the user's existing session via the session cookie. The eIAM-Web PEP issues a RequestSecurityToken response with a SAML assertion and sends this response as a self-transmitting form to the user's web browser. |
| 16 | WS RequestSecurityToken-Response to application | The user's browser automatically sends the form to the application via browser POST using Java Script. |
| 17 | Check SAML assertion and redirect to RelayState | The application checks the Security Token Response and the SAML assertion it contains. If successful, the application creates a session with the user. The application redirects the user's web browser to a URL of its choice. With this response, a session cookie is issued, which is used to track the session between client and application; |
| 18 | The user's web browser tries to access the protected resource of the web application again | The eIAM-Web PEP allows the request to pass through to the application, since a valid session exists and the user has the necessary coarse-grained authorisation role. The application in turn allows the request because a valid session exists and the user has the necessary fine-grained role to perform the desired operation on the application; |
| 19 | Response to the user's web browser | The application sends the response to the user's web browser. |