Use deflate to compress authentication header payload in Dashboard cookie

[nibix]

Description

First shot at a compression-based solution for #1311 . More a RFC on the approach than a final pull request. Covers so far only SAML. OIDC will come when we have the concept straight.

Uses deflate compression to compress the main payload of the Dashboards security cookie when SAML auth is active. This might help with issues in environments where users have big amounts of roles or attributes. Such users can have trouble with logging into Dashboards because the security cookie - which carries this information encoded in a JWT - gets too big.

The deflated value is written into the attribute authHeaderValueCompressed inside the cookie. This allows us to tell new cookies apart from cookies written with an earlier version and to support both.

Issues and Limitations

• Obviously, this only moves the bar at which users might get issues.
• By default, dashboards (and the underlying Hapi) manage the session storage as follows: First, the payload is JSON encoded. Then, the payload is encrypted using Iron encryption and base64 encoded. As the deflate output is binary, we need to encode it to base64 in order to properly represent it in JSON. However, this again blows the payload size up a bit which we just compressed before.
• We still need some example payloads to verify the actual effectiveness of this change.

Category

• Bug fix

Why these changes are required?

Allow users with many roles to authenticate with SAML in Dashboards.

What is the old behavior before changes and new behavior after changes?

Such users could not log in into Dashboards.

Issues Resolved

• [RFC] Improved session management #1311
• Set-Cookie header is ignored due to size limit after the Kibana upgrade to 1.10.1 #516

Testing

• Unit testing
• We still need some sample payloads to verify the effectiveness

Check List

• New functionality includes testing
• New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[cwperks]

@nibix this approach looks promising to me. The example of compressing 14kb -> a little over 4kb sounds like it will relieve some of the pain for user's but not solve all cases.

[stephen-crawford]

Hi @nibix, thank you for writing up this draft. As Craig mentioned this looks like a good start. Is there anything that will need to be done in order to checksum/verify the final cookie against the original? Is it possible to do this without having to transfer the uncompressed cookie for comparison? Or do we simply need to assume that the cookie is correct when it arrives? I don't know if this is a concern with this type of implementation but wanted to ask.

[peternied]

Nice, much closer to our end state! I think we might be able to have the auth header span multiple cookies to provide headroom.

While in draft, I would recommend documenting / stubbing out what kinds of scenario tests we should create.

[peternied]

What would you think about inserting a cookie splitter that could provide head room of these requests?

[nibix]

Would be an option, but we cannot do this inside this code. From this code, we can only write exactly one cookie.

[nibix]

Or do we simply need to assume that the cookie is correct when it arrives?

I believe we should just assume that the cookie is correct when it is arrives. Additionally, the deflate compression algorithm already stores a checksum at the end of the data, thus we already have a certain validation.

Additionally, of course, the JWT also has a signature which would become invalid when something goes wrong in the round trip.

[nibix]

Superseded by #1352