Force a specific account to re-login by revoking their vouch cookie and access token

[Choo57]

As far as I understand, best practice at the moment is to change the vouch.jwt.secret to invalidate all tokens for the "firing an employee" case, but wanted to ask if there are any enhancements regarding this.

This would force everyone else to login again which is not the ideal scenario most of the time.

Do you think a "blacklist" which is checked at /validate can be used here where the username can be added temporarily? So in cases where a long cookie age "e.g. 1 day" is used, vouch admin can add the username to the blacklist and bounce vouch proxy to prevent the use of any cookies obtained earlier without affecting any other users.

[bnfinet]

@Choo57 how many users are you managing? How frequently are you revoking access? Is this a problem you have or is this theoretical?

I'm a bit reluctant to give VP more authority, at least in such an incremental fashion. If there were a full blown project to support RBAC or ACL in VP that might make some sense (after appropriate discussion). At this point the access control is intentionally light and clear with "is anyone who logs in at the IdP allowed?" or "are you on the list?".

You can probably achieve this feature already by using some nginx-fu to evaluate the X-Vouch-User http header returned by VP.
https://stackoverflow.com/questions/18970620/nginx-reject-request-if-header-is-not-present-or-wrong

FYI - There has been some discussion of moving to allow_list and deny_list or just allow and deny.

[Choo57]

@bnfinet many thanks for the fast response really appreciate it. This is a real issue for us at the moment, not a theoretical one, but I would say it does not happen very frequently (e.g. only once every 2-3 months). But when it happens, we usually need to be able to stop the user from accessing the services immediately.

In our case each nginx services multiple independent companies who have a number of users, so changing the vouch secret and bouncing the service interrupts everyone connected.

Writing the X-Vouch-User header into the nginx conf file to restrict user access looks like a nice workaround, but it will also require an nginx restart I think which will interrupt every other customer on that nginx as well. We have websocket connections so every user will need to refresh their pages to get their websockets reconnected, whereas updating a "deny list" on Vouch's config.yml will only require a vouchproxy restart which will probably go unnoticed by customers.

I also considered keeping the IdP session long (e.g. 1 day) and set the vouch cookie age to 10 minutes for example, so once the username on IdP is deactivated, the user would only have a valid cookie for the next 10 minutes at most, but could not find a way to refresh vouch cookie in the browser silently without a page refresh..