On 16 August 2016 at 22:43, Bill Burke <bburke@redhat.com> wrote:



On 8/16/16 3:10 AM, Stian Thorgersen wrote:
You'll end up with another "protocol" to do this, which is additional maintenance and testing and more importantly a new potential vector for vulnerabilities. Not great IMO.


Protocol?  You mean like AJP?  BTW, making an argument not to have a feature because of maintenance and testing is a really lame reason. Anybody can basically just use that argument for anything they don't like.

I thought you where stating it shouldn't use OIDC or SAML. So it'll need to be something else right? IMO we should leverage OIDC and SAML and not come up with yet another way to do the same thing.

I'm sorry, but it's not a lame reason at all to argue the time and complexity of implementing and maintaining something. That should always be taken into consideration. Just for argument sake if it took 5 man-years to implement, test and maintain what you are proposing (I'm not saying that it will, but I'm exaggerating to prove a point) and it exposed us to thousands of vulnerabilities (again, I'm exaggerating) would that not be a good enough reason not to do it?
 


What you are describing around having dedicated nodes for the proxy operations just sounds more complex than having completely separate servers completely. For high performance I'd imagine the proxy would end up with having quite different needs for configuration than the Keycloak server as well.

 Not really.  You just specify a DNS entry that points to one of your Keycloak nodes that is designated as the proxy.  You ahve to do that anyways. 

As far as config goes, if the proxy needs to be configured differently, we just provide an extra domain.xml profile like we do for the example load-balancer that is described in the docs.

So you have one group of Keycloak servers acting as a proxy with some special config, then another group of Keycloak servers acting as regular KC servers with yet another config. Then you have different DNS settings depending on what app it is. Etc. etc.. How is that simpler than just using the Keycloak proxy we have today with a separate KC server?

A lot of tweaking goes into creating a proxy that works fast and with the minimum latency. Just talk to the APIMan guys. I believe they have much better performance on Vert.x than they have on Undertow as well.
 


There's also plenty of options around proxies (Apache, nginx, APIMan, 3scale, etc.). I'm not convinced we should even have our own. Sounds like APIMan might actually survive and end up being supported in some form, so that may still be a better option to us rolling our own proxy/gateway.

 Disagree 100%.  Right now without a supported proxy we have zero control over how other languages and environments integrate with Keycloak (except Java).  We're at the mercy of mod-auth-mellon and mod-auth-openidc the latter of which isn't even maintained by RHT.  Both of which we do not have any in house knowledge to make extensions to.  The potential to simplify and unify setup and configuration and management is just too huge here to ignore.

Apache and nginx as proxies are what folks use and already have in place. Having yet another proxy in the mix doesn't really simplify things IMO. An alternative to making life easier would be to make it easier to use Apache and nginx rather than reinvent the wheel and create our own.
 

But, we're arguing over something that nobody has time to work on anyways :)

Arguing (or discussing...) might end up in it becoming a high priority in which case we would find someone ;)
 


Bill