原文发布于 2011 年 10 月 28 日(星期五)

大家好,在这里我想说的是,最近我也亲身经历了一件倒霉事,这是由不按规则使用声明身份验证导致的,我多么希望我当时更清楚地了解这一点。这是部署声明身份验证时非常基本的一个问题,所以在这里我想强调一下,以便您不会遇到相同的问题。

简单地说,如果使用声明身份验证,则必须在负载平衡解决方案中使用相关性。TechNet 中说明了这个问题,但只是作为简单的旁注,并且语气不是特别强烈。这篇文章位于 http://technet.microsoft.com/zh-cn/library/cc288475.aspx,其中是这样阐述的:

注意:如果您在负载平衡配置中具有多台 Web 服务器的 SharePoint Foundation 2010 服务器场上结合 AD FS 使用基于 SAML 令牌的身份验证,则可能 会对客户端网页视图的性能和功能产生影响。当 AD FS 向客户端提供身份验证令牌时,将针对每个权限受限的页面元素将该令牌提交到 SharePoint Foundation 2010。如果负载平衡解决方案不使用相关性,则会向多台 SharePoint Foundation 2010 服务器验证每个安全元素,这可能 导致令牌被拒绝。令牌被拒绝后,SharePoint Foundation 2010 会重定向客户端以便重新验证到 AD FS 服务器。一旦出现这种情况,AD FS 服务器可能 会拒绝在短时间内发出的多个请求。这种行为是设计使然,以阻止拒绝服务攻击。如果性能受到不利影响或者页面无法完全加载,请考虑 将网络负载平衡设置为单个相关性。这可以将对 SAML 令牌的请求隔离到单个 Web 服务器。

我没有注意到这一点,也没有特别重视这个问题,所以得到了教训,但是我将通过博客与大家分享这个教训,希望您不会遇到同样的问题。我用斜体标出了“注意”中的一些词,它们很明显与事实不符(这个问题也不应该通过“注意”来阐述,应该采用鲜明的粗体字)。如果不使用相关性,则遇到下面某些类型的问题:

  • 可能会随机将您重定向回登录页。
  • 您可能会陷入身份验证循环中,从而导致 ADFS 因感知的拒绝服务 (DOS) 攻击而终止请求,就像“注意”中所描述的那样。
  • 如果查看活动的跟踪记录,您可能会发现 SharePoint 将 Fedauth Cookie 设置为已过期的值,然后开始重新向 ADFS 发出请求,然后,要么是 ADFS 不向您发出未过期的 Cookie,要么是 SharePoint 查看后将它转换为已过期的 Cookie,具体原因我现在依然不太清楚。这就是我上面提到的 DOS 循环开始的原因。回想一下,我现在想起来了,在过去的一些案例中人们向我提到过,他们遇到了这个问题,现在我意识到可能是没有严格遵循操作步骤,这是问题所在。

简而言之,关于出现的这个问题,毫无疑问也无需多言 – 对于 SharePoint 2010,如果要使用声明身份验证,一定要对负载平衡解决器使用相关性

这是一篇本地化的博客文章。请访问 Make Sure You Know This About SharePoint 2010 Claims Authentication - Sticky Sessions Are REQUIRED 以查看原文