[keycloak-dev] next-gen Keycloak proxy
sthorger at redhat.com
Fri Mar 17 03:42:08 EDT 2017
On 16 March 2017 at 16:05, Bill Burke <bburke at redhat.com> wrote:
> On 3/16/17 6:19 AM, Stian Thorgersen wrote:
> The Keycloak proxy shouldn't be tied directly to the database or caches.
> It should ideally be stateless and ideally there's no need for sticky
> Please stop making broad blanket statements and back up your reponse
> otherwise I'm just going to ignore you.
> If the proxy implements pure OIDC it has to minimally store refresh token
> and access token. Plus I foresee us wanting to provide more complex proxy
> features which will require storing more an more state. So, the proxy
> needs sessions which means many users will want this to be fault tolerant,
> which means that the proxy will require distributed sessions.
> It should be capable of running collocated with the Keycloak Server for
> simplicity, but also should be possible to run in separate process. If it's
> done as an additional subsystem that allows easily configuring a Keycloak
> server to be IdP, IdP+Proxy or just Proxy.
> Further, it should leverage OpenID Connect rather than us coming up with a
> new separate protocol.
> My reasoning behind this is simple:
> * Please let's not invent another security protocol! That's a lot of work
> and a whole new vulnerability vector to deal with.
> * There will be tons more requests to a proxy than there are to the
> server. Latency overhead will also be much more important.
> It wouldn't be a brand new protocol, just an optimized subset of OIDC.
> For example, you wouldn't have to do a code to token request nor would you
> have to execute refresh token requests. It would also make things like
> revocation and backchannel logout much easier, nicer, more efficient, and
> more robust.
> I Just see huge advantages with this approach: simpler provisioning,
> simpler configuration, a real nice user experience overall, and possibly
> some optimizations. What looking for is disadvantages to this approach
> which I currently see are:
> 1) Larger memory footprint
> 2) More database connections, although these connections should become
> idle after boot.
> 3) Possible extra distributed session replication as the
> User/ClientSession needs to be visible on both the auth server and the
> 4) Possible headache of too many nodes in a cluster, although a proxy is
> supposed to be able to handle proxing multiple apps and multiple instances
> of that app.
> What's good about 2-4 is that we can bench this stuff and learn the
> limits. From what Stuart Douglas tells me is that Undertow is really
> really competitive with just about every web server (Apache, Jetty, etc.)
> (usually better). Where Java in general is not as good as its
> competitors is in SSL/TLS. I don't know how much worse it is.
More information about the keycloak-dev