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
Sign out link doesn't work on authenticate_service_url #867
Comments
Are you hitting this URL directly (via curl or some other type of request) or via the sign-out button in This is what I am seeing |
Ah I see, I was hitting the |
With actual routes, the proxy redirect it to authenticate signout URL, with a generated signed URL. While if we're on the authenticate page, we hit the authenticate signout URL directly without generated signed URL. |
I ran into this as well (see #857). I suggested moving the auth endpoints so that the signout would work no matter which service you were interacting with. I might be doing something wrong, but in forward auth mode with Traefik, the "./pomerium" subrouter isn't available from other services, so it's useful to make sure it works on the authenticate url. |
@simbaja maybe another solution is auto generated a signed signout URL if we're on authenticate url. But another question: is it ok to signout directly from authenticate service at all, because in this case, we don't clear session in proxy cc @desimone @travisgroth ? |
Instead of generating the signed signout url from authenticate, moving the auth endpoints (which are only really called by the proxy anyway) to /.pomerium/auth instead of /.pomerium resolves the issue with a minimum of changes (I think like 10 lines of code, mainly updating some string values). So, /.pomerium/sign_out would always be proxy signout, /.pomerium/auth/sign_out would be the direct authentication url... the proxy sign_out already generates a signed url, so it then works everywhere. I'm new to Go/Pomerium, so I apologize if I'm missing something obvious. I can certainly create a pull request for this based on the fixes I did in my fork, but not sure if I caught everything due to my unfamiliarity with the project/language. |
Cookies are stored per-domain, so signing out must be done from the proxy domain. (ie sign out at There is work being done to convert the cookie to a session id, with the session being stored separately. If that were the case it would be possible to delete the session from the backend and then it wouldn't matter where the sign out occurred. (you'd end up with a cookie tied to a session that no longer exists) |
Thanks for confirmation. Though in my PR above, signout directly from authenticate service also works, mean user must re-signin to get new valid session. So new question is should we change the signout endpoint only, or move all authenticate endpoint like @simbaja suggested? |
I'm probably doing something wrong as well. What I encountered is that in Traefik forward auth mode, from the individual apps, the /.pomerium router isn't available. So, I'm not able to use the app.example.com/.pomerium/sign_out link. Instead, the only thing that seems to be available under this use case (again, probably doing something wrong), is the authenticate.example.com/.popmerium/sign_out link. |
I think the main point here, base on @calebdoxsey comment, is we must do the logout from proxy, not directly from authenticate. So whether or not you change the authenticate endpoints, you still must do it via proxy first. So IHMO, the proper fix is changing the proxy signout url or the authenticate signout url. I'm not too familiar with traefik, but is it possible to the forward all request ends with |
Yep, having a router conflict where some proxy methods work on the authenticate url and others don't seems odd (like /.pomerium/ goes to proxy, but /.pomerium/sign_out (which is linked from proxy "/") doesn't because the router chooses the authentication router endpoint instead of the proxy router endpoint. If we move the auth to be in its own namespace, everything works regardless of what url you're using. Alternatively, if you eliminate the routing conflicts by renaming the proxy end point names, that could also work.
Not that I can see. In forward auth mode, Traefik is just passing the request to be verified and then the proxy is not involved further (it goes directly to the backend after authentication as long as verify continues to return a response of 200). This also causes issues with how the audiences are generated in this mode (per @calebdoxsey it's per app), but this also didn't work with this setup, so I modified the audience to be the IDP Client ID for now to make my scenario fully operational. But, that's a different issue, so I don't want to go too far down the rabbit hole there. |
FWIW, the BeyondCorp implementation from Hooli.xyz does logout on the authenticate url, and it would log out all logins in all routes. I can image this would be useful for at least two cases: 1) for IT/tech support to have a reliable way to ask the user to "turn it off and on again", 2) to immediately log a terminated employee out everywhere. Session id in the cookie sounds like a good solution, but it looks like Pomerium will need to depend on a HA cache if multiple instances of Pomerium is running (i.e. enterprise use case). |
Would be nice to be able to logout on the authenticate url. Its not that easy to reference k8s service ( promerium-proxy ) from namespace ( myapp ) in ingress object ( myapp ) without using external service workaround or using CRDs ( ingress controller specific ) with Traefik Ingress Controller to proxy |
This is fixed after #926, feel free to re-open if you still face this issue. |
What happened?
Access /.pomerium/sign_out and get error:
Bad Request: internal/urlutil: malformed unix timestamp field
What did you expect to happen?
Sign out the user and ask to login again
How'd it happen?
Access /.pomerium/sign_out
What's your environment like?
pomerium --version
or/ping
endpoint):pomerium/0.9.0 (+https://wwww.pomerium.io; 914b952; go1.14.3)
In docker
What's your config.yaml?
NA
What did you see in the logs?
NA
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: