zuul:
+ routes:
+ api: /api/**
+From cb207320ce67c6b63549a6c64b5a6edf164762c5 Mon Sep 17 00:00:00 2001
From: Dave Syer zuul.route.home:
/ would route all traffic (i.e. "/**") to the "home" service.
You can also run a Zuul server without the proxying, or switch on parts of the proxying platform selectively, if you
+use @EnableZuulServer (instead of @EnableZuulProxy). Any beans that you add to the application of type ZuulFilter
+will be installed automatically.
In this case the routes into the Zuul server are +still specified by configuring "zuul.routes.*", but there is no service discovery and no proxying, so the +"serviceId" and "url" settings are ignored. For example:
+ zuul:
+ routes:
+ api: /api/**
+maps all paths in "/api/**" to the Zuul filter chain.
+How does it work? The @EnableOAuth2Sso annotation pulls in
spring-cloud-starter-security (which you could do manually in a
-traditional app), and that has some autoconfiguration for a
-ZuulFilter, which itself is activated because Zuul is on the
+traditional app), and that in turn triggers some autoconfiguration for
+a ZuulFilter, which itself is activated because Zuul is on the
classpath (via @EnableZuulProxy). The
-filter
+filter
just extracts an access token from the currently authenticated user,
and puts it in a request header for the downstream requests.
You can control the authorization behaviour downstream of an
+@EnableZuulProxy through the proxy.auth.* settings. Example:
proxy:
+ auth:
+ routes:
+ customers: oauth2
+ stores: passthru
+ recommendations: none
+In this example the "customers" service gets an OAuth2 token relay, +the "stores" service gets a passthrough (the authorization header is +just passed downstream), and the "recommendations" service has its +authorization header removed. The default behaviour is to do a token +relay if there is a token available, and passthru otherwise.
+See + +ProxyAuthenticationProperties for full details.
+