我的问题是关于使用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）应该路径到“/ login / core” . 相反，我们看到一些cookie（特别是idsrv，idsrv.external和idsrv.partial）路径到“/ Login / core” . 我终于能够将这个问题追踪到一个 Health 检查，这个检查在Prod中每隔30秒ping我们的应用程序，这个套管设置错误（“/ Login / core”） .
看来，当 Health 检查是我们的SSO应用程序收到的初始请求时，idsrv，idsrv.external和idsrv.partial cookie将在所有进一步的请求中 always - 甚至来自其他客户端，浏览器，机器等 - 得到设置到应用程序重新启动之前的错误"/Login/core"路径 .
这意味着在重定向WS-Federation登录期间，由于cookie路径不正确，所有身份验证信息都将丢失 . 尽管在日志中看到用户已成功通过身份验证，但用户未登录（subject.Identity.IsAuthenticated返回false）并且再次呈现登录页面而没有错误消息 .
奇怪的是，即使在那种情况下，idsrv.session和SignInMessage cookie仍然设置为正确的路径，我认为这是因为它们是在身份验证过程中的不同点创建的 . 如果来自我们任何客户端应用程序的请求首先命中SSO应用程序，则为所有cookie设置正确的“/ login / core”路径 .
一旦我能够找出问题的根本原因，就很容易解决 . 我担心的是，这是一个非常明显的漏洞，如果他们设法通过应用程序回收事件或后部署来计算他们错误的请求时间，那么有意或无意地（如我们的情况）可能会取消我们的SSO应用程序 . 我很好奇这是否是围绕IIS中托管的子应用程序的限制，或者是否有其他原因导致这种情况发生 . 我们将非常感谢您对我们如何填充漏洞（在托管它作为兄弟应用程序之外）的任何见解 .