[keycloak-dev] next-gen Keycloak proxy

[Bill Burke]

Keycloak Proxy was written a few years ago to secure apps that can't use 
an adapter provided by us.  While Keycloak Proxy works (? mostly?) 
,we've been pushing people to Apache + mod-auth-mellon or 
mod-auth-openidc for non-Java apps.   I predict that relying on Apache 
to proxy and secure apps that can't use our adapters is going to quickly 
become an issue for us.  We already have a need to write extensions to 
mod-auth-*, specifically to support Pedro's Authz work (which is really 
nice BTW!).  We could also do tighter integration to make the 
configuration experience more user-friendly.  The problem is we have 
zero expertise in this area and none of us are C/C++ developers (I 
haven't coded in C/C++ since 1999 when I was at Iona).

This brings me to what would be the next generation of the Keycloak 
Proxy.  The first thing I'd like to improve is that configuration would 
happen within the admin console.  This configuration could be made much 
simpler as whatever protocol configuration that would be needed could be 
hard-coded and pre-configured.   Mappers would focus on mapping values 
to HTTP headers.

Beyond configuration, things become more interesting and complex and 
their are multiple factors in deciding the authentication protocol, 
proxy design, and provisioning:

* Can/Should one Keycloak Proxy virtual host and proxy multiple apps in 
same instance?  One thing stopping this is SSL.  If Keycloak Proxy is 
handling SSL, then there is no possibility of virtual hosting.  If the 
load balancer is handling SSL, then this is a possibility.

* Keycloak Proxy currently needs an HttpSession as it stores 
authentication information (JWS access token and Refresh Token) there so 
it can forward it to the application.  We'd have to either shrink needed 
information so it could be stored in a cookie, or replication sessions.  
THe latter of which would have the same issues with cross DC.

* Should we collocate Keycloak proxy with Keycloak runtime?  That is, 
should Keycloak Proxy have direct access to UserSession, CLientSession, 
and other model interfaces?  The benefits of this are that you could 
have a really optimized auth protocol, you'd still have to bounce the 
browser to set up cookies directly, but everything else could be handled 
through the ClientSession object and there would be no need to generate 
or store tokens.

* Collocation is even nicer if virtual hosting could be done and there 
would be no configuration needed for the proxy.  It would just be 
configured as a Keycloak instance and pull which apps in would need to 
proxy from the database.