<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>