IdentityServer3 - Cookie路径问题

Question

我的问题是关于使用OWIN WS-Federation中间件的IIS托管的IdentityServer 3 SSO应用程序生成的cookie的问题。我们遇到了间歇性的生产问题，这阻碍了登录（和注销）的发生。虽然我已经找到了原因，但我相信这会让我们的SSO容易受到攻击。

IIS设置：

• https://www.example.com - 家长应用（客户端应用）
  • login - 子应用程序（使用OWIN WS-Federation中间件的IDS3应用程序）

（注意：存在其他客户端应用程序，但它们位于其他服务器上）

我们希望从这样的设置中看到的是，Identity Server的cookie（idsrv，idsrv.external，idsrv.partial和idsrv.session）应该走到＆＃34; /登录/核心＆＃34 ;.相反，我们看到了一些cookie（特别是idsrv，idsrv.external和idsrv.partial）路径到＆＃34; / Login / core＆＃34;。我终于能够将问题追踪到健康检查，该检查在Prod中每隔30秒ping我们的应用程序，其中设置了错误的外壳（＆＃34; / Login / core＆＃34;）。

当健康检查是我们的SSO应用程序收到的初始请求时，idsrv，idsrv.external和idsrv.partial cookie会在所有进一步的请求中始终 - 甚至来自其他客户端，浏览器，机器等 - 设置为错误＆＃34; /登录/核心＆＃34;路径直到应用程序重新启动。

这意味着在重定向WS-Federation登录期间，由于cookie路径不正确，所有身份验证信息都会丢失。尽管在日志中看到用户已成功通过身份验证，但用户未登录（subject.Identity.IsAuthenticated返回false）并且再次呈现登录页面而没有错误消息。

奇怪的是，idsrv.session＆amp;即使在那种情况下，SignInMessage cookie仍然设置为正确的路径，我认为这是因为它们是在身份验证过程中的不同点创建的。如果来自我们任何客户端应用程序的请求首先访问SSO应用程序，则正确的＆＃34; / login / core＆＃34;为所有cookie设置路径。

一旦我能够找出问题的根本原因，就很容易解决。我担心的是，这是一个非常明显的漏洞，如果他们设法通过应用程序回收事件或后部署来设置他们错误的请求时间，那么有意或无意地（如我们的情况）可能会取消我们的SSO应用程序。我很好奇这是否是围绕IIS托管的子应用程序的限制，或者是否有其他原因导致这种情况发生。任何关于我们如何插入漏洞的信息（除了作为兄弟应用程序托管之外）都将非常感激。