[keycloak-dev] next-gen Keycloak proxy

[Stian Thorgersen]

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
> sessions.
>
> 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
> proxy.
> 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.
>
> Bill
>
> Bill
>