À savoir sur l’authentification basée sur les revendications SharePoint 2010 - Sessions sticky OBLIGATOIRES

Article d’origine publié le vendredi 28 octobre 2011

Bonjour, je vais vous parler aujourd’hui de la mésaventure qui m’est arrivée à mon tour avec une anomalie liée à l’utilisation de l’authentification basée sur les revendications. C’est un aspect tellement fondamental du déploiement que je veux en parler haut et fort pour qu’il ne vous arrive pas la même chose. 

Très simplement, si vous utilisez l’authentification basée sur les revendications, vous DEVEZ utiliser l’affinité dans votre solution d’équilibrage de charges. TechNet le décrit, mais uniquement sous la forme d’une brève note, et pas de manière particulièrement convaincante. L’article se trouve ici https://technet.microsoft.com/en-us/library/cc288475.aspx et dit ceci :

Remarque : si vous utilisez l’authentification basée sur des jetons SAML avec AD FS sur une batterie de serveurs SharePoint Foundation 2010 possédant plusieurs serveurs Web dans une configuration équilibrée en charge, il peut y avoir un effet sur la performance et la fonctionnalité des affichages de pages Web. Lorsque AD FS fournit le jeton d’authentification au client, celui-ci est soumis à SharePoint Foundation 2010 pour chaque élément de page soumis à autorisation. Si la solution équilibrée en charge n’utilise pas l’affinité, chaque élément sécurisé est authentifié vis-à-vis de plusieurs serveurs SharePoint Foundation 2010, ce qui peut engendrer le rejet du jeton. Une fois le jeton rejeté, SharePoint Foundation 2010 redirige le client pour qu’il se réauthentifie sur le serveur AD FS. Après cela, un serveur AD FS peut rejeter plusieurs demandes qui sont faites au cours d’une brève période. Ce comportement est conçu comme une protection contre les attaques par déni de service. Si la performance s’en trouve affectée ou que les pages ne se chargent pas complètement, envisagez de définir l’équilibrage de charges du réseau en affinité simple. Cela permet d’isoler les demandes de jetons SAML sur un seul serveur Web.

Je prends sur moi de ne pas l’avoir remarqué plus tôt et de ne pas l’avoir pris plus au sérieux, mais j’en parle à présent dans l’espoir que vous n’ayez pas à le faire. J’ai mis en italique les termes de la note qui ne permettent pas de mesurer l’importance de la situation (pas plus que le format de la note n’est approprié – ça devrait être imprimé en majuscules et en gras). Si vous n’utilisez pas l’affinité, des erreurs de ce type se produiront à coup sûr :

• Vous pouvez être redirigé de manière aléatoire vers une page de connexion.
• Vous pouvez vous trouver embarqué dans une boucle d’authentification qui finira avec ADFS mettant fin à la demande en raison d’une perception d’attaque par déni de service, comme le stipule la note.
• Dans le suivi de l’activité, vous pouvez voir SharePoint définir votre cookie fedauth à une valeur expirée, puis commencer à refaire les demandes à ADFS. Ensuite, pour des raisons qui m’échappent encore, soit ADFS ne vous envoie pas un cookie non expiré, soit SharePoint l’analyse et le transforme en un cookie expiré. C’est ce qui déclenche le cycle de déni de service que j’ai décrit plus haut. Rétrospectivement, je réalise maintenant qu’il y a eu des cas dans le passé où des gens m’ont interrogé à ce sujet et que l’explication était probablement le manque de sessions sticky.

En bref, il ne doit plus y avoir aucune confusion ou débat à ce sujet – pour SharePoint 2010, si vous utilisez l’authentification basée sur les revendications, UTILISEZ L’AFFINITÉ AVEC VOTRE ÉQUILIBREUR DE CHARGE !

Ce billet de blog a été traduit de l’anglais. Vous trouverez la version originale de l’article sur Make Sure You Know This About SharePoint 2010 Claims Authentication - Sticky Sessions Are REQUIRED