ZTNA is not retaining the RelayState URL when users accessing applications

Products

• Symantec ZTNA

Issue/Introduction

ZTNA users must authenticate via a SAML Identity Provider.

When users initially access a URL that contains a '#' character and are redirected to authenticate to the SAML Identity Provider, the user is not redirected to the original URL they were going to after a successful authentication.

HAR file would appear to show that the original path is truncated, and hence the redirect post authentication is not going to the URL initially accessed. Everything after the '#' in the URL is missing.

The RelayState parameter confirms that the URL is truncated, and this is where the user is sent post authentication. The SAML RelayState is the HTTP parameter used during Single Sign-On (SSO) to preserve application state. It acts as a redirect token that ensures a user is sent back to their originally requested deep link or a specific landing page after authenticating, rather than a generic default home page.

If the user is already authenticated to ZTNA before accessing the URL that includes a '#' character, then the page appears as expected.

 

Environment

ZTNA.

SAML Identity Provider.

 

Cause

The # character in a URI introduces the fragment identifier (often called the hash or anchor). The fragment identifier (RFC 3986) is strictly a client-side directive where:

• The Server's Job: To locate and deliver the entire resource (the HTML page, the video, the JSON file, etc.).
• The Browser's Job: To display that resource to the user. The fragment tells the browser where to look or what to do once the resource has already arrived.

For example, if you visit https://example.com/page.html#section3, the server only cares about finding page.html. Once the browser downloads page.html, it looks for an element with id="section3" and automatically scrolls down to it.

Resolution

This issue will happen regardless of ZTNA, but whenever any redirects where the original URL needs to be maintained. To workaround the issue, one can either

• encode the '#' character with %23 : The browser treats %23 as part of the data path or query string, not a fragment delimiter, so it will be sent to the server, or
• make sure that users are authenticated in advance of accessing any URLs that contain '#' character, hence avoiding the truncation triggered via redirects.

Additional Information

The HAR file when the issue was reported showed the following key pieces of info:

1. The original request sent to ZTNA service: https://www.example.com/example/#/link
2. ZTNA redirected the request to the ZTNA login service with the following redirect URL: https://example.luminatesec.com/accezz-login?accezz_redirect=https%3A%2F%2Fwww.example.com%2Fexample%2F (note everything including and beyond the # is missing
3. The ZTNA login service then redirected user agent to the SAML Identity Provider provider, passing in the SAML request and RelayState which only included everything up to the # character:
   https://idp.example.com/saml/login?RelayState=https%3A%2F%2Fwww.example.com%2Fexample%2F&SAMLRequest=...
4. After successfully authenticating at the SAML Identity provider, the assertion was sent back and user redirected to the RelayState URL, and not the original URL which was lost.