Duplicated and unauthenticated requests from users from a corporation using Zscaler for authentication

Question

We've got a Ruby on Rails application and some of our users connect to our website from a network of a company that uses Zscaler for network security/administration.

When an ajax request is made by one of these users, we see a pattern of requests that does not happen normally:

• First, we get an OPTIONS request to which we respond with 200 and some headers:

headers['Access-Control-Allow-Origin'] = request.headers['Origin'] || '*'
headers['Access-Control-Allow-Methods'] = 'GET, POST, PUT, DELETE, OPTIONS'
headers['Access-Control-Allow-Headers'] = 'Content-Type, Authorization, Origin, Content-Length, Accept, ' + request.headers['Access-Control-Request-Headers'].to_s
headers['Access-Control-Allow-Credentials'] = 'true'
headers['Access-Control-Max-Age'] = '600'

Note: This request has an additional parameter that we do not add nor use called _sm_byp (a sample value would be iVVsN0kN0745SVp5)

• Right after, we get a GET request that halts and redirects (302) because our server detects it as not signed in. As if the session cookies were not correct, maybe. This request also has the _sm_byp query parameter (same value as the OPTIONS request).

• Then, we see a successful GET request. This request does not have the _sm_byp parameter.

By investigating the origin of this parameter, I found out Zscaler might be the cause. Then I found out Zscaler manages these users' company network. Therefore, I am quite sure this is related to how Zscaler manages authentication.

I had a call with the Zscaler user support but they would not help without a user to reproduce the problem. They did explain that use SAML for authentication and sent me this link. The website explains this:

1. A user opens a browser and tries to reach a website.
2. The Zscaler service generates a SAML authentication request, which is encoded and embedded into the URL for the IdP.
3. The service sends a redirect to the user's browser. It includes the encoded SAML authentication request to be submitted to the IdP.
4. The user's browser submits the authentication request to the IdP.
5. The IdP (...) generates a SAML response with digitally signed public/private DSA/RSA keys, encodes it and sends it to browser.
6. The browser forwards the SAML response to the service. The CAS of Zscaler uses the IdP's public key to verify the response.
7. After the service successfully verifies the response, it logs in the user and redirects the user's browser to the destination URL.

I am thinking the _sm_byp parameter is related to the authentication request mentioned in point #2. And, could point #3 be the redirect (not signed in) we are getting? It seems normal that the ajax treats it as a failure since it is expecting a json but gets an html response (due to the redirect to the login page). Is this a normal auth behaviour? How should our RoR server respond to those requests? I could just ignore these ajax "errors" but I feel like we might be treating this the wrong way. I just want to make sure it's not Zscalers fault but ours.

Finally, these users have not made any complaint about this so we figured they are not really seeing any problem. However, although the OPTIONS and the first GET request are just a second apart, the successful GET request arrives about 40 seconds later. Therefore, I suspect they might actually be seing some problem but I am not 100% sure.