Spring Cloud Zuul Proxy背后的Spring OAuth授权服务器

Question

I am currently developing a application based on a micro service architecture. We use a API-Gateway implemented using Spring Cloud Netfix's Zuul Server to route the requests to our micro services.

To realize single sign on for all our services I am currently working on an OAuth2 server set up using Spring Cloud Security. The server is basically just copy and past of the implementation in Dave Syer's Repo: https://github.com/dsyer/spring-security-angular/tree/master/oauth2/authserver

The main difference is that I want to route the requests to my OAuth server through the Zuul Proxy. This way I will not have to directly expose my OAuth Server and can add and remove Login Server dynamically.

The problem is I do not seam to understand how to correctly configure this setup. When I try to access a protected resource on the OAuth server I am forwarded to the login page. This of course is as expected. But I can not figure out how to set the hostname and port used when forwarding. What I want to happen is the server to forward to an endpoint on the Zuul server that will get proxied back to the OAuth server. (The Zuul API-Gateway should be the only server the client ever talks to. Everything else will be hidden.)

As it is the host and port are read from the HttpServletRequest in LoginUrlAuthenticationEntryPoint . But the request the server sees is the request send by the Zuul proxy. So I am forwarded to an internal IP not an endpoint on the proxy.

I tried to set the URL of the login page in WebSecurityConfigurerAdapter.configure(HttpSecurity) to the absolut URL of my Zuul Proxy. But this just caused my application to complain about too many redirects. (Might have caused a loop there.)

What would be the best way to set this up?

• Do I have to implement some kind of own forwarding strategy by overriding a bean?
• Is there a configuration option I am missing?
• Is my idea itself wrong? (In his answer to How to avoid redirect to another host with Zuul? Dave Syer says you would not normally proxy this but does not explain why.)

Answer 1

Update : POC can be found here https://github.com/kakawait/uaa-behind-zuul-sample

---

Did you try following setup (on zuul server):

zuul:
  routes:
    uaa-service:
      path: /uaa/**
      stripPrefix: false

security:
  # Disable Spring Boot basic authentication
  basic:
    enabled: false
  oauth2:
    sso:
      loginPath: /login
    client:
      accessTokenUri: https://<zuul hostname>/uaa/oauth/token
      userAuthorizationUri: https://<zuul hostname>/uaa/oauth/authorize
      ...

Basically it works on my project only thing I have to do is to disable CSRF protection on /uaa/oauth/token route.

Auth server should be on

server:
  # Use different context-path to avoid session cookie overlapping
  context-path: /uaa

Tested using Spring-Cloud.Brixton.M3

---

Thank to @thomas-letsch , you should tweak you security like following (sample)

public void configure(HttpSecurity http) throws Exception { 
    http.logout().and()
        .antMatcher("/**").authorizeRequests() 
        .antMatchers("/index.html", "/home.html", "/", "/uaa/oauth/**").permitAll() 
        .anyRequest().authenticated().and() 
        .csrf().csrfTokenRepository(getCSRFTokenRepository()).ignoringAntMatchers("/uaa/‌​oauth/token").and() 
        .addFilterAfter(createCSRFHeaderFilter(), CsrfFilter.class); 
} 

Answer 2

As far as I understand your question, spring-cloud-security (for the EnableOauth2Sso part) and spring-cloud (for zuul), this is not possible to proxy the calls to the authorization server using zuul. The main reason being that spring-cloud-security secures the Gateway independently (and before accounting for) Zuul routing's logic.

Which means that the (sample configuration from Dave Syer's OAuth2 example) spring.oauth2.client.* configuration

spring:
  oauth2:
    client:
      accessTokenUri: http://localhost:9999/uaa/oauth/token
      userAuthorizationUri: http://localhost:9999/uaa/oauth/authorize
      clientId: acme
      clientSecret: acmesecret

is considered before allowing any access to the Zuul's routes zuul.routes.*

Moreover this setup enables the client agent to store two Cookies: one for the Gateway and one for the Authorization Server.

I hope this helps.