Cannot view application details after logging in when going through Cloud SWG
search cancel

Cannot view application details after logging in when going through Cloud SWG

book

Article ID: 400373

calendar_today

Updated On:

Products

Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

Users accessing internet services via Cloud SWG using Proxy forwarding access method.

Users in India, accessing a specific financial application, report seeing slow (or no) rendering of the application page after submitting the login credentials.

Users outside India (in France and UK), accessing the same application, report no such issues.

India users access the same on premise proxy servers in UK but for them the traffic is forwarded to GINMU POP versus GGBLO POP for UK and French users.

Environment

Proxy Forwarding.

Back end application hosted in UK.

Cause

Application backchannel validation of received authorization code timing out after 5 seconds.

 

Resolution

Increase application timeout so that access token validation completes successfully.

In the working case, the users would submit their credentials to an IAM server, get an authorization code which they would send to the back end application. The back end application would then send the code to the IAM server (via another non Cloud SWG, non proxy forwarding channel) and expect a corresponding access token within 5 seconds. In the case where it would take longer, the application would not render successfully and no error code or clue was returned.

Additional Information

Gathering the working and non working HAR files, we could see the credentials submitted to an authentication endpoint, where a 'code' was returned when successful.

This code could be seen as getting sent to the application (different domain) and in the working case, the HAR file showed an access token returned. In the non working case, no access token was returned.

Engaging the 3rd party application to understand the access token validation process, we understood that a separate backchannel existed between the two domains to validate the code and get an access token.

When the users failed, the 3rd party determined that the IAM server expected the code within 5 seconds of it being setup, and when it failed it was marked as invalid. Increasing this to 15 seconds addressed the issue.