Support Preservation of RelayState in IdP-Init SAML workflows

[jobannon]

Problem

I would like to direct by user to a specific RelayState after the AuthN response to sent (I am using IDP-init workflows). Currently, we will redirect where the user would like but will not preserve the RelayState when provided

Solution

FusionAuth should support preservation of the RelayState value as part of the AuthN response.

Additional context

• This is supported by many SAML providers when initiating an IdP initiated workflow https://docs.aws.amazon.com/appstream2/latest/developerguide/external-identity-providers-further-info.html

• Ticket: https://fusionauth.zendesk.com/agent/tickets/77074

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[lyleschemmerling]

My reading of the spec suggests that, actually, there is no standard for what the request to FusionAuth should be in regards to RelayState, though at the moment we treat it as synonymous with redirect_uri. However, it does indicate that, optionally, the RelayState may be sent along with the unsolicited SAML Response to the service provider in an IDP-initiated login to act as a redirect URI for the service provider to send the browser after returning to the ACS endpoint.

As it is at the moment FusionAuth will consume the RelayState parameter in the initiate-login URL, use that as what is effectively the redirect to the ACS endpoint, and then discard it. We never send a RelayState to the SP in an IDP-initiated flow.

We should consider this carefully as the potential to break people with existing integrations with our IDP-init flow is fairly high.

[spwitt]

Section 3.4.3 of the SAML Bindings spec (because they can't contain it all in one spec) has the following to say about RelayState

If no such value is included with a SAML request message, or if the SAML response message is being generated without a corresponding request, then the SAML responder MAY include RelayState data to be interpreted by the recipient based on the use of a profile or prior agreement between the parties.

One option is to use and then clear the RelayState as we are today if it is one of the application's SAML Authorized redirect URLs. This maintains existing functionality of allowing the caller to select an ACS URL based on this parameter. If the RelayState value is not one of the configured SAML redirect URLs, then we try the next option to determine the ACS URL and leave the RelayState intact.