* Can/Should one Keycloak Proxy virtual host and proxy multiple apps in same instance? One thing stopping this is SSL. If Keycloak Proxy is handling SSL, then there is no possibility of virtual hosting. If the load balancer is handling SSL, then this is a possibility.

* Keycloak Proxy currently needs an HttpSession as it stores authentication information (JWS access token and Refresh Token) there so it can forward it to the application. We'd have to either shrink needed information so it could be stored in a cookie, or replication sessions. THe latter of which would have the same issues with cross DC.

From a corporate standpoint we're already Red Hat partners at multiple

So nice of you to hijack the thread to promote your own product. Not very professional. Its a bit hypocritical of me to say this as I've done it myself in the past and received a lot of crap for it. Now that its being done to my project I can see why people get upset over it. This isn't the first time you've done this. If you do it again, we'll remove you from the list. I really don't give a shit if you're a partner or not.

Keycloak Proxy was written a few years ago to secure apps that can't use an adapter provided by us. While Keycloak Proxy works (? mostly?) ,we've been pushing people to Apache + mod-auth-mellon or mod-auth-openidc for non-Java apps. I predict that relying on Apache to proxy and secure apps that can't use our adapters is going to quickly become an issue for us. We already have a need to write extensions to mod-auth-*, specifically to support Pedro's Authz work (which is really nice BTW!). We could also do tighter integration to make the configuration experience more user-friendly. The problem is we have zero expertise in this area and none of us are C/C++ developers (I haven't coded in C/C++ since 1999 when I was at Iona). This brings me to what would be the next generation of the Keycloak Proxy. The first thing I'd like to improve is that configuration would happen within the admin console. This configuration could be made much simpler as whatever protocol configuration that would be needed could be hard-coded and pre-configured. Mappers would focus on mapping values to HTTP headers. Beyond configuration, things become more interesting and complex and their are multiple factors in deciding the authentication protocol, proxy design, and provisioning: * Can/Should one Keycloak Proxy virtual host and proxy multiple apps in same instance? One thing stopping this is SSL. If Keycloak Proxy is handling SSL, then there is no possibility of virtual hosting. If the load balancer is handling SSL, then this is a possibility. * Keycloak Proxy currently needs an HttpSession as it stores authentication information (JWS access token and Refresh Token) there so it can forward it to the application. We'd have to either shrink needed information so it could be stored in a cookie, or replication sessions. THe latter of which would have the same issues with cross DC. * Should we collocate Keycloak proxy with Keycloak runtime? That is, should Keycloak Proxy have direct access to UserSession, CLientSession, and other model interfaces? The benefits of this are that you could have a really optimized auth protocol, you'd still have to bounce the browser to set up cookies directly, but everything else could be handled through the ClientSession object and there would be no need to generate or store tokens.

* Collocation is even nicer if virtual hosting could be done and there would be no configuration needed for the proxy. It would just be configured as a Keycloak instance and pull which apps in would need to proxy from the database. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 3/14/17 9:20 AM, Marek Posolda wrote: > On 13/03/17 22:07, Bill Burke wrote: >> Keycloak Proxy was written a few years ago to secure apps that can't use >> an adapter provided by us. While Keycloak Proxy works (? mostly?) >> ,we've been pushing people to Apache + mod-auth-mellon or >> mod-auth-openidc for non-Java apps. I predict that relying on Apache >> to proxy and secure apps that can't use our adapters is going to quickly >> become an issue for us. We already have a need to write extensions to >> mod-auth-*, specifically to support Pedro's Authz work (which is really >> nice BTW!). We could also do tighter integration to make the >> configuration experience more user-friendly. The problem is we have >> zero expertise in this area and none of us are C/C++ developers (I >> haven't coded in C/C++ since 1999 when I was at Iona). >> >> This brings me to what would be the next generation of the Keycloak >> Proxy. The first thing I'd like to improve is that configuration would >> happen within the admin console. This configuration could be made much >> simpler as whatever protocol configuration that would be needed could be >> hard-coded and pre-configured. Mappers would focus on mapping values >> to HTTP headers. >> >> Beyond configuration, things become more interesting and complex and >> their are multiple factors in deciding the authentication protocol, >> proxy design, and provisioning: >> >> * Can/Should one Keycloak Proxy virtual host and proxy multiple apps in >> same instance? One thing stopping this is SSL. If Keycloak Proxy is >> handling SSL, then there is no possibility of virtual hosting. If the >> load balancer is handling SSL, then this is a possibility. >> >> * Keycloak Proxy currently needs an HttpSession as it stores >> authentication information (JWS access token and Refresh Token) there so >> it can forward it to the application. We'd have to either shrink needed >> information so it could be stored in a cookie, or replication sessions. >> THe latter of which would have the same issues with cross DC. >> >> * Should we collocate Keycloak proxy with Keycloak runtime? That is, >> should Keycloak Proxy have direct access to UserSession, CLientSession, >> and other model interfaces? The benefits of this are that you could >> have a really optimized auth protocol, you'd still have to bounce the >> browser to set up cookies directly, but everything else could be handled >> through the ClientSession object and there would be no need to generate >> or store tokens. > +1 > > I personally never tried Keycloak Proxy, but it's intended for the > applications, which don't understand OIDC or SAML right? So we don't > need another layer of separate KeycloakProxy server, which needs to > communicate through OIDC with Keycloak auth-server itself, but we can > maybe just have another login protocol implementation like "Keycloak > protocol" or something? Once user is successfully authenticated, > Keycloak will just programatically create token and add some headers > (KEYCLOAK_IDENTITY etc) and forward the request to the application. > > Another advantage is, that we won't need anything special for the > replication and cross-dc. As long as all the state is cached in > userSession, Keycloak can just read the cached token from it and > forward to the application. We will need the solution for cross-dc of > userSessions anyway, but this will be able to just leverage it. The downside is that you potentially have a lot more nodes joining the cluster and also the memory footprint and size of the proxy. Keycloak server is 125M+ distro and currently takes up minimally 300M+ of actual RAM. I'm not sure if that's something we should take into account or not. I also don't know if users want one proxy that virtual-hosts a bunch of apps or not. I"m not keen on having multiple options for deploying the proxy. More work for us and more work for our users to figure out what to do. I would rather have one way that we can push people towards as the recommended and preferred way. Bill _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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 <mailto:bburke@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.