Asegúrese de que sabe esto acerca de la autenticación de notificaciones de SharePoint 2010 - Se REQUIEREN sesiones pegajosas

Artículo original publicado el viernes, 28 de octubre de 2011

Hola, estoy aquí para hablarles que también ahora tengo mi propia historia sobre quemarme por una anomalía del uso de la autenticación de notificaciones que desearía que hubiera estado más clara para mí. Este es un aspecto tan fundamental de su implementación que deseo asegurarme de que lo muevo a primer plano aquí para que no le suceda lo mismo a usted. 

Dicho de una manera simple, si está usando autenticación de notificaciones, DEBE usar afinidad en su solución de equilibrio de carga. TechNet lo describe pero solo como una aclaración muy breve, y no de una manera adecuadamente convincente. El artículo se encuentra en https://technet.microsoft.com/en-us/library/cc288475.aspx y dice lo siguiente:

Nota: si usa la autenticación basada en tokens de SAML con AD FS en una granja de servidores de SharePoint Foundation 2010 con varios servidores web en una configuración equilibrada de carga, podría producirse un efecto en el rendimiento y la funcionalidad de las vistas de página web de cliente. Cuando AD FS ofrece el token de autenticación al cliente, dicho token se envía a SharePoint Foundation 2010 para cada elemento de página restringido con permisos. Si la solución equilibrada de carga no está usando afinidad, cada elemento protegido se autentica a más de un servidor SharePoint Foundation 2010, lo que podría dar lugar al rechazo del token. Una vez se ha rechazado el token, SharePoint Foundation 2010 redirige el clienta para que se autentique de nuevo con el servidor AD FS. Después de que esto ocurra, un servidor AD FS podría rechazar varias solicitudes que se realicen en un breve período de tiempo. Este comportamiento es por diseño, para protegerse frente a una denegación de ataque de servicio. Sin el rendimiento se ve afectado de manera adversa o las páginas no se cargan por completo, piense en configurar el equilibrio de carga de red en una afinidad única. Esto aísla las solicitudes para los tokens SAML a un servidor web único.

Aceptaré las consecuencias por no darme cuenta de esto y por no tomármelo en serio, pero estoy escribiendo en el blog sobre ello ahora por los que, con suerte, no tendrá que hacerlo usted. He dejado en cursiva las palabras de la nota que claramente no le hacen a esto justicia (es más, ni debería ser una nota – debería estar en grandes letras en negrita). Si no usa la afinidad verá que se producen algunos de los siguientes tipos de problemas:

• Se le puede redirigir de manera aleatoria de nuevo a una página de inicio de sesión.
• Puede terminar en un bucle de autenticación que haga que ADFS detenga la solicitud debido a un ataque de denegación de servicio percibido (DoS), como indica la nota.
• Si mira un seguimiento de la actividad, puede ver que SharePoint establece su cookie fedauth en un valor expirado, a continuación, empieza a crear las solicitudes de nuevo a ADFS, que a su vez, por razones que todavía no tengo claras, no le emitirá una cookie no expirada o SharePoint mirará y la transforma en una cookie expirada. Esto es lo que desencadena el ciclo de DOS que he descrito anteriormente. Mirando atrás, ahora me doy cuenta de que ha habido algunos casos en el pasado en los que los usuarios me han preguntado acerca de que les sucedía esto y me doy cuenta ahora de que probablemente se debía a la falta de sesiones pegajosas.

En resumen, no debería haber confusión o palabrería sobre este asunto en el futuro – para SharePoint 2010, si va a usar la autenticación de notificaciones, USE LA AFINIDAD CON SU EQUILIBRADOR DE CARGA!

Esta entrada de blog es una traducción. Puede consultar el artículo original en Make Sure You Know This About SharePoint 2010 Claims Authentication - Sticky Sessions Are REQUIRED