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.
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.
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.
But, we're arguing over something that nobody has time to work on anyways :)
Bill