[keycloak-dev] next-gen Keycloak proxy

[Bill Burke]

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