These are chat archives for spring-cloud/spring-cloud

13th
May 2015
Ryan Baxter
@ryanjbaxter
May 13 2015 00:36
is there good “utility” class to move DomainExtractingServer.extractApproximateZone to? I want to reuse it in another class
Dave Syer
@dsyer
May 13 2015 06:45
If you can't see one I guess you need to create it
Leon Radley
@leon
May 13 2015 13:00
@dsyer I’m having troubles with SSO and csrf. when I try to login to with sso I’m not getting logged in "Authentication Failed: Could not obtain access token”
Why is csrf interfering with the login process?
Do I need to change the order of the filters?
Leon Radley
@leon
May 13 2015 14:37
Anyone here?
Dave Syer
@dsyer
May 13 2015 15:55
Is it your own oauth2 auth server?
@collinpeters I didn't get anything on the topology
Gitter dropped some packets
Collin Peters
@collinpeters
May 13 2015 16:01
ok, one minute
Yesterday I extended LoginUrlAuthenticationEntryPoint#buildRedirectUrlToLoginPage and hardcoded the return of the proper redirect URL (for testing). This partially worked... I am still trying to step through it all
Dave Syer
@dsyer
May 13 2015 16:05
I'm confused about that. It's a Spring Security core class so it should work in the majority of situations you'd encounter.
I suspect something is weird about what you are doing.
You have 2 proxy layers for the "1st party" client?
Collin Peters
@collinpeters
May 13 2015 16:05
more than likely :)
yes
gateway will do /ui/*
ui server will do /ui/api and /ui/oauth
Dave Syer
@dsyer
May 13 2015 16:06
I just wonder what's so bad about redirecting directly to the auth server
Collin Peters
@collinpeters
May 13 2015 16:06
the reason being is that I want 3rd parties to go right through to the resource & oauth servers
Dave Syer
@dsyer
May 13 2015 16:07
And why not the 1st party?
Collin Peters
@collinpeters
May 13 2015 16:07
In the current setup the auth server would not be directly exposed. i.e. it runs under the same URL, same port. So https://domain/oauth will identify the auth server
I suppose I don't have to have the UI server doing a proxy of /oauth
Dave Syer
@dsyer
May 13 2015 16:09
I would get it working that way first at least
Collin Peters
@collinpeters
May 13 2015 16:10
I don't think that will fix the redirect problem though. Yesterday I took the oauth example from the tutorial series and changed the ui server to run on port 8081, then put a simple reversee proxy in front of it, and the redirect URL is always the 'internal port'
Dave Syer
@dsyer
May 13 2015 16:10
There might be some advantages to sharing a domain at least (if not a host). But you can try that when the flow actually works. Sharing a domain would normally be handled by a front end proxy (not one of the apps).
Collin Peters
@collinpeters
May 13 2015 16:11
If extending LoginUrlAuthenticationEntryPoint is the correct approach to remedy that, then I suppose that might be enough
Dave Syer
@dsyer
May 13 2015 16:11
If there is a proxy and it adds X-Forwarded-* and the redirect is coming to the wrong place, that sounds like a problem
But I can't believe that no-one ran a Spring Security app behind a proxy before (it can't possibly be true)
Collin Peters
@collinpeters
May 13 2015 16:12
yeah, I added some debug and x-forwarded-* is there, but I don't see the code ever trying to use it
agreed, it does seem strange
Dave Syer
@dsyer
May 13 2015 16:17
Maybe @rwinch can help with that
Actually I think he just had a baby, so he's probably on leave
Collin Peters
@collinpeters
May 13 2015 16:19
ok, made it further down the process now. Based on your example I have the following:
  1. Angular app appempts /user which gets a 302 to localhost:8080/ui/login
2- /ui/login does a 302 redirect to the auth server at :8080/oauth/... which is proxied directly to the auth server
3 - auth server authenticates, then does 302 redirect to http://localhost:8080/ui/login?code=8rNRD7&state=CG4ddZ
4 - now the ui server grabs that, I can see it authenticate the code and get a token, but then it does a 302 redirect o localhost:8081/
this code seem to even hit my custom LoginUrlAuthenticationEntryPoint. Which is probably right, now I need to hunt down how to get that one fixed
I will check out /trace to see what the headers are
I guess Spring Security 3 might not have access to that if it's new
But I doubt no-one needed this before
Collin Peters
@collinpeters
May 13 2015 16:31
Here is the info for the login?code=xxxx from /trace on the UI server
   {
      "timestamp": 1431534424782,
      "info": {
         "method": "GET",
         "path": "/login",
         "query": "code=8Ja6O7&state=LiWrKn&",
         "remote": true,
         "proxy": "ui",
         "headers": {
            "request": {
               "accept": "application/json, text/plain, */*",
               "x-xsrf-token": "4f3de84c-3bd9-4c7a-83ff-0cbf037124d8",
               "x-requested-with": "XMLHttpRequest",
               "user-agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36",
               "referer": "http://localhost:8080/ui/",
               "accept-encoding": "deflate, gzip",
               "accept-language": "en-GB,en;q=0.8,en-US;q=0.6,en-CA;q=0.4",
               "cookie": "JSESSIONID=93B320C53448C672733A8FB45974773A; XSRF-TOKEN=4f3de84c-3bd9-4c7a-83ff-0cbf037124d8",
               "x-forwarded-host": "localhost:8080",
               "x-forwarded-prefix": "/ui"
            },
            "response": {
               "Server": "Apache-Coyote/1.1",
               "X-Content-Type-Options": "nosniff",
               "X-XSS-Protection": "1; mode=block",
               "Cache-Control": "no-cache, no-store, max-age=0, must-revalidate",
               "Pragma": "no-cache",
               "Expires": "0",
               "X-Frame-Options": "DENY",
               "Set-Cookie": "JSESSIONID=C9362E193747E405B7F673B9894AA178; Path=/; HttpOnly",
               "Location": "http://localhost:8081/",
               "Content-Length": "0",
               "Date": "Wed, 13 May 2015 16:27:52 GMT",
               "status": "302"
            }
         }
      }
   },
