OPENID Keycloak integration - Redirect response is too big and make NGINX fail upstream sent too big header

[ale-cristofori]

When a user logs into MapStore using the new functionality of the OPEN ID integration, they receive a final response from server in case of successful login, that redirects the user to the MapStore main page.

Such response contains headers, which in turn contain a series of setCookie headers which in turn contain tokens that have a significant length see the pdf attached with an example of a request (highlighted in red) and the response (in blue). The tokens in the response access_token, refresh token, KEYCLOAK_ADAPTER_STATE.

The length of these headers does not play well with NGNIX settings that limits the size amount of memory that NGINX will allocate for each request to the proxied server.

As a temporary fix we increased on NGINX settings in the configuration file ngnix.conf the size of proxy_buffer_size, proxy_buffers and proxy_busy_buffers_size.

proxy_buffer_size          128k;
    proxy_buffers              4 256k;
    proxy_busy_buffers_size    256k;

Those settings though should not be kept as such as we would require the client to change their NGNIX settings, we would need to find a solution that could limit the amount of size of the headers, if there is a viable one. @offtherailz, could you confirm?
debug1.pdf

This can be tested on the geoFIT deployed instance
https://pgiis.geofit.fr/mapstore/#/

The user ale-cristofori
the password, along with the details to connect to the VM hosting the deployed instance is available here

[ale-cristofori]

@taba90 I cannot assign issues on this board apparently, could you have a look at this and let me know?

[ale-cristofori]

the headers with the long tokens will be replaced by a an opaque string that will be returned by the callback, as response data. The response will land on a dedicated html page that will fire a further request to the server exchanging the opaque string with the refresh and access token, to be then saved in the local storage. This will help slim down a bit the size of the headers.

Another thing it is possible to do is to reduce the number of claims in the keycloak token, this can be achieved in the Keycloak admin interface.

If, in a deployed live instance in the future, a certain user belongs to large number of groups and the token becomes big in any case we will have to tell the customer to set NGINX to support headers higher than 4KB in size.

[ale-cristofori]

@taba added the end point for the obscured Token/smaller string this part is DONE.

The remaining part is to adapt the remaining part of OPENID to this new workflow.