Since we switch to use databroker, time in template is now protobuf
timestamp instead of time.Time, that causes it appears in raw form
instead of human-readable format.
Fix this by converting protobuf timestamp to time.Time in template.
There's still a breaking change, though. The time will now appears in
UTC instead of local time.
Fixes#1100
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
Skip group without members, so it saves us time to handle group members,
and reduce the size of groups.
While at it, also querying API with the fields we need.
Fixes#567
* 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
* pkg: add storage package
Which contains storage.Backend interface to initial support for multiple
backend storage.
* pkg/storage: add inmemory storage
* internal/databroker: use storage.Backend interface
Instead of implementing multiple databroker server implementation for
each kind of storage backend, we use only one databroker server
implementation, which is supported multiple storage backends, which
satisfy storage.Backend interface.
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
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.
