Make Sure You Know This About SharePoint 2010 Claims Authentication - Sticky Sessions Are REQUIRED

  • Article

Hey folks, I’m here to tell you that I too now have my own story of getting burned by an anomaly of using claims authentication that I wish would have been clearer to me. This is such a fundamental aspect of deploying it that I want to make sure I call it out front and center here so that the same thing doesn’t happen to you. 

Very simply stated, if you’re using claims authentication, you MUST use affinity in your load balancing solution. TechNet does describe this, but only as a very brief side note, and not in an appropriately convincing fashion. The article is at https://technet.microsoft.com/en-us/library/cc288475.aspx and says this:

Note: If you use SAML token-based authentication with AD FS on a SharePoint Foundation 2010 farm that has multiple Web servers in a load-balanced configuration, there might be an effect on the performance and functionality of client Web-page views. When AD FS provides the authentication token to the client, that token is submitted to SharePoint Foundation 2010 for each permission-restricted page element. If the load-balanced solution is not using affinity, each secured element is authenticated to more than one SharePoint Foundation 2010 server, which might result in rejection of the token. After the token is rejected, SharePoint Foundation 2010 redirects the client to authenticate again back to the AD FS server. After this occurs, an AD FS server might reject multiple requests that are made in a short time period. This behavior is by design, to protect against a denial of service attack. If performance is adversely affected or pages do not load completely, consider setting network load balancing to single affinity. This isolates the requests for SAML tokens to a single Web server.

I’ll take the hit for not noticing this and not taking it more seriously, but I’m blogging about this now so hopefully you won’t have to. I’ve italicized the words in the note that clearly do not give this justice (nor should it be a note for that matter – it should be in big bold letters). If you don’t use affinity you will see some of these kinds of issues occur:

  • You may randomly be redirected back to a login page.
  • You may end up in an authentication loop that causes ADFS to halt the request because of a perceived denial of service (DOS) attack, as the note states.
  • If you look at a trace of the activity, you may see SharePoint setting your fedauth cookie to an expired value, then start making the requests again to ADFS, which then, for reasons which are still unclear to me, either won’t issue you a non-expired cookie, or SharePoint looks at and transforms it to an expired cookie. That’s what kicks off that DOS cycle I described above. In retrospect now I realize there have been a few cases in the past where folks have asked me about this happening to them, and I realize now that it was probably the lack of sticky sessions that was the culprit.

In short, there should be no confusion or waffling on this issue going forward – for SharePoint 2010, if you are going to use claims authentication, USE AFFINITY WITH YOUR LOAD BALANCER!

UPDATE 6/22/2012 - My friend Mark P. correctly points out that this affinity is required for FBA too, as well as SAML claims. Make sure you are on top of this for both!