Better support lots of groups (was: Consider exposing proxy_buffer_size in Nginx configuration)

[stevendanna]

Response headers from dex can be very large if the user has a large set of LDAP groups being returned. While the auth team is looking at providing solutions to the underlying problems, it may be helpful for some users to have access to the proxy_buffer_size nginx configuration so they can accommodate header information larger than 4k. (Alternatively, we could bump the default size to something we think is reasonable and not make it configurable).

[srenatus]

Thanks for creating this issue. For LDAP, you can limit the returned groups using a group search filter; the same trick isn't available to your when using SAML. So, the issue is more apparent and annoying in the SAML case.

[srenatus]

Alternatively, we could change the protocol between the UI and session-service. The too-big-headers occurr when session-service, after having gotten the id_token (and, if possible, a refresh_token) from Dex will hand it over to the UI by redirecting to it with the id_token in the URL fragment. That redirect header is what can get too large.

Alternatively, it could just redirect with no token in it, and the UI code could first try to get an id_token from some session-service endpoint (or try to do a /session/refresh), and be given the token in the API response. That way, they could be arbitrarily large.

The problems here are:

1. The UI code's auth handling is wonky -- there's no "hold it, we'll get a fresh token first" logic; if a different API request happens first, it'll get a 401, and the UI will send the user back to the login screen
2. The UX with having a giant id_token is largely unknown. It could be sluggish? It's currently sent with any request, so, it'll cause some extra traffic.

[susanev]

this work has been deprioritized, so closing.