x-forwarded-* is present, but the 302 Location in the response is not using it
I'm heading into some meetings now. I'll debug further in a bit, if you have any tips on where to look it would be useful. Thanks for the help so far!
Dave Syer
@dsyer
May 13 2015 16:33
This is in your proxy though
Is it forwarding those headers to the auth server?
I see. That is the proxied request.
Which only proves what you already said
Collin Peters
@collinpeters
May 13 2015 16:36
hmm... good question. This call is not is not being proxied as it is not /oauth. i.e. it's /login?code=xxx so the call to the auth server is made directly in the code.
Dave Syer
@dsyer
May 13 2015 16:36
Directly how?
Collin Peters
@collinpeters
May 13 2015 16:36
To be clear, starting from the outside, the gateway will proxy /ui/login to the ui server, but /login is not proxied to the oauth server
in the UI server application.yml I have:
accessTokenUri: http://localhost:9999/uaa/oauth/token
userAuthorizationUri: http://localhost:8080/oauth/authorize
So I am thinking here that the userAuthorizationUri is an external redirect so it needs to be used
But accessTokenUri can be made directly. This happens in the code right? i.e. it isn't the browser that uses that URL
Dave Syer
@dsyer
May 13 2015 16:38
Yes, uAU is what gets sent to the client
and aTU is a back channel
Collin Peters
@collinpeters
May 13 2015 16:39
so it seems that aTU back channel call is not using x-forwarded-*
Dave Syer
@dsyer
May 13 2015 16:39
It doesn't need to
If it doesn't get a token in the response it failed
You shouldn't be following redirects from /token
Collin Peters
@collinpeters
May 13 2015 16:40
ahh.. yes... so it is just after that call is made that we need to compute the 302 with the x-forwarded-*
Dave Syer
@dsyer
May 13 2015 16:40
(Who would follow it?)
Collin Peters
@collinpeters
May 13 2015 16:40
yeah, no I'm not
sorry for that confusion
Dave Syer
@dsyer
May 13 2015 16:40
The redirect you show above is to the home page
I assume that's s saved request
Collin Peters
@collinpeters
May 13 2015 16:40
the back-channel call is just a regular call, no headers needed, token given in response
somewhere after that when it computes the redirect to the home page it is not using the x-forwarded so it is going to the internal home page. i.e. localhost:8081 intead of localhost:8080/ui
shoot, meetings are starting. I will debug it today and let you know how it goes.
Dave Syer
@dsyer
May 13 2015 16:42
It seems like the login uri handler is not the one sending that 302
Collin Peters
@collinpeters
May 13 2015 16:42
nope
Dave Syer
@dsyer
May 13 2015 16:42
You actually have a token at that point, and an authenticated user
Collin Peters
@collinpeters
May 13 2015 16:42
correct
Dave Syer
@dsyer
May 13 2015 16:42
So Spring Security is trying to find the original request that triggered the authentication
I have to run now as well
Collin Peters
@collinpeters
May 13 2015 16:43
thanks for the help. I'll post my results later
Collin Peters
@collinpeters
May 13 2015 20:19
Ok, I've spent a bit of time stepping through the code and I'll let you know where I'm at.
P.S. Using Spring Security 3.2.7-RELEASE
To recap, this is the final step of the authorization code flow, exchanging a code for a token, then redirecting.

