Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

authenticate: allow manual refresh #73

Closed
victornoel opened this issue Mar 27, 2019 · 3 comments · Fixed by #123
Closed

authenticate: allow manual refresh #73

victornoel opened this issue Mar 27, 2019 · 3 comments · Fixed by #123
Labels
Milestone

Comments

@victornoel
Copy link

@victornoel victornoel commented Mar 27, 2019

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.

@desimone desimone added this to the v0.0.4 milestone Mar 28, 2019
@desimone

This comment has been minimized.

Copy link
Member

@desimone desimone commented Apr 25, 2019

@victornoel

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 (COOKIE_REFRESH defaults to 30 minutes). That said, you could shorten the refresh period and depending on how many users you are supporting it could be fine.

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 desimone removed this from the v0.0.4 milestone Apr 25, 2019
@victornoel

This comment has been minimized.

Copy link
Author

@victornoel victornoel commented May 6, 2019

@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 see from your explanation that both are handled in the same way.

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 :)

@desimone

This comment has been minimized.

Copy link
Member

@desimone desimone commented May 7, 2019

@victornoel

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.
However, tracking state of how often a user has hit refresh gets tricky because if they clear their session, we no longer know the last time they hit refresh and we can't rate limit effectively.

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 ...

IF (user-state is at least X minutes old) AND (user-state.last-refresh is null OR user-state.last-refresh >= X minutes ago)
ALLOW REFRESH
ELSE
DENY REFRESH

Could work?

@desimone desimone changed the title Authorization refresh, for example for groups authenticate: allow manual refresh May 17, 2019
@desimone desimone added this to the v0.0.5 milestone May 17, 2019
desimone added a commit to desimone/pomerium that referenced this issue May 26, 2019
proxy: Add user dashboard. [pomeriumGH-123]
proxy/authenticate: Add manual refresh of their session. [pomeriumGH-73]
authorize: Add administrator (super user) account support. [pomeriumGH-110]
internal/policy: Allow administrators to impersonate other users. [pomeriumGH-110]
desimone added a commit that referenced this issue May 26, 2019
proxy: Add user dashboard. [GH-123]
proxy/authenticate: Add manual refresh of their session. [GH-73]
authorize: Add administrator (super user) account support. [GH-110]
internal/policy: Allow administrators to impersonate other users. [GH-110]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.