With SAML, trust is established between all parties by exchanging metadata. These metadata contain all the information necessary for one entity to send a message to another (like endpoint locations, bindings and signing certificates). SURFconext couples the SP and the IdP based on specific rules. Note that SURFconext itself does not authenticate users, this is done by the connected Identity Providers.

SAML authentication process in steps

The figure shows you the sign-on process step-by-step. Let's imagine Alice want's to sign-on to a Google Mail instance that is registered for her institution on SURFconext. The authentication will be as shown in the figure below. All messages are send from the browser of the user. In blue you see what happens in the browser of the user at SURFconext. Let's dive into this.

1. Alice will access the remote application using a link on the intranet, a bookmark or similar and the application will load. Let's assume the URL is https://mail.google.com/a/my-university.nl
2. The application identifies the user’s origin by the application subdomain, user IP address or similar and redirects the user back to the identity provider, asking for authentication. When connected to SURFconext, SURFconext is the Identity Provider to the service. This is the authentication request and the SP will generate a SAML Request.
3. The SP will instruct the browser to redirect the user to SURFconext with a request to authenticate the user.
4. When Alice's browser arrives at the SURFconext she must select her IdP for authentication. This is done using the so-called WAYF (Were Are You From) page. Alice chooses the institution she has an account with.
5. Embedded in the redirection is a SAML Authentication Request. This message is compressed to save space in the URL and encoded because some characters are not allowed in URL's. Simply said, this message is: "This is a request from the SP with EntityID ' https://mail.google.com/a/my-university.nl'. Please authenticate the user and send the result back to me." For detailed information about the authentication request read our page about authentication requests.  The IdP will continue to the next step.
6. After successful authentication, the IdP builds the authentication response in the form of an XML-document, signs it using an X.509 certificate, and posts this information to the service provider, which is SURFconext for the IdP.  This is the SAML Response and this message also contains the attributes from the user.
7. The IdP sends sends the Encoded SAML Response to Alice' browser. Basically this says “This is a message from idp.my-university.nl, I have successfully authenticated a user. Take note that this message will expire in a couple of minutes”. The message contains an XML digital signature, proving that the message was sent by idp.my-university.nl. The signature was made using a public key algorithm, the public key being embedded in a certificate known to the SP.
8. SURFconext validates the response message and if OK makes some alterations, e.g. rewriting the user's identifier and adding or modifying attributes. According to the attribute release policy applied, SURFconext determines the attributes that are allowed through to the Service Provider. The SAML Response instructs the browser of Alice to send the response to the Assertion Consumer Service (ACS) URL of the SP. An Assertion is a set of security statements about a subject created by an Asserting Party, being an IdP.
9. The SP verifies the XML signature, checks if the authentication was successful and if the message is not expired. Then it extracts the user’s identifier and attributes as known to SP. If this step is OK, Alice is logged on, her mailbox is retrieved and she can read her mail.

Most services will use the flow as described. You will have noticed the service only needs to connect to SURFconext, which is the identity provider to the service, and all the user data such as passwords are managed by IdP's and attributes are managed by SURFconext which will save you a lot of hassle. SURFconext acts as both an IdP as SP. An It is an IdP to SP's and an SP to IdP's.

Navigate

Page Tree
root Documentation for Service Providers searchBox true