[keycloak-dev] Resolving of relative redirectUri in cluster

Stian Thorgersen stian at redhat.com
Mon Sep 29 03:42:32 EDT 2014


Ignore my email - I didn't read the email properly (Monday @ 9am isn't a good time to read technical emails).

It's a good idea and we should add it. Adapters will often be located behind the firewall and can communicate directly with Keycloak servers so shouldn't need to go through the proxy server.

Made me think, maybe we could add a in-vm transport for refreshing tokens etc.. That would further lower the overhead of refreshing tokens if applications are co-located on the same WildFly server.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 29 September, 2014 8:58:39 AM
> Subject: Re: [keycloak-dev] Resolving of relative redirectUri in cluster
> 
> To avoid sending all traffic through a proxy it would be better to either:
> 
> * Use round-robin DNS
> * Use HTTP redirect from http://frontend:8080 to http://backend-node1:8080
> 
> However, neither what you propose or HTTP redirect would work with cookies.
> Round-robin DNS would though and IMO that's the cleanest way to do it.
> 
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Monday, 29 September, 2014 8:38:58 AM
> > Subject: [keycloak-dev] Resolving of relative redirectUri in cluster
> > 
> > I wonder if it's ok to add possibility to WildFly/AS7 adapter for
> > alternative resolving of relative redirectUris. Currently it's always
> > retrieved from HTTP request sent by browser (ie. with relative uri
> > "/auth" and HTTP request is "http://localhost:8080/customer-portal" then
> > adapter is able to resolve the URI to "http://localhost:8080/auth"). Is
> > it ok to have possibility (perhaps boolean config option on adapter like
> > "preserve-hostname") to resolve them from the actual hostname instead of
> > browser request? Usually it's not much difference, but in cluster there
> > might be scenario like:
> > - Setup with loadbalancer on "http://frontend:8080" and 2 backend
> > cluster nodes "http://backend-node1:8080" and "http://backend-node2:8080"
> > - Then user filled login form. Now assume that request request with
> > code+state is processed on
> > "http://backend-node1:8080/customer-portal?code=...&state=..." . Now
> > adapter sends codeToToken exchanging request  to relative URI, which is
> > resolved from browser to "http://frontend:8080". So adapter sends
> > request to loadbalancer, which is then resended back to one of backend
> > nodes. So 2 additional network hops needed.
> > 
> > So when there is possibility to resolve relative URI from hostname, then
> > backend-node1 will send exchanging request to itself instead of going
> > through loadbalancer. In cluster it should help to save performance and
> > reduce network communication.
> > 
> > Note that this will be configurable and will be used by adapters just
> > for backend requests (codeToToken, refresh token etc). All browser
> > redirects will still need to go through loadbalancer IMO, in usual
> > cluster environments are cluster nodes hidden in private network and URI
> > like "http://backend-node1:8080/auth" may not be available for users.
> > 
> > wdyt?
> > 
> > Marek
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


More information about the keycloak-dev mailing list