<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 16 August 2016 at 22:43, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<p><br>
</p>
<br>
<div>On 8/16/16 3:10 AM, Stian Thorgersen
wrote:<br>
</div>
<blockquote 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></span>
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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<br>
<blockquote 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></span>
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. </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<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.</div></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<br>
<blockquote 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></span>
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></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
But, we're arguing over something that nobody has time to work on
anyways :)</div></blockquote><div><br></div><div>Arguing (or discussing...) might end up in it becoming a high priority in which case we would find someone ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font color="#888888"><br>
<br>
Bill<br>
</font></span></div>
</blockquote></div><br></div></div>