Currently, when option changes, whether the option is good or bad, we
always store new policy evaluator.
When options is bad, policy evaluator will be nil. That can lead to panic
at runtime if a Check request were called after Authorize.OnConfigChange
ran with bad option.
We already have an error message if new policy evaluator fails, so we
must only update it on success only.
* authorize: derive check response message from reply message
While at it, add tests for ok response related functions.
* authorize: more test case for ok reply with k8s svc
* store directory groups separate from directory users
* fix group lookup, azure display name
* remove fields restriction
* fix test
* also support email
* use Email as name for google'
* remove changed file
* show groups on dashboard
* fix test
* re-add accidentally removed code
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, with impersonated request, the real user email/group still
has effects.
Example:
data.route_policies as [{
"source": "example.com",
"allowed_users": ["x@example.com"]
}] with
input.databroker_data as {
"session": {
"user_id": "user1"
},
"user": {
"email": "x@example.com"
}
} with
input.http as { "url": "http://example.com" } with
input.session as { "id": "session1", "impersonate_email": "y@example.com" }
Here user "x@example.com" is allowed, but was impersonated as
"y@example.com". As the rules indicated, the request must be denied,
because it only allows "x@example.com", not "y@example.com". The current
bug causes the request is still allowed.
To fix it, when evaluates rules for allowed email/group/domain, we must checking
that the impersonate email/groups is not set/empty.
Fixes#1091
* add google cloud serverless support
* force ipv4 for google cloud serverless
* disable long line linting
* fix destination hostname
* add test
* add support for service accounts
* fix utc time in test
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
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.
