2:42 a.m.
On 16 March 2017 at 16:05, Bill Burke <bburke(a)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