[keycloak-dev] combine proxy and keycloak server

[Bill Burke]

On 8/16/16 6:19 PM, John Dennis wrote:
> 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 
Could you share these docs with us..create better awareness between the 
two groups, because we already had to document that process from the 
keycloak end and we're missing the apache end of things:

https://keycloak.gitbooks.io/server-installation-and-configuration/content/v/2.1/topics/clustering/load-balancer.html




> 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.
>
By in-house knowledge, I mean a member of this team that reports to 
Bolek.    Right now we're stuck with vanilla SAML and OIDC and however 
these mod-auth plugins implement those specs.  Are you willing to 
maintain a fork of these mods with keycloak-specific extensions?  For 
example we're writing an extension to our Java OIDC adapters so that we 
can have sticky sessions for both the browser redirects and out-of-band 
code to token requests so we can avoid unnecessary DB hits.  I know you 
guys support mod-auth-mellon, but mod-auth-openidc is managed and run by 
a commercial competitor: ping identity, which, by itself sucks from a 
perception perspective.

But we're diverging into arguments that were not the focus of the 
original post.   My main focus to reduce the number of things you have 
to install and configure, make configuration and management consistent, 
reduce the number of steps to secure an app, and finally reduce the 
number of network hops for a login.  Make security easier and faster for 
developers which is why Stian and I started the project in the first place.