This is in OAuth2ClientAuthenticationProcessingFilter#doFilter. I have verified that the original request from the browser, proxied through to the user server, does contain the correct x-forwarded-* headers.

In doFilter, it makes the call to the auth server to exchange the code for a token.

So this is calling accessTokenUri which for me http://localhost:9999/uaa/oauth/token. This works fine.

At the end of the method it calls successfulAuthentication, this ultimately calls successHandler.onAuthenticationSuccess

successHandler is an instance of SavedRequestAwareAuthenticationSuccessHandler

Here it checks if there is a savedRequest but it is null. So super.onAuthenticationSuccess is invoked, which ultimately gets to #handle

Here is calls determineTargetUrl which ultimately just returns defaultTargetUrl which return "/"

At no point does it look at the x-forwarded-* headers.

That is where I am at. I'm not sure if the SavedRequest should actually be populated and that is why it is failing, or if it just an issue with not calculating the redirect URL correctly

Dave Syer
@dsyer
May 13 2015 21:34
I guess you can set the default login success URL
Instead of "/" you need an absolute URL
Collin Peters
@collinpeters
May 13 2015 21:47
Ok, I can have a look. Most of the stuff I find online about the login success URL is for form based auth.
I guess I should just update my example to use that anyways
do you mean to set that url in the ui server? or auth server?
Dave Syer
@dsyer
May 13 2015 21:48
It's the UI that sends the redirect isn't it?
Collin Peters
@collinpeters
May 13 2015 21:48
yes
Dave Syer
@dsyer
May 13 2015 21:49
The auth server finished its j
ob
Collin Peters
@collinpeters
May 13 2015 21:49
yup. the ui server makes the back channel call, then does the redirect
Dave Syer
@dsyer
May 13 2015 21:50
It's still a vanilla Spring Security problem
Anyone who ever did anything behind a proxy would have seen it
Collin Peters
@collinpeters
May 13 2015 21:52
probably can override the successHandler in OAuth2ClientAuthenticationProcessingFilter
Collin Peters
@collinpeters
May 13 2015 21:58
What is the quickest way to customize that? Just inject it using @Bean in my configuration class?
Collin Peters
@collinpeters
May 13 2015 22:07
nope... that doesn't work. Bean doesn't exist yet.
checketts
@checketts
May 13 2015 23:03
@spencergibb I see the spring-cloud-zookeeper project is coming along nicely. I'm interested in leveraging that. Is it too soon for me to jump on and start playing with it?
Collin Peters
@collinpeters
May 13 2015 23:18
@dsyer - found some perhaps relevent Q's about the proxy in front problem. Most seem to be SSL specific, but perhaps related
http://stackoverflow.com/q/30164516
http://stackoverflow.com/q/24920373
http://stackoverflow.com/q/25455969