带有 OpenId Connect 的 Azure 流量管理器答案

【问题标题】：Azure Traffic Manager with OpenId Connect带有 OpenId Connect 的 Azure 流量管理器
【发布时间】：2019-09-11 23:45:51
【问题描述】：

我有一个使用 OpenId-Connect 强制执行身份验证的 Azure 云服务 (abc.cloudapp.net)。最近，出于维护原因，我决定将它放在流量管理器 (abc.trafficmanager.net) 后面。在阅读了how Traffic Manager works on Microsoft docs 之后，我的理解（根据下面的流程图）是，当有人点击 TM 时，它会简单地为我的云服务进行 DNS 查找并返回一个位置为 abc.cloudapp 的 302。 net（或IP可能），然后客户端遵循重定向。文档清楚地说明了这一点：

最重要的一点是流量管理器在 DNS 级别工作。流量管理器使用 DNS 根据流量路由方法的规则将客户端定向到特定的服务端点。客户端直接连接到选定的端点。流量管理器不是代理或网关。流量管理器看不到客户端和服务之间传递的流量。

但我（通过 Fiddler/Chrome 开发工具）看到的是 TM 似乎正在命中实际的云服务端点，从而导致身份验证问题，因为我的云服务中的重定向 URL 与 TM URL 不匹配等等.

TM 应该这样做吗？还是我在这里遗漏了一些重要的东西。下面是一个相关的线程。

RequireNonce is 'true' (default) but validationContext.Nonce is null in Azure Traffic Manager , OpenIdConnectAuthentication

【问题讨论】：

标签： azure openid-connect azure-traffic-manager

【解决方案1】：

流量管理器在 DNS 级别运行，没有 302，因为它不使用 HTTP 运行。当客户端对您的域名进行 DNS 查询时，流量管理器将返回一个 DNS 回复，表明该服务在那边。

然后，客户端将使用流量管理器提供的 IP 地址连接到流量管理器 URL/您的自定义域。

所以用户看到的 URL 不会改变，流量管理器只是告诉他们服务在哪里。

【讨论】：

感谢朱纳斯的回答。我想我错过了字里行间的阅读。现在它更有意义了。那么如果是这种情况，是否所有不同的云服务端点都应该将流量管理器 URL 指定为 openId-Connect 的重定向 URL？在这种情况下，直接使用它们将不起作用。
哦，好问题。如果您现在可以确定客户端将在下一次请求时再次连接到相同的云服务，那么每次都使用 TM 端点应该没问题。实际上，您可能可以帮助确保在流量管理器上具有良好的 TTL，这样客户端甚至不会在身份验证完成之前询问服务在哪里。