我想通过Spring Cloud中的Zuul作为API网关引入一些服务。
我对身份验证存在一些设计疑问。身份验证将由Spring Security处理，在servlet过滤器链中位于Zuul之前。
我的担忧：
网关将位于许多服务之前
一些服务可能会公开不需要身份验证的端点
一些服务可能会公开需要Session Id和一些使用令牌的端点，即任意的不透明值（例如，如果您知道一个“难以猜测”的url下载文件） 在API网关/Spring Security中，您可以配置所有端点及其特定的身份验证要求。
在管理API网关方面：
谢谢， Adrian
我们正在使用Spring Session来复制会话，使其在Zuul Edge Server后面的所有服务中同步。 Zuul将对用户进行身份验证，填充用户凭证并将经过身份验证的用户插入会话中。 然后，这将在所有服务之间进行复制，每个服务都负责自己的安全规则和设置。 因此，实际上，Zuul只是在Spring Security中查找用户，而后端的服务正在根据其需求执行安全规则。 这样，您可以独立更改每个服务，使网关成为一个简单的代理。
这种方法的一个很好的例子是Dave Syers关于Spring Security和Angular JS应用程序的教程。 我还发布了另一个相关问题，其中包含我们如何做到这一点的示例，这可能有所帮助。
- 网关将位于许多服务的前面。
这里的问题是什么？
- 一些服务可能会公开不需要身份验证的端点。
Spring Security有一个permitAll()访问规则。
- 一些服务可能会公开需要Session Id和一些带有令牌的端点，这是任意的不透明值（例如，如果您知道“难以猜测”的url，则可以下载文件）。在API Gateway/Spring Security中，您可以配置所有端点及其特定的身份验证要求。
您的Zuul代理可以具有会话。如果您使用Spring Security OAuth 2.0，则可以使用ResourceServerSecurityConfigurer#stateless(false)并通过HttpSecurity#sessionManagement().sessionCreationPolicy(...)激活会话，每次接收到有效访问令牌时都会创建会话。 JSESSIONID Cookie将放置在HTTP响应中。
- 如何强制实际服务团队根据下游服务提供所需的设置？
我不确定我是否理解这个问题，您不想在API Gateway（Zuul代理）级别执行安全约束吗？还是您试图在代理和目标应用程序上都进行“安全双重检查”？
- 如何允许网关中频繁的身份验证设置更改（根据服务需求），而无需停止整个网关？
Zuul允许您在运行时动态添加ZuulRoute，如果您将其用作独立库的话。如果包装在Spring Security中，其上下文在启动时只初始化一次...我怀疑您可以轻松地在运行时更改安全配置。
根据评论中OP的澄清编辑： 如果您的团队应对其安全规则负责，则具有集中式网关是设计上的矛盾。
我对微服务哲学的理解是，每个应用程序都是独立的，并负责其完整的功能范围和安全/访问控制。您可以轻松验证应用程序级别的令牌（通过向授权服务器发出调用或使用JWT），每个应用程序定义每个资源所需的范围。 Spring Cloud已经有一个OAuth 2.0 starter，如果使用“纯”Spring Boot，则可以轻松创建一个。
这样，您可以在任何地方部署单个应用程序（公共云或本地服务器），而无需依赖上游组件进行安全性或同步网关配置部署与其他团队。
API Gateway是一个简单的诱惑，但不要忽视风险和限制：
