Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Is your feature request related to a problem? Please describe.
A user tries to sign in into an application, but they are not authorized to access it because not in the only authorized group.
The admin adds them to the group for the user to be able to access the application.
The user tries to access the application but access is still refused.
Describe the solution you'd like
Authorization of groups (since the others are not mutable) should be refreshed after some time, if possible configurable.
Describe alternatives you've considered
Sign out from another application the user has access to in order to sign in again and refresh groups.
Explain any additional use-cases
Changing access right of a user by removing them from a group.
Just to confirm -- as this may have chanced since the initial issue was file -- group membership (or lack there of) will be updated along with the session for most identity providers. The session expiration is usually set by the upstream identity provider (usually ~1-3 hours) and pomerium tries to renew the token at roughly half that (
It's a tradeoff between accidentally DDOS'ing ourselves and the identity provider (which have strict query limits ) and making sure the user is not carrying stale credentials.
@desimone Thanks for the explanation.
When I wrote this issue, I was (maybe incorrectly) expecting that adding a user to a group would be taken into account without any delay, while it seemed perfectly normal that removing a user for a group would take some time to be taken into account.
I'm not sure what is possible to improve the user experience though… I worry that if one of my user tells me that he needs to access an app and that I add him to a group, then he has to wait at most 15mn and be unhappy :)
It's not an ideal situation. I'd like to have a "recheck my access" button, especially on the unauthorized access user page.
I looked (indeed, it's still commented out in the code) at adding a refresh endpoint which would force a user/group session update. But without a backoff interval / rate limiting, a user ( either accidentally or maliciously) could DOS the identity provider and cause you to unexpectedly hit your IdP's QPS limits.
The problem is tracking user state (in this case, how much has bob@company been hitting that refresh button) is challenging because we don't have a backend datastore that can be queried across potentially many pomerium instances. State is currently tracked in the user session.
For the purpose of access, If the user clears their session, no big deal, we require a re-authentication.
A option could be to allow refreshing for users that have been logged in for at least some interval (say ~5 minutes) and also track last refresh timestamp in the session.
So basically ...