Bump. I'm going to keep bumping this occasionally to see if somebody in the community wants to take this on. On 8/4/16 8:30 PM, Bill Burke wrote: > I think we should combine Keycloak Proxy with the keycloak server. When > creating a client, you would have an option to declare it as a proxied > client. This is way better than what we currently have as we woudln't > have to do SAML or OIDC so it would be more performant and it would > require no additional setup. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Yeah, on the Client creation page, instead of oidc or saml, you can pick "proxied". You would specify the URL pattern of incoming requests and the URL pattern to forward HTTP requests and bam, it just works. Set up some virtual host table on demand with Undertow. On 8/5/16 11:36 AM, Thomas Darimont wrote: Sounds interesting... could you provide a bit more detail about what you have in mind? Cheers, Thomas 2016-08-05 16:38 GMT+02:00 Bill Burke <bburke(a)redhat.com&gt;: > Bump. > > I'm going to keep bumping this occasionally to see if somebody in the > community wants to take this on. > > > On 8/4/16 8:30 PM, Bill Burke wrote: > > I think we should combine Keycloak Proxy with the keycloak server. When > > creating a client, you would have an option to declare it as a proxied > > client. This is way better than what we currently have as we woudln't > > have to do SAML or OIDC so it would be more performant and it would > > require no additional setup. > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

I'm not convinced about this. A lot of complexity for what seems like little benefit. The improvement of not having to do OIDC would probably end up being outweighed by all requests going through Keycloak rather than a separate proxy. On 9 August 2016 at 11:06, Thomas Darimont <thomas.darimont(a)googlemail.com <mailto:thomas.darimont@googlemail.com>> wrote: FYI, I sent some questions to the undertow dev-mailing list regarding dynamic vhost configuration: http://lists.jboss.org/pipermail/undertow-dev/2016-August/001668.html <http://lists.jboss.org/pipermail/undertow-dev/2016-August/001668.html> Cheers, Thomas 2016-08-05 21:26 GMT+02:00 Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>>: Yeah, on the Client creation page, instead of oidc or saml, you can pick "proxied". You would specify the URL pattern of incoming requests and the URL pattern to forward HTTP requests and bam, it just works. Set up some virtual host table on demand with Undertow. On 8/5/16 11:36 AM, Thomas Darimont wrote: > Sounds interesting... > > could you provide a bit more detail about what you have in mind? > > Cheers, > Thomas > > 2016-08-05 16:38 GMT+02:00 Bill Burke <bburke(a)redhat.com > <mailto:bburke@redhat.com>>: > > Bump. > > I'm going to keep bumping this occasionally to see if > somebody in the > community wants to take this on. > > > On 8/4/16 8:30 PM, Bill Burke wrote: > > I think we should combine Keycloak Proxy with the > keycloak server. When > > creating a client, you would have an option to declare > it as a proxied > > client. This is way better than what we currently have > as we woudln't > > have to do SAML or OIDC so it would be more performant > and it would > > require no additional setup. > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > <https://lists.jboss.org/mailman/listinfo/keycloak-dev> > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>

Don't you think that all that is pretty much related with turning Keycloak as a Web Application Firewall (WAF) ? Now that we also have authz services in, we can do a lot of things at this regard. ----- Original Message ----- From: "Bill Burke" <bburke(a)redhat.com&gt; To: stian(a)redhat.com, "Thomas Darimont" <thomas.darimont(a)googlemail.com&gt; Cc: "keycloak-dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Monday, August 15, 2016 10:38:00 AM Subject: Re: [keycloak-dev] combine proxy and keycloak server You should rethink your position, IMO. Its actually a huge benefit in both usability and performance. Usability in that you don't have to configure and run a completely different program/process that is configured completely different than Keycloak. You can configure and manage all clients in one place. Performance is that you get rid of all the redirects that happen with SAML and OIDC. FOr your performance concern, you would just assign only a set of specific nodes that would be your proxy. So, if you had a keycloak cluster of 4 nodes, 2 nodes could be designated solely as proxy nodes, the other 2 for normal SSO. On 8/15/16 7:44 AM, Stian Thorgersen wrote: I'm not convinced about this. A lot of complexity for what seems like little benefit. The improvement of not having to do OIDC would probably end up being outweighed by all requests going through Keycloak rather than a separate proxy. On 9 August 2016 at 11:06, Thomas Darimont < thomas.darimont(a)googlemail.com > wrote: FYI, I sent some questions to the undertow dev-mailing list regarding dynamic vhost configuration: http://lists.jboss.org/pipermail/undertow-dev/2016-August/001668.html Cheers, Thomas 2016-08-05 21:26 GMT+02:00 Bill Burke < bburke(a)redhat.com > : Yeah, on the Client creation page, instead of oidc or saml, you can pick "proxied". You would specify the URL pattern of incoming requests and the URL pattern to forward HTTP requests and bam, it just works. Set up some virtual host table on demand with Undertow. On 8/5/16 11:36 AM, Thomas Darimont wrote: Sounds interesting... could you provide a bit more detail about what you have in mind? Cheers, Thomas 2016-08-05 16:38 GMT+02:00 Bill Burke < bburke(a)redhat.com > : Bump. I'm going to keep bumping this occasionally to see if somebody in the community wants to take this on. On 8/4/16 8:30 PM, Bill Burke wrote: > I think we should combine Keycloak Proxy with the keycloak server. When > creating a client, you would have an option to declare it as a proxied > client. This is way better than what we currently have as we woudln't > have to do SAML or OIDC so it would be more performant and it would > require no additional setup. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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.

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.

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.

On 08/16/2016 04:43 PM, Bill Burke wrote: >> 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. Correction, Red Hat does support mod_auth_openidc and we do have in-house expertise to modify and extend these packages. In fact we're already made significant contributions to mod_auth_mellon and the lasso SAML library it utilizes. The platform group has deployed Keycloak behind both the Apache and HAproxy proxies and has (started) documenting the process. We also are in

the process of writing Ansible and Puppet configuration modules to help deploy Keycloak, I believe in all these scenarios Keycloak is behind a proxy. I wish our two groups had better awareness of each other.

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.

One of the main reasons for this whole email thread was to provide a way to reduce the number of moving parts that need to be installed and configured. And reduce the number of steps it takes to secure an application. Integration with other things is interesting, but not the goal of what I'm proposing.