Skip to main content

Extended Flow for Third-Party Initiated Authentication

The easiest way to integrate a third-party SAML Identity Provider (IDP) is to add a SAML IDP Connector pattern to your SAML SP Realm pattern.This approach is called direct integration.

Direct integration is not appropriate in the following cases:

  • If you also have an own IDP. In this case, you may have to configure multiple SAML IDP Connector patterns and have to come up with a Selection Expression for each of them.
    • The expression can become complex, and you have to ensure that always exactly one expression evaluates to "True".
    • In some cases this can even be impossible as the IDP selection may depend on unknown criteria.
  • If you have multiple SAML SP Realm patterns. In this case, maintaining the trust relationships for all IDPs can be cumbersome.

To overcome these issues, nevisAdmin 4 provides an experimental pattern called SAML Response Consumer.

The pattern itself is simple but the complete SAML flow is special and requires some explanation: Let's assume that we already have a basic SAML setup that includes a Nevis SP and a Nevis IDP. This basic setup is described in chapter SAML Flows for Authentication. However, instead of integrating the third-party IDP in our SP, we want it to be associated with our Nevis IDP. To achieve this, we configure a SAML Response Consumer pattern and select the same Virtual Host and Authentication Realm as in the SAML IDP pattern.

The following figure shows the resulting SAML flow:

Third-party initiated authentication - SAML flow

The SAML flow contains the following steps (the numbers of the steps correspond with the numbers in the figure above):

  1. The user wants to access a web application.
    1. The web application is hosted on www.siven.ch.
    2. To access the application, the user requests a URL at the third-party IDP. This triggers an IDP-initiated authentication.
  2. The third-party IDP authenticates the user and returns a SAML Response.
    1. The only known fact about this SAML Response is that the included assertion contains information about the user.
    2. The third-party IDP must also return a RelayState parameter, which contains the URL of the desired application.
    3. The browser is instructed to send both the SAML Response and the RelayState parameter to the SAML Response Consumer.
  3. The SAML Response Consumer consumes the SAML Response and ensures that the user is authenticated.
    1. The Issuer is extracted to dispatch into a corresponding ServiceProviderState.
    2. The ServiceProviderState validates the signature of the received SAML message.
    3. An Authentication Processing flow is executed. This flow can be complex as the exact steps depend on what we know about the user and the information we have received.
  4. The SAML Response Consumer now declares the authentication to be completed.
    1. The browser is redirected to the URL taken from the RelayState parameter. The remainder of the authentication flow is similar to an SP-initiated authentication. Check [SAML Flows for Authentication] for a more detailed description.
  5. There is no authenticated session on www.siven.ch. Therefore, access to the application is denied.
    1. The request is handed over to the SAML SP, which triggers SP-initiated authentication.
  6. The SAML SP forces the browser to send an AuthnRequest to our SAML IDP.
  7. The SAML IDP consumes the AuthnRequest.
    1. As the SAML IDP and the SAML Response Consumer are associated with the same Authentication Realm there already is a session.
    2. As the session is authenticated already, the IDP immediately returns a SAML Response without any user interaction.
  8. The browser is instructed to send the AuthnRequest to the SP.
  9. The SP consumes the SAML Response, authenticates the session and redirects it to the application.
  10. Now there is an authenticated session and the user is allowed to access the application.