Cookie “miq_oidc_access_token” is invalid because its size is too big. Max size is 4096 B.

[uejo]

1. Describe the issue you are having and what you expected to happen.
   When a user is probably in too much ldap groups and tries to log in via OIDC, it doesn't work when the token is too long.
   Expectation: The user can log in regardless of the length of the token.

2. Describe the steps to reproduce, including any log snippets and stack traces that will help diagnose.
   Login at the appliance in the "Service UI" with OIDC using Keycloak (v25). If the user is in too much ldap groups, he doesn't get logged in, but stays at the login page.
   In Firefox browser under Developer Tools - Console it shows:

Indeed the miq_oidc_access_token is bigger then the 4096 Bytes.

3. Describe your environment, including
   Version: radjabov-pre.20240404134108_e4479a1
   Environment
   For ManageIQ: VMware appliance

[Fryguy]

Are you seeing the error on the browser side? Or is that just to demonstrate the size?

Do you see any errors in journald from the httpd process?

[uejo]

Yes its only in the browser. The cookie is too long, hence the browser is rejecting it, gives an error on the client side, like the screenshot i posted. That's why the backend doesn't ever receive the authentication request -> no errors in the logs

[Fryguy]

When a user is probably in too much ldap groups

@uejo Can you give more details on the content of the cookie? I'm trying to replicate the issue - about how many groups are we talking about?

[uejo]

Hello, we are talking about around 50 long named ldap groups. But i think the main problem here is not that the user is in too many ldap groups, its the way the cookie is used/handled. It doesn't matter if its the groups, it could also be the roles, or long "scope" "name" field which lead to a bigger access token, which lead to a bigger cookie. As stated in the RFC https://www.rfc-editor.org/rfc/rfc6265.html#section-6.1 browser should support at least 4096 bytes and as far as i understand this, the application has to take care if the cookie exceeds this value, since browsers support usually around 4097 bytes. (eg FF and edge )

Unfortunately i don't really understand the code base, but it seems you only set the cookie for the Service UI here:
https://github.com/ManageIQ/manageiq-appliance/blob/e3f79aa81982590f2878f089b738d3b6de06bfeb/TEMPLATE/etc/httpd/conf.d/manageiq-external-auth-openidc.conf.erb#L33

and not for the Classic UI. I think the cookie there handled by the httpd OIDC plugin. The login works in the Classic UI by the way.

[Fryguy]

That's correct - that particular cookie isn't handled by our application at all, but instead by mod_auth_openidc for the /ui/service path. On the classic UI side you don't see the problem because we don't store it in a cookie, but instead it's passed along to the Rails session, which is server side.

I did a little research, and did find this: https://github.com/OpenIDC/mod_auth_openidc/wiki/Cookies#cookie-exceeds-size-limit. Seems there's a way to configure chunked cookies, but I can't find that setting just yet.

[Fryguy]

Actually I found it here: https://github.com/OpenIDC/mod_auth_openidc/blob/master/auth_openidc.conf#L539-L546

However, what's strange is it says if it's not set, it defaults to 4000 bytes per chunk, so based on that I don't understand why you are seeing this error. 😕

[uejo]

You mean probably https://github.com/OpenIDC/mod_auth_openidc/blob/9c0909af71eb52283f4d3797e55d1efef64966f2/auth_openidc.conf#L539-L546.
But if not defined the default value is 4000. So it is even set by default, but that doesn't matter since the cookie is explicitly set by the code i linked above. So i suppose it is not managed and not get junked by the OIDC plugin.

[Fryguy]

Oh I see what you're saying - your theory is that since we call Set-Cookie explicitly, it's ignoring any cookie handling by mod_auth_openidc? If so, that would explain it.

[Fryguy]

cc @jrafanie @kbrock

[Fryguy]

@uejo You should be able to manipulate the conf file as you need on your appliance until you can get it working - if you can find a way to change the cookie handling from an explicit set-cookie to using OIDC, please feel free to make a pull request.

[uejo]

I found a workaround, at least for our problem:

In the documentation: https://www.manageiq.org/docs/reference/latest/auth/openid_connect.html#oidc-assertions
it says for the "The following Group Membership mapper must be manually created":
ID token: on access token: on and to userinfo: off
i changed that in our keycloak to ID token: on, access token: off and to userinfo: on and for the api the "Add to token introspection": on
Now the ldap groups are not in the cookie anymore which means the size is below 4k byte now.
I also seems that everything else for the classic UI and Service UI is working as expected.

[Fryguy]

Can you verify that group switching still works as expected in the service UI and classic UI? (Group switcher is under the user icon in the upper-right, I believe)

[uejo]

Yes, looks good to me.

[uejo]

It seems the "userinfo: on" doesn't do anything, it can be left to off.

[Fryguy]

@uejo This sounds like a great change to the documentation - can you make a PR in https://github.com/ManageIQ/manageiq-documentation/blob/master/auth/openid_connect.md ? Thank you!

[uejo]

Here you go! As mentioned above this solves our problem, but not really the underlying issue.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.