Aspetto fondamentale sull'autenticazione delle attestazioni di SharePoint 2010: le sessioni persistenti sono OBBLIGATORIE

Articolo originale pubblicato venerdì 28 ottobre 2011

Saluti a tutti, vi scrivo perché anch'io ho avuto un'esperienza negativa legata a un'anomalia dell'utilizzo dell'autenticazione delle attestazioni che avrei preferito conoscere meglio. È un aspetto fondamentale della distribuzione e vorrei illustrarlo con chiarezza affinché lo stesso problema non accada anche a voi. 

In parole semplici, se si utilizza l'autenticazione delle attestazioni è NECESSARIO utilizzare l'affinità nella soluzione di bilanciamento del carico. In TechNet questo aspetto è descritto con una breve nota, ma non in modo convincente. Trovate l'articolo a cui mi riferisco all'indirizzo https://technet.microsoft.com/en-us/library/cc288475.aspx e la nota è la seguente:

Nota: L'utilizzo dell'autenticazione basata su token SAML con ADFS in una farm di SharePoint Foundation 2010 con più server Web in una configurazione con carico bilanciato può avere conseguenze sulle prestazioni e la funzionalità delle visualizzazioni delle pagine Web client. Quando ADFS fornisce il token di autenticazione al client, il token viene inviato a SharePoint Foundation 2010 per ogni elemento della pagina con autorizzazioni limitate. Se la soluzione con carico bilanciato non utilizza l'affinità, ogni elemento protetto verrà autenticato in più server di SharePoint Foundation 2010, con un possibile rifiuto del token. Dopo che il token è stato rifiutato, SharePoint Foundation 2010 reindirizza il client per la riautenticazione al server ADFS. Dopo che si è verificato questo evento, è possibile che un server ADFS rifiuti più richieste effettuate in un breve periodo di tempo. Questo comportamento da progettazione garantisce protezione da un attacco Denial of Service. Se le prestazioni subiscono un rallentamento o le pagine non vengono caricate completamente, considerare.

Sarò criticato per non avere notato questo punto e non averlo considerato più seriamente, ma ne scrivo ora per evitare che lo stesso capiti a voi. Ho utilizzato il corsivo per le parole della nota che non danno il giusto peso a questo aspetto, che peraltro non dovrebbe essere illustrato in una nota, ma piuttosto evidenziato in grassetto. Se non si utilizza l'affinità, rileverete alcuni dei tipi di errori indicati di seguito:

• È possibile che si venga reindirizzati casualmente a una pagina di accesso.
• È possibile che si finisca in un ciclo di autenticazione a causa del quale la richiesta verrà bloccata da ADFS per il rilevamento di un attacco Denial of Service, come indicato nella nota.
• Se osservate una traccia dell'attività, noterete che in SharePoint il cookie FedAuth è stato impostato su un valore scaduto, quindi vengono nuovamente effettuate le richieste ad ADFS; a questo punto, per motivi che ancora non mi sono chiari, un cookie non scaduto non viene rilasciato da ADFS oppure tale cookie viene trasformato da SharePoint in un cookie scaduto. Questa condizione avvia il ciclo DOS che ho descritto sopra. Mi rendo conto ora che in passato alcuni utenti mi avevano chiesto informazioni su questa situazione e adesso so che, probabilmente, la causa era la mancanza di sessioni persistenti.

In conclusione, non ci dovrebbe più essere confusione su questo problema d'ora in avanti. Se utilizzate l'autenticazione delle attestazioni per SharePoint 2010, UTILIZZATE L'AFFINITÀ CON IL BILANCIAMENTO DEL CARICO!

Questo è un post di blog localizzato. Consultate l'articolo originale: Make Sure You Know This About SharePoint 2010 Claims Authentication - Sticky Sessions Are REQUIRED