Hi all,
Good work with the sample project Scott, it's a proper isolated code
where we might easily see what's going on. My previous problem was
nearly solved, it only keeps happening with FF, when user isn't logged
in[0].
Scott, I've got no reason to avoid other traditional HTTP proxies, all
of this is because I'm a bit of newbie in this kind of topics about
distributed environments and having chosen the Spring Cloud utility I
thought I could implement everything I needed using Zuul. So that's the
design I was thinking in for production:
Browser request -> Zuul proxy (80) -> UI Service (8099 and accesses
other services using the keycloak rest template) -> Backbone services
(80xx). They call each other using the keycloak rest template
Mobile app request -> Zuul proxy (80) -> Backbone services (80xx). They
call each other using the keycloak rest template
I've declared each backbone service in Keycloak as confidential because
that way I can access the service directly through the browser. Like you
say, it might be a properer option to use bearer-only access, but how
could I deal with the UI Service? This could be a choice according to
what you say, not adding any other proxy:
Browser request -> UI Service (80) -> Zuul proxy (8765) -> Backbone
services (80xx). They call each other using the keycloak rest template
The only drawback I can think about this design is the case of needing
to have more UI replicas, I would need to manage them myself? If I add a
proxy on the top of it could I have it talking with Eureka to know where
the different instances of the UI Service are?
Thanks!
[
Hi Aritz,
Your sample project was very helpful to understand the problems you’re
facing with Zuul as a proxy server. I spent some time investigating
and I’ve sent you a pull request[0] that will get your sample working.
That being said, please do read the "Cookies and Sensitive Headers”
documentation from Spring Cloud Netflix[1]. This applies to anyone
thinking of using Zuul as a stateful proxy server. Zuul was designed
by Netflix to proxy stateless services. In the Keycloak world, these
would be clients with an access type of bearer-only.
I'd strongly recommend against this setup in production. You could
continue to use Zuul for stateless services but anything requiring an
interactive login should really be behind a more traditional HTTP
proxy (e.g. Nginx, Apache, etc).
If you disagree, can you tell us the reason you’d want to proxy a
stateful service with Zuul?
Hope this helps clear things up a bit.
Best,
Scott
[0]:
https://github.com/xtremebiker/zuul-keycloak-test/pull/1
[1]:
http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com <mailto:srossillo@smartling.com>
> On Jun 2, 2016, at 4:08 PM, Aritz Maeztu <amaeztu(a)tesicnor.com
> <mailto:amaeztu@tesicnor.com>> wrote:
>
> Hi Scott and all,
>
> Tried removing the tomcat adapter from my project, it was my mistake
> putting it with the Spring Security one, all together. Thanks for the
> link to the question, it was a question I made in SO some time ago
> and your answer worked that time. However, even I leave /sso/login
> unprotected by Spring Security, the same behaviour happens. So I
> tried creating a sample scenario from scratch and I can reproduce the
> issue. Here it is, three maven projects, the service discovery
> (Eureka), the proxy service (Zuul) and the sample secured service:
>
>
https://github.com/xtremebiker/zuul-keycloak-test
>
> The keycloak.json file in the secured service should be replaced by
> the one for your client, of course. And here there is a filter
> declaration that can be made in Spring Boot to show the request
> dumper for Tomcat:
>
>
http://stackoverflow.com/questions/23325389/spring-boot-enable-http-reque...
>
> The steps to reproduce it are:
>
> 1- Boot the three projects
>
> 2- Wait till the two services are registered in Eureka and navigate
> to localhost:8765/secured-service/path
>
> 3- After logging in in Keycloak, the port changes to 8083
>
> I'll continue struggling and see if I can figure it out myself.
>
> Regards
>
>
> 31/05/2016 22:56(e)an, Scott Rossillo igorleak idatzi zuen:
>> Hi Artiz,
>>
>> If you’re using the Tomcat adapter and Spring Security adapter
>> together, they may be interfering with each other. I’m not saying
>> this is the problem you’re having but I’d avoid using both adapters
>> together.
>>
>> Please also take a look at this Stack Overflow answer[0] related to
>> redirect issues. If none of this helps I’ll try to debug with Eureka
>> and Zuul.
>>
>> [0]:
>>
http://stackoverflow.com/questions/33543672/keycloak-redirects-me-to-my-i...
>>
>> Scott Rossillo
>> Smartling | Senior Software Engineer
>> srossillo(a)smartling.com
>>
>>> On May 31, 2016, at 4:00 PM, Aritz Maeztu <amaeztu(a)tesicnor.com>
wrote:
>>>
>>> Hello Scott,
>>>
>>> I've got the spring security and tomcat keycloak adapters both as a
>>> project dependency for each service (as I'm running the services in
>>> Tomcat 8 embedded servers). Basically I want to base my security in
>>> Spring Security, that's why I chose this adapter over the Spring
>>> Boot adapter.
>>>
>>> As the behaviour states, a redirection is made first to the
>>> /sso/login endpoint, then other one to the keycloak authorization
>>> server. The question is, as a redirection is a mere instruction
>>> stated from the server to the browser, which chances do I have to
>>> send the original x-forwarded headers to the keycloak authorization
>>> server, so that it can make the redirection to the url requested at
>>> the very beginning (to the reverse proxy)?
>>>
>>> I could implement a playground scenario for you if you happen to
>>> require it.
>>>
>>> Many thanks
>>>
>>>
>>> 31/05/2016 20:14(e)an, Scott Rossillo igorleak idatzi zuen:
>>>> Hi Artiz,
>>>>
>>>> So just to be clear, which Keycloak adapter are you using? The
>>>> Spring Boot Adapter or the Spring Security Adapter?
>>>>
>>>> Scott Rossillo
>>>> Smartling | Senior Software Engineer
>>>> srossillo(a)smartling.com
>>>>
>>>>> On May 31, 2016, at 3:13 AM, Aritz Maeztu
<amaeztu(a)tesicnor.com>
>>>>> wrote:
>>>>>
>>>>> I've got some Spring Boot application instances with embeded
>>>>> Tomcat servlet containers. Tomcat has a similar system to Wildfly
>>>>> for request dumpering, that's what I have enabled for getting the
>>>>> trace below. In short words that's the behaviour I'm able to
see:
>>>>>
>>>>> 1. Zuul Proxy (Spring Boot in Tomcat) -> Organization Service
>>>>> (8083 port) : A forward request where X-forwarded headers are
>>>>> included
>>>>>
>>>>> 2. Organization Service (localhost:8083) : Looks for a token and
>>>>> if it's not available, the keycloak adapter redirects to the
>>>>> /sso/login of the same service (Here the traceability from the
>>>>> proxy gets losts)
>>>>>
>>>>> 3. localhost:8083/sso/login: Redirects to the keycloak wildfly
>>>>> server, saving the requested url
>>>>>
>>>>> 4. Keycloak login: The user performs the authentication and the
>>>>> redirectUri is localhost:8083/sso/login. Later on, the login
>>>>> endpoint redirects the user to the url requested in point 2, not
>>>>> the first one from the proxy.
>>>>>
>>>>> I only have this problem when my organization service needs to
>>>>> verify the token (or a token doesn't exist) using the keycloak
>>>>> adapter. When the /sso/login endpoint is not requested,
>>>>> everything is working properly. Hope I've explained it well!
>>>>>
>>>>>
>>>>> 31/05/2016 7:15(e)an, Stian Thorgersen igorleak idatzi zuen:
>>>>>> Where is your app deployed? If it's on WildFly you can follow
>>>>>> the same steps used to configure reverse proxy for Keycloak
>>>>>> Server to configure WildFly. Check if getRequestURL returns the
>>>>>> correct URL in your app.
>>>>>>
>>>>>> On 30 May 2016 at 15:08, Aritz
Maeztu<amaeztu(a)tesicnor.com>wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------- Birbidalitako mezua --------
>>>>>> Gaia: Re: [keycloak-user] Redirection issue with proxy
>>>>>> behind keycloak
>>>>>> Data: Mon, 30 May 2016 13:28:21 +0200
>>>>>> Nork: Aritz Maeztu<amaeztu(a)tesicnor.com>
>>>>>> Nori: stian(a)redhat.com
>>>>>> CC: Niels Bertram<nielsbne(a)gmail.com>,
>>>>>> keycloak-user<keycloak-user(a)lists.jboss.org>, Scott
>>>>>> Rossillo<srossillo(a)smartling.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I've done all the traceability from the proxy server
till
>>>>>> the login page is displayed:
>>>>>>
>>>>>> First step, /organization/organizations is requested, so the
>>>>>> proxy server knows it has to be forwarded to the 8083 port
>>>>>> (the one for the organization service). That's the first
>>>>>> request received by my application's Tomcat:
>>>>>>
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 START TIME =30-may-2016 13:01:18
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 requestURI=/organizations
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 authType=null
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 characterEncoding=UTF-8
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 contentLength=-1
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 contentType=null
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 contextPath=
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=accept-language=es-ES,es;q=0.8
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=x-forwarded-host=mies-057:8765
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=x-forwarded-prefix=/organization
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=upgrade-insecure-requests=1
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=accept-encoding=gzip
>>>>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9
>>>>>>
header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=user-agent=Mozilla/5.0 (Windows
>>>>>> NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
>>>>>> Chrome/50.0.2661.102 Safari/537.36
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=netflix.nfhttpclient.version=1.0
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9
>>>>>> header=x-netflix-httpclientname=organization
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=host=mies-057:8083
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=connection=Keep-Alive
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 locale=es_ES
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 method=GET
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 pathInfo=null
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 protocol=HTTP/1.1
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 queryString=null
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 remoteAddr=192.168.56.1
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 remoteHost=192.168.56.1
>>>>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 remoteUser=null
>>>>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 requestedSessionId=null
>>>>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 scheme=http
>>>>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 serverName=mies-057
>>>>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 serverPort=8083
>>>>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 servletPath=/organizations
>>>>>> 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 isSecure=false
>>>>>> 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9
>>>>>>
------------------=--------------------------------------------
>>>>>>
>>>>>> Here x-forwarded-host is mies-057:8765 (the proxy server)
>>>>>> and x-forwarded-prefix is /organization. So the original
>>>>>> request is kept in the headers. Well, now my service (8083)
>>>>>> tries to check for authorization via the /sso/login endpoint
>>>>>> from the keycloak spring security adapter:
>>>>>>
>>>>>> 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9]
>>>>>> o.k.a.s.management.HttpSessionManager : Session created:
>>>>>> CDCA7AD4439DE94BD0B3B5803DAA0752
>>>>>> 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9]
>>>>>> k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to
>>>>>> login URI /sso/login
>>>>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9
>>>>>>
------------------=--------------------------------------------
>>>>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 authType=null
>>>>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 contentType=null
>>>>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=X-Content-Type-Options=nosniff
>>>>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=X-XSS-Protection=1; mode=block
>>>>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=Cache-Control=no-cache,
>>>>>> no-store, max-age=0, must-revalidate
>>>>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=Pragma=no-cache
>>>>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=Expires=0
>>>>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 header=X-Frame-Options=DENY
>>>>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9
>>>>>>
header=Set-Cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752;
>>>>>> Path=/; HttpOnly
>>>>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9
>>>>>> header=Location=http://mies-057:8083/sso/login
>>>>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 remoteUser=null
>>>>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 status=302
>>>>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9 END TIME =30-may-2016 13:01:18
>>>>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-9
>>>>>>
===============================================================
>>>>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 START TIME =30-may-2016 13:01:18
>>>>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 requestURI=/sso/login
>>>>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 authType=null
>>>>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 characterEncoding=UTF-8
>>>>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 contentLength=-1
>>>>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 contentType=null
>>>>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 contextPath=
>>>>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10
>>>>>> cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752
>>>>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 header=host=mies-057:8083
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 header=connection=keep-alive
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10
>>>>>>
header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 header=upgrade-insecure-requests=1
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 header=user-agent=Mozilla/5.0 (Windows
>>>>>> NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
>>>>>> Chrome/50.0.2661.102 Safari/537.36
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 header=accept-encoding=gzip, deflate,
sdch
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 header=accept-language=es-ES,es;q=0.8
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10
>>>>>> header=cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 locale=es_ES
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 method=GET
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 pathInfo=null
>>>>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 protocol=HTTP/1.1
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 queryString=null
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 remoteAddr=192.168.56.1
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 remoteHost=192.168.56.1
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 remoteUser=null
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10
>>>>>> requestedSessionId=CDCA7AD4439DE94BD0B3B5803DAA0752
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 scheme=http
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 serverName=mies-057
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 serverPort=8083
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 servletPath=/sso/login
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10 isSecure=false
>>>>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10]
>>>>>> o.a.c.filters.RequestDumperFilter :
>>>>>> http-nio-8083-exec-10
>>>>>>
------------------=--------------------------------------------
>>>>>> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10]
>>>>>> o.k.adapters.PreAuthActionsHandler :
>>>>>> adminRequesthttp://mies-057:8083/sso/login
>>>>>> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10]
>>>>>> f.KeycloakAuthenticationProcessingFilter : Request is to
>>>>>> process authentication
>>>>>> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10]
>>>>>> f.KeycloakAuthenticationProcessingFilter : Attempting
>>>>>> Keycloak authentication
>>>>>> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10]
>>>>>> o.k.adapters.RequestAuthenticator : -->
authenticate()
>>>>>> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10]
>>>>>> o.k.adapters.RequestAuthenticator : try bearer
>>>>>> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10]
>>>>>> o.k.adapters.RequestAuthenticator : try oauth
>>>>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10]
>>>>>> o.k.a.s.token.SpringSecurityTokenStore : Checking if
>>>>>>
org.keycloak.adapters.springsecurity.authentication.SpringSecurityRequestAuthenticator@d328c2d
>>>>>> is cached
>>>>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10]
>>>>>> o.k.adapters.OAuthRequestAuthenticator : there was no code
>>>>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10]
>>>>>> o.k.adapters.OAuthRequestAuthenticator : redirecting to
>>>>>> auth server
>>>>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10]
>>>>>> o.k.adapters.OAuthRequestAuthenticator : callback
>>>>>> uri:http://mies-057:8083/sso/login
>>>>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10]
>>>>>> f.KeycloakAuthenticationProcessingFilter : Auth outcome:
>>>>>> NOT_ATTEMPTED
>>>>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10]
>>>>>> o.k.adapters.OAuthRequestAuthenticator : Sending redirect
>>>>>> to login
>>>>>>
page:http://mies-057.tesicnor.com:8080/auth/realms/master/protocol/openid-connect/auth?response_type=code&client_id=organization&redirect_uri=http%3A%2F%2Fmies-057%3A8083%2Fsso%2Flogin&state=1%2F21d709ec-1e69-41c5-ac6d-c705f8ce3907&login=true
>>>>>>
>>>>>> As it's shown in the logs, the X-forwarded logs are not
kept
>>>>>> by the keycloak adapter (look at the lines
>>>>>> belowk.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting
>>>>>> to login URI /sso/login). So could it be the proxy server
>>>>>> itself being properly configured but the keycloak adapter
>>>>>> losing the original headers while performing the
redirection?
>>>>>>
>>>>>> I've also set up the request dumper in the undertow
server
>>>>>> as Niels suggested, but obviously, X-forwarded headers are
>>>>>> not reaching the keycloak server..
>>>>>>
>>>>>> Thanks for your time, again ;-)
>>>>>>
>>>>>>
>>>>>>
>>>>>> 25/05/2016 7:22(e)an, Stian Thorgersen igorleak idatzi zuen:
>>>>>>> You need the Host and X-Forwarded-For headers to be
>>>>>>> included and there's also some config to be done on
the
>>>>>>> Keycloak server (see
>>>>>>>
http://keycloak.github.io/docs/userguide/keycloak-server/html/server-inst...)
>>>>>>>
>>>>>>> On 24 May 2016 at 08:46, Aritz
>>>>>>> Maeztu<amaeztu(a)tesicnor.com>wrote:
>>>>>>>
>>>>>>> Hi Niels and Scott. First of all, thank you very
much
>>>>>>> for your help. I'm currently using Zuul (Spring
Cloud)
>>>>>>> as the reverse proxy. All the services are
registered
>>>>>>> in a discovery service called Eureka and then Zuul
>>>>>>> looks for the service id there and performs de
>>>>>>> redirection. I read aboutX-Forwarded headers, but I
>>>>>>> thought it might result in a security issue if not
>>>>>>> included, not that it could affect the redirection
process.
>>>>>>>
>>>>>>> As Scott says, I suppose the Host and the X-Real-Ip
>>>>>>> headers are the relevant ones here, so I guess I
should
>>>>>>> instruct Zuul to send them when the service is
>>>>>>> addressed (however I wonder why they are not already
>>>>>>> being sent, as Zuul is a proxy service, all in all).
>>>>>>>
>>>>>>> Here I include a preview of the first redirection
made
>>>>>>> to the keycloak login page, which shows the request
>>>>>>> headers sent to the service /login endpoint (at port
>>>>>>> 8081 in localhost):
>>>>>>>
>>>>>>>
https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0
>>>>>>>
>>>>>>> 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi
zuen:
>>>>>>>> Hi Artitz,
>>>>>>>>
>>>>>>>> a great way to figure out what is sent from the
>>>>>>>> reverse proxy to your keycloak server is to use
the
>>>>>>>> undertow request dumper.
>>>>>>>>
>>>>>>>> From the jboss-cli just add the request dumper
filter
>>>>>>>> to your undertow configuration like this:
>>>>>>>>
>>>>>>>> $KC_HOME/bin/jbpss-cli.sh -c
>>>>>>>>
>>>>>>>>
/subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler,
>>>>>>>> module=io.undertow.core)
>>>>>>>>
>>>>>>>>
/subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add
>>>>>>>>
>>>>>>>> /:reload
>>>>>>>>
>>>>>>>> given your apache config looks something like
this:
>>>>>>>>
>>>>>>>> ProxyRequests Off
>>>>>>>> ProxyPreserveHost On
>>>>>>>> ProxyVia On
>>>>>>>>
>>>>>>>> ProxyPass /auth ajp://127.0.0.1:8009/auth
>>>>>>>> <
http://127.0.0.1:8009/auth>
>>>>>>>> ProxyPassReverse /auth ajp://127.0.0.1:8009/auth
>>>>>>>> <
http://127.0.0.1:8009/auth>
>>>>>>>>
>>>>>>>>
>>>>>>>> you should see something like that (forwared info
is
>>>>>>>> somewhat rubbish in this example as I am running
the
>>>>>>>> hosts on Virtualbox - but you can see this
request was
>>>>>>>> put through 2 proxies from local pc 192.168.33.1
to
>>>>>>>> haproxy on 192.168.33.80 and then apache reverse
proxy
>>>>>>>> on 192.168.33.81 ):
>>>>>>>>
>>>>>>>>
==============================================================
>>>>>>>> 23:47:20,563 INFO [io.undertow.request.dump]
(default
>>>>>>>> task-14)
>>>>>>>>
----------------------------REQUEST---------------------------
>>>>>>>> URI=/auth/welcome-content/favicon.ico
>>>>>>>> characterEncoding=null
>>>>>>>> contentLength=-1
>>>>>>>> contentType=null
>>>>>>>> header=Accept=*/*
>>>>>>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6
>>>>>>>> header=Cache-Control=no-cache
>>>>>>>> header=Accept-Encoding=gzip, deflate, sdch
>>>>>>>> header=DNT=1
>>>>>>>> header=Pragma=no-cache
>>>>>>>> header=X-Original-To=192.168.33.80
>>>>>>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1;
WOW64)
>>>>>>>> AppleWebKit/537.36 (KHTML, like Gecko)
>>>>>>>> Chrome/50.0.2661.102 Safari/537.36
>>>>>>>> header=Authorization=Basic
>>>>>>>> bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo=
>>>>>>>> header=X-Forwarded-Proto=https
>>>>>>>> header=X-Forwarded-Port=443
>>>>>>>> header=X-Forwarded-For=192.168.33.1
>>>>>>>> header=Referer=https://login.vagrant.dev/auth/
>>>>>>>> header=Host=login.vagrant.dev
>>>>>>>> locale=[en_US, en, de]
>>>>>>>> method=GET
>>>>>>>> protocol=HTTP/1.1
>>>>>>>> queryString=
>>>>>>>> remoteAddr=192.168.33.1:0
<
http://192.168.33.1:0/>
>>>>>>>> remoteHost=192.168.33.1
>>>>>>>> scheme=https
>>>>>>>> host=login.vagrant.dev
>>>>>>>> serverPort=443
>>>>>>>>
--------------------------RESPONSE--------------------------
>>>>>>>> contentLength=627
>>>>>>>> contentType=application/octet-stream
>>>>>>>> header=Cache-Control=max-age=2592000
>>>>>>>> header=X-Powered-By=Undertow/1
>>>>>>>> header=Server=WildFly/10
>>>>>>>>
>>>>>>>>
>>>>>>>> Hope this helps diagnosing your issue. Niels
>>>>>>>>
>>>>>>>> On Tue, May 24, 2016 at 1:20 AM, Aritz
>>>>>>>> Maeztu<amaeztu(a)tesicnor.com>wrote:
>>>>>>>>
>>>>>>>> I'm using keycloak to securize some
Spring based
>>>>>>>> services (with the keycloak spring security
>>>>>>>> adapter). The adapter creates a `/login`
endpoint
>>>>>>>> in each of the services which redirects to
the
>>>>>>>> keycloak login page and then redirects back
to the
>>>>>>>> service when authentication is done. I also
have a
>>>>>>>> proxy service which I want to publish in the
80
>>>>>>>> port and will take care of routing all the
>>>>>>>> requests to each service. The proxy performs
a
>>>>>>>> plain FORWARD to the service, but the
problem
>>>>>>>> comes when I securize the service with the
>>>>>>>> keycloak adapter.
>>>>>>>>
>>>>>>>> When I make a request, the adapter redirects
to
>>>>>>>> its login endpoint and then to the keycloak
auth
>>>>>>>> url. When keycloak sends the redirection, the
url
>>>>>>>> shown in the browser is the one from the
service
>>>>>>>> and not the one from the proxy. Do I have
some
>>>>>>>> choice to tell the adapter I want to redirect
back
>>>>>>>> to the first requested url?
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Aritz Maeztu Otaño
>>>>>>>> Departamento Desarrollo de Software
<Mail
>>>>>>>> Attachment.gif>
>>>>>>>>
<
https://www.linkedin.com/profile/preview?vpa=pub&locale=es_ES>
>>>>>>>>
>>>>>>>> <Mail Attachment.png>
<
http://www.tesicnor.com/>
>>>>>>>>
>>>>>>>> Pol. Ind. Mocholi.C/Rio Elorz, Nave 13E31110
Noain
>>>>>>>> (Navarra)
>>>>>>>> Telf.: 948 21 40 40
>>>>>>>> Fax.: 948 21 40 41
>>>>>>>>
>>>>>>>> Antes de imprimir este e-mail piense bien si
es
>>>>>>>> necesario hacerlo: El medioambiente es cosa
de todos.
>>>>>>>>
>>>>>>>>
>>>>>>>>
_______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Aritz Maeztu Otaño
>>>>>>> Departamento Desarrollo de Software <Mail
>>>>>>> Attachment.gif>
>>>>>>>
<
https://www.linkedin.com/profile/preview?vpa=pub&locale=es_ES>
>>>>>>>
>>>>>>> <Mail Attachment.png>
<
http://www.tesicnor.com/>
>>>>>>>
>>>>>>> Pol. Ind. Mocholi.C/Rio Elorz, Nave 13E31110 Noain
>>>>>>> (Navarra)
>>>>>>> Telf.: 948 21 40 40
>>>>>>> Fax.: 948 21 40 41
>>>>>>>
>>>>>>> Antes de imprimir este e-mail piense bien si es
>>>>>>> necesario hacerlo: El medioambiente es cosa de
todos.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> keycloak-user(a)lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Aritz Maeztu Otaño
>>>>>> Departamento Desarrollo de Software <Mail
Attachment.gif>
>>>>>>
<
https://www.linkedin.com/profile/preview?vpa=pub&locale=es_ES>
>>>>>> <Mail Attachment.png> <
http://www.tesicnor.com/>
>>>>>>
>>>>>> Pol. Ind. Mocholi.C/Rio Elorz, Nave 13E31110 Noain (Navarra)
>>>>>> Telf.: 948 21 40 40
>>>>>> Fax.: 948 21 40 41
>>>>>>
>>>>>> Antes de imprimir este e-mail piense bien si es necesario
>>>>>> hacerlo: El medioambiente es cosa de todos.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user(a)lists.jboss.org
>>>>>> <mailto:keycloak-user@lists.jboss.org>
>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Aritz Maeztu Otaño
>>>>> Departamento Desarrollo de Software <linkdin.gif>
>>>>>
<
https://www.linkedin.com/profile/preview?vpa=pub&locale=es_ES>
>>>>> <logo.png> <
http://www.tesicnor.com/>
>>>>>
>>>>> Pol. Ind. Mocholi.C/Rio Elorz, Nave 13E31110 Noain (Navarra)
>>>>> Telf.: 948 21 40 40
>>>>> Fax.: 948 21 40 41
>>>>>
>>>>> Antes de imprimir este e-mail piense bien si es necesario
>>>>> hacerlo: El medioambiente es cosa de todos.
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> Avast logo
>>>
<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&...
>>>
>>>
>>> El software de antivirus Avast ha analizado este correo electrónico
>>> en busca de virus.
>>>
www.avast.com
>>>
<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&...
>>>
>>>
>>>
>>
>
>
>
> ------------------------------------------------------------------------
> Avast logo
>
<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&...
>
>
> El software de antivirus Avast ha analizado este correo electrónico
> en busca de virus.
>
www.avast.com
>
<
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&...
>
>
>
Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra)
Telf.: 948 21 40 40
Fax.: 948 21 40 41
Antes de imprimir este e-mail piense bien si es necesario hacerlo: El
medioambiente es cosa de todos.