问Zuul - Api网关认证

EN

我们使用Spring会话在Zuul边缘服务器后面的所有服务中复制会话。Zuul将对用户进行身份验证，该用户将填充用户凭据并将经过身份验证的用户插入会话。然后在所有服务之间复制，每个服务负责自己的安全规则和设置。所以说，Zuul所做的就是在春季安全性中查找用户，后端的服务正在强制执行安全规则，因为它们适用于他们的需要。通过这种方式，您可以独立地更改每个服务，从而使网关成为一个简单的代理。

这方面的一个很好的例子是Dave关于Spring安全和一个角JS应用程序的教程。我还发布了与此相关的另一个问题，其中包含了我们如何做到这一点的示例，这可能会有所帮助。

• 网关将位于许多服务的前面。

这里有什么可担心的？

• 有些服务可能公开不需要身份验证的端点。

Security有一个permitAll()访问规则

• 有些服务可能公开需要会话Id的端点，而有些则公开带有令牌的端点“，这是一个任意的不透明值(例如，如果您知道API Gateway/Spring安全性中存在”难以猜测“的url，则下载文件)，您可以配置所有端点并满足其特定的身份验证要求。

您的Zuul代理可以有会话。如果您正在使用SpringSecurityWeb2.0，您可以在每次收到有效的访问令牌时使用OAuth并使用HttpSecurity#sessionManagement().sessionCreationPolicy(...)激活会话来创建会话。将在HTTP响应中放置一个JSESSIONID。

• 如何强制实际的服务团队为每个下游服务提供所需的设置？

我不确定我是否理解这里的问题，您不想在API网关(zuul proxy)级别强制执行安全约束吗？还是试图对代理和目标应用程序进行“安全双重检查”？

• 如何允许在网关中频繁更改身份验证设置(根据服务需求)，而不必停止整个网关？

Zuul允许您在运行时动态添加ZuulRoute，如果您将它用作独立的库，即。包装在Security中，其上下文在启动时被初始化一次.我怀疑您是否能够轻松地在运行时更改安全配置。

编辑注释中OP的精确性:如果您的团队应该负责他们的安全规则，那么拥有一个集中式网关在设计上是一个矛盾。

我对微服务哲学的解释是，每个应用程序都是独立的，并负责其全部功能范围，安全/访问控制是其中的一部分。您可以轻松地在应用程序级别验证令牌(通过调用授权服务器或使用JWT)，每个应用程序定义每个资源所需的范围。Spring已经有了一个OAuth 2.0起动器，或者如果使用“普通”Spring，您可以轻松地创建一个。

这样，您就可以在任何地方(公共云或前提服务器)部署各个应用程序，而不必依赖上游组件来实现安全性，也不必与其他团队同步您的网关配置部署。

API网关是一个很容易的诱惑，但不要忽视风险和约束：

• 你不能保证内部通话的安全
• 您将不得不依赖上游网络组件，并将应用程序的输入视为理所当然。
• 高级访问控制规则可能会成为一个令人头疼的问题:如何获得用户的个人权限，等等
• 您必须与其他团队同步配置更改。