<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 8/16/16 3:10 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAcuzkACr6ZFYE12EH3Ei5P-qJsidbgCQd157ATUdkcM+g@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div><br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAJgngAcuzkACr6ZFYE12EH3Ei5P-qJsidbgCQd157ATUdkcM+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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.</div>
<div><br>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAJgngAcuzkACr6ZFYE12EH3Ei5P-qJsidbgCQd157ATUdkcM+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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.</div>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote>
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.<br>
<br>
But, we're arguing over something that nobody has time to work on
anyways :)<br>
<br>
Bill<br>
</body>
</html>