Currently, we're doing "sync" in databroker server. If we're going to
support multiple databroker servers instance, this mechanism won't work.
This commit moves the "sync" to storage backend, by adding new Watch
method. The Watch method will return a channel for the caller. Everytime
something happens inside the storage, we notify the caller by sending a
message to this channel.
* config,docs: add databroker storage backend configuration
* cache: allow configuring which backend storage to use
Currently supported types are "memory", "redis".
* 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
* internal/controlplane: using envoy strip host port matching
With envoy 1.15.0 release, strip host port matching setting allows
incoming request with Host "example:443" will match again route with
domains match set to "example".
Not that this is not standard HTTP behavior, but it's more convenient
for users.
Fixes#959
* docs/docs: add note about enable envoy strip host port matching
Storing server version when creating new server. After then, we can
retrieve the version from backend when server restart.
With storage backend which supports persistent, the server version
won't change after restarting.
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.
"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.
authenticate: revoke current session oauth token before sign out
After #926, we don't revoke access token before sign out anymore. It
causes sign out can not work, because right after user click on sign out
button, we redirect user to idp provider authenticate page with a valid
access token, so user is logged in immediately again.
To fix it, just revoke the access token before sign out.
