* authenticate: validate origin of signout
- add a debug task to kill envoy
- improve various function docs
- userinfo: return "error" page if user is logged out without redirect uri set
- remove front channel logout. There's little difference between it, and the signout function.
Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com>
- gofumpt everything
- fix TLS MinVersion to be at least 1.2
- add octal syntax
- remove newlines
- fix potential decompression bomb in ecjson
- remove implicit memory aliasing in for loops.
Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com>
* authenticate: remove cookie options
* authenticate: remove shared key field
* authenticate: remove shared cipher property
* authenticate: move properties to separate state struct
* proxy: allow local state to be updated on configuration changes
* fix test
* return new connection
* use warn, collapse to single line
* address concerns, fix tests
In #1088, OptionsUpdater was removed, but current code still mention it.
This commit updates all comments which still mention about that
interface (authorize is exlcuded, and will be updated in #1206).
In #1030, the fix was done without aware of the context that traefik
forward auth mode did allow request without the "?uri=". Previosuly,
this is done in proxy, and by converting the forward auth request to
actual request. The fix is #1030 prevent this conversion, to makre
authorize service aware of which is forward auth request.
But that causes traefik forward auth without "?uri" stop working. Fixing
it by making the authorize service also honor the forwarded uri header,
too.
Fixes#1096
Currently, authorize service does handle unauthenticated request in
forward auth mode, and return status 401.
But proxy has not handled the response yet, and always returns 403 for
both unauthenticated and unauthorized request. That breaks session
handling in forward auth mode. That said, if user was signed out, or for
any reason, authorize service return 401 status, proxy does not redirect
user to re-signin, but always return 403.
To fix it, proxy is changed to handle envoy check response in more
details, to distinguish between 401 and 403 status.
Thanks to @simbaja for rasing the problem and come up with original fix.
Fixes#1014Fixes#858
With Traefik in forward auth mode, when accessing:
https://example.com/foo
traefik will send a request like this to proxy:
https://pomerium?uri=https://example.com
The path "/foo" is passed to proxy via "X-Forwarded-Uri" instead of via
query parameters. When proxy redirects request to authenticate, it only
set the "pomerirum_redirect_url" to the value of "uri".
So after authentication success, the user will be redirected to example.com
instead of example.com/foo. If "X-Forwarded-Uri" is present, we should
add it to redirect uri, so the user will be redirected to right place.
When proxy receives forward auth request, it should forward the request
as-is to authorize for verification. Currently, it composes the check
request with actual path, then send the request to authorize service.
It makes the request works accidently, because the composed check
request will satisfy the policy un-intentionally. Example, for forward
auth request:
http://pomerium/?uri=https://httpbin.localhost.pomerium.io
the composed request will look like:
&envoy_service_auth_v2.AttributeContext_HttpRequest{
Method: "GET",
Headers: map[string]string{},
Path: "",
Host: "httpbin.localhost.pomerium.io",
Scheme: "https",
}
This check request has at least two problems.
First, it will make authorize.handleForwardAuth always returns false,
even though this is a real forward auth request. Because the "Host"
field in check request is not the forward auth host, which is "pomerium"
in this case.
Second, it will accidently matches rule like:
policy:
- from: https://httpbin.localhost.pomerium.io
to: https://httpbin
allowed_domains:
- pomerium.io
If the rule contains other conditions, like "prefix", or "regex":
policy:
- from: https://httpbin.localhost.pomerium.io
prefix: /headers
to: https://httpbin
allowed_domains:
- pomerium.io
Then the rule will never be triggered, because the "/headers" path can
be passed in request via "X-Forwarded-Uri" (traefik), instead of
directly from the path (nginx).
To fix this, we just pass the forward auth request as-is to authorize.
Fixes#873