When user signin to 2 sites "a.example.com" and "b.example.com", we're
using the same session for user when accessing those sites. When user
singout from "a.example.com", that session is marked as deleted, thus
user now can not access "b.example.com" nor re-signin to get new access.
User must wait the cookie is expired, or delete the cookie manually to
re-signin to "b.example.com".
This is also affected if user signout from authenticate service
dashboard page directly.
To fix this, we will clear the session state if the session was deleted,
authorize service will return unauthorized, so the user will be
redirected to re-authenticate.
Updates #1014
Updates #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
Some ingress like traefik set the X-Forwarded-Uri header instead
of passing the actual path in request, we should hornor and use
that header in forward auth mode.
While at it, refactoring the handleForwardAuth to return earlier instead
of nested condition, and add more tests to cover all cases.
In 35af5c0b91, the check for multiple
cache servers in NotifyJoin is made to be done in a goroutine. That can
lead to a data race, because the memberlist can be changed at the time
the goroutine was run. go warns about this race when test memberlist was
run with "-race".
To fix this, we pass the nil check as argument to goroutine.
* depedency: bump opa v0.21.0
Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com>
* config: error if groups are used without service account
Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com>
"ver" field is not specified by RFC 7519, so in practice, most providers
return it as string, but okta returns it as number, which cause okta
authenticate broken.
To fix it, we handle "ver" field more generally, to allow both string and
number in json payload.
