1:38 a.m.
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
1:58 a.m.
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(a)redhat.com>
To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:42 a.m.
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(a)redhat.com>
To: "Marek Posolda" <mposolda(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
> To: keycloak-dev(a)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(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
3741
days inactive
3741
days old
2 comments
2 participants
participants (2)
-
Marek Posolda -
Stian Thorgersen