[keycloak-dev] next-gen Keycloak proxy

[Marek Posolda]

On 13/03/17 22:07, Bill Burke wrote:
> 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.
+1

I personally never tried Keycloak Proxy, but it's intended for the 
applications, which don't understand OIDC or SAML right? So we don't 
need another layer of separate KeycloakProxy server, which needs to 
communicate through OIDC with Keycloak auth-server itself, but we can 
maybe just have another login protocol implementation like "Keycloak 
protocol" or something? Once user is successfully authenticated, 
Keycloak will just programatically create token and add some headers 
(KEYCLOAK_IDENTITY etc) and forward the request to the application.

Another advantage is, that we won't need anything special for the 
replication and cross-dc. As long as all the state is cached in 
userSession, Keycloak can just read the cached token from it and forward 
to the application. We will need the solution for cross-dc of 
userSessions anyway, but this will be able to just leverage it.

Marek
>
> * 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.
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev