im using Keycloak as OIDC Idp. Is there a way to r...
# all-things-deployment
b
im using Keycloak as OIDC Idp. Is there a way to refresh group membership of a user (maybe delete the user daily so that it forces a refresh? ๐Ÿฅด)? assuming that i do not create any groups using the datahub UI or API, the group membership of a user is determined at first login. Wondering how I could keep the user's membership updated as they change appointments and move around in my org... ๐Ÿคจ I do not want to manually edit the membership of each membership in UI, that is very laborious in production. Only for adhoc basis. wondering if i need to write a custom daily script to query user's group membership (via a third party, in-house API) and gen a new version of groupmembership if it changes. Since membership info is kept in CorpUser entity and not CorpGroup entity.
o
b
Well, for now I'll have to write that script I guess๐Ÿ˜…. Feature supported!
b
This understanding is correct- it's been on our backlog to update the GroupMembership aspect every time a user logs in... Just haven't gotten to it.. I'd be happy to advise / review that change @better-orange-49102!
b
My team also haven't decided how we will do it. Because we previously encountered a bug where the jwt token is too big causing the webpage to loop endlessly, we took out the groups info from the token. The fascinating part about the bug was that user could login, datahub could create the groups(as seen in mysql) but the user's browser will keep looping endlessly. Trimming the jwt size eliminates the problem but we lose information.
o
You're not the only one that has been happening to. We really need to figure out a better way to handle that.
b
What's the root cause of that? JS can't handle large cookies in browser? I've not been able to identify why.
Also, a simplistic check during every login would wipe out the existing groups information inside Datahub, (especially the ones created within Datahub, no?)
nod 1
o
Browsers have a hard limit on cookie size. Pac4J saves all of the groups claims that come in from the OIDC source by default and makes the session token cookie huge.
Eric L did a pretty thorough investigation here: https://datahubspace.slack.com/archives/C029A3M079U/p1644940202569599
thank you 1
b
Yeah this is it^. We do need to roll up our sleeves on this one and get to the bottom of it. It's a pretty bad experience overall. I'm wondering if we can tell pac4j to just set a smaller payload cookie
They use a cookie to avoid having to manage server state for this