Handle too large cookies gracefully

[thoro]

Cookies in browsers are limited to 4096 bytes.

I have had the issue with SAML Authentication that my auth cookie was > 6000 bytes.

The issue was that I passed all assigned groups to kibana via the Role attribute (> 50 groups), limiting the groups resolved the issue for me.

But it would be nice for kibana to actually be aware of the 4096 bytes cookie, and figure out a way how to limit it's size.

Maybe just add the actual backend_groups to the cookie instead of all groups?

Similar to #374

[qube222pl]

We have the same issue with OPENID.
We are using DEX as OpenID Connect provider which is connected to LDAP.
All groups in which user belong to in LDAP are mapped to roles. If user belong to a large number of groups cookie size is larger than 4096.

[dinusX]

Hi,

It's totally possible for a user to belong to many groups/roles and get mapped to multiple security roles in ES. I assume the problem is when the number of groups is very high.
I don't think it's possible to select on ES which groups to be stored in cookie and which not.

I would suggest filtering the groups using some rules on the SAML IDP side, in the attribute mapping configuration.

I assume that IDP used for OpenId should also have some way to map attributes that are sent to Elasticsearch application.

[kfox1111]

We are interested in OpenDistro for ElasticSearch specifically for multitenant support. As we have a lot of tenants, and users can be a member of multiple tenants, we do need to relay this information to elasticsearch so it can select on it. Filtering the roles out won't work because it filters out the exact needed info. Support for splitting the token into multiple cookies and/or using a persistent store for storing the tokens and returning a cookie with a pointer to the jwt in the perstient store would resolve this better. Seems like we could use elasticsearch itself to do that? store the jwt in elastticsearch, set a ttl on the doc equal to the expiry time of the jwt, and return a pointer to it for the cookie?

[debjanibnrj]

Hi, security authentication cookie size is currently limited by the browser. Both RFC 2109 and RFC 6265 state that user agents should support cookies of at least 4096 bytes. For many browsers this is also the maximum size of the cookie.

We are working on solution for this use case. Meanwhile a workaround for JWT/SAML is to limit the number of roles and sttributes being send from the IdP.

[sdwerwed]

I have the same issue using Azure AD, after sending request to https://<opensearch-dashboards>/auth/openid/login?code=xxx?state=xxx?session_state=xxx in the response headers I see set-cookie: security_authentication=<6kbsize> which is higher than the limit of around 4kb, this results on infinite redirects. For a workaround, I removed group claims in App Registrations and used role-based access which reduced the size of the cookies.

For now, would make sense to send a warning if the cookie length exceeds 4KB to make admins aware of a problem.

@debjanibnrj Is there any update regarding this bug?
What about storing such big data to HTLM5 key-value storage or splitting the cookies?

[lgazo]

I came across this issue as well and it had two sources of the problem. First one was that if the client in KeyCloak had "full scope" allowed, the cookie was too large anyway. Then some of the users have many roles mapped into the JWT token which caused the cookie to grow beyond the 4k limit again. This is a road block which we would be able to workaround only by changing our business logic. The workaround would be having a grouping role which when encountered would be expanded to required list of roles in Kibana. It imposes a significant rework and unnecessarily conditional logic.

I also thought of an alternative where the roles would not be mapped to access token or ID token, but then Kibana is not able to retrieve the information from UserInfo endpoint unfortunately. If there would be a support to retrieve the roles from UserInfo endpoint and cache it on Kibana's side, it is an elegant solution for large list of roles (at least for us). But I could not find any documented way how to configure it that way.

I also liked the idea of @sdwerwed splitting the cookie if such information has to be stored in it. But as I understood Kibana keeps the state in the session on the backend anyway, so why does the cookie has to contain such large information?

Would you consider using UserInfo endpoint as a viable solution for the problem?

[aryannegi313]

Faced a similar issue with OpenID authentication. The cookie size was greater than 4kb so the kibana UI authentication was not happening and was getting multiple redirection error.

I see this has been marked as an enhancement is there any update on this.
On which version will this problem be fixed?

[OldSchooled]

@dinusX , @davidlago, @debjanibnrj, @zengyan-amazon

This is such a pressing issue for us that the organization I work for is interested in attempting to resolve this problem ourselves by contributing to this repository. Would you be able to shortcut our effort by helping us identify the code in question and possibly sharing any general ideas for a solution you may have come up with?

Also, I'd like to mirror the question from @lgazo. If Kibana keeps the state in the session on the backend, why do we need to store this information in the cookie?

[domruf]

My first idea would also be to store all the user information on the server side and only use a short session key in the cookie.
But if that is not possible, maybe it is possible to store the information in HTML5 localStorage instead of cookies?!

[stephen-crawford]

[Triage] This issue is being addressed as part of the campaign to handle large cookies.

[DarshitChanpura]

Tagging it as v2.7.0 since opensearch-project/security-dashboards-plugin#1402 was merged is ready to be shipped with this release.

[DarshitChanpura]

Closing this as it will be shipped in v2.7.0