[keycloak-dev] combine proxy and keycloak server

Stian Thorgersen sthorger at redhat.com
Wed Aug 17 03:08:22 EDT 2016


On 16 August 2016 at 22:43, Bill Burke <bburke at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160817/406853d1/attachment-0001.html 


More information about the keycloak-dev mailing list