Re: [keycloak-dev] next-gen Keycloak proxy

On 3/17/17 5:01 AM, Stian Thorgersen wrote: 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(a)redhat.com&gt; 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). I'm worried about cookie size constraints. I'll do some measurements. This issue is orthogonal to the other issues though I think.

> > > 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. Client nodes currently register themselves with auth server on demand so that they can receive revocation and backchannel logout events. The auth server sends a message to each and every node when these events happen. A proxy that has access to UserSession cache doesn't have to do any of these things. This is the "simpler" and "more efficient" argument. I forgot the "more robust" argument I had.

> > 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. Configuring a proxy in the admin console is a good thing right? If that is an assumption, then the proxy needs to receive realm invalidation events so that it can refresh the client view (config settings, mappers, etc.).

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. realm info doesn't hit the db much, but user store will be hit. Hmm...didn't think of the user store hit. Something like LDAP would be hit by the auth server and each proxy for each login session. That's a downer... If a proxy could proxy all apps, then maybe there is a way to maintain sticky sessions between the auth server and the proxy so they shared the same node/cache for the same session. Still a huge negative though as things just got a lot more complex.

Maybe we could just hook up the proxy to the realm store and realm cache? I prefer this idea as then proxy setup isn't much different than auth server setup. And all the configuration sync logic is already in place as the proxy would receive realm invalidation events. Bill