[keycloak-dev] next-gen Keycloak proxy

[Stian Thorgersen]

In summary I'm more open towards your approach, but still have some
concerns around it. More inline.

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.
>

Can't the tokens just be stored in a cookie? That would make it fully
stateless and no need for sticky sessions.

I guess it comes down to what is more costly refresh token requests or
having a distributed "session" cache (which we already have).


>
>
> 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 like removing the code to token request and refresh token requests.
However, doesn't the revocation and backchannel logout mechanism have to be
made simpler and more robust for "external apps" as well? Wouldn't it be
better to solve this problem in general and make it available to external
apps and not just our "embedded" proxy.


>
>  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.
>

I would think it would make it even harder to scale to really big loads.
There will already be limits on a Keycloak cluster due to invalidation
messages and even more so the sessions. If we add even more nodes and load
to the same cluster that just makes the matter even worse. There's also
significantly more requests to applications than there is for KC server.
That's why it seems safer to keep it separate.

It depends on what and how much of the db + cache we're talking about. Is
it just user sessions then that can probably be handled with distributed
sessions.


>
> 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.
>

Undertow sure. I don't think that's where there the limitation is going to
be. Rather the limitation would most likely be in the Infinispan cluster.


>
> Bill
>
> Bill
>