Share via

Impostazione corretta della scadenza dei token di accesso per gli utenti delle attestazioni SAML di SharePoint 2010

  • Article

Impostazione corretta della scadenza dei token di accesso per gli utenti delle attestazioni SAML di SharePoint 2010

Nel tentativo di comprendere il processo per impostare correttamente la scadenza dei cookie di accesso, ho individuato recentemente un problema di una certa entità. Sembra infatti che per gli utenti delle attestazioni SAML non si verifichi mai il timeout dei cookie di accesso ottenuto da ADFS. Questo significa che chiudendo il browser e riaprendolo dopo diversi minuti o addirittura dopo diverse ore, questi utenti possono accedere direttamente al sito senza dover eseguire di nuovo l'autenticazione per ADFS. Le applicazioni client di Office 2010 inoltre funzionano nello stesso modo. Dopo aver finalmente individuato le diverse cause all'origine di questo problema, ho deciso di documentarle in questo post.

È necessaria innanzitutto una brevissima premessa. Al primo accesso a un sito di SharePoint protetto con le attestazioni SAML, un utente viene reindirizzato per essere autenticato e ottenere le attestazioni. Il provider di identità SAML, conosciuto anche come servizio token di sicurezza di provider di identità, esegue questa operazione e quindi reindirizza l'utente a SharePoint. Quando l'utente torna a SharePoint, viene creato un cookie FedAuth, la cui presenza indica che l'autenticazione è stata effettuata. Per semplificare l'esperienza degli utenti finali, il valore del cookie FedAuth viene scritto nella cartella locale dei cookie. Se alle successive richieste per lo stesso sito viene trovato un cookie FedAuth valido per il sito, il cookie viene letto e l'utente accede direttamente al contenuto di SharePoint senza dover rieseguire l'autenticazione. Questa soluzione può risultare sorprendente per gli utenti abituati a utilizzare ADFS 1.x e SharePoint 2007, poiché con questi prodotti tutti i cookie SSO Web sono basati sulla sessione e non vengono salvati su disco. Alla chiusura del browser ad esempio il cookie scompare ed è pertanto necessario eseguire di nuovo l'autenticazione ogni volta che si chiude e si riapre il browser. Il processo è diverso con SharePoint 2010.

AGGIORNAMENTO 1: è stata individuata una modifica che può essere apportata al servizio token di sicurezza di SharePoint in modo da utilizzare di nuovo i cookie di sessione, come in SharePoint 2007. Questa modifica viene apportata in PowerShell, come indicato di seguito:

$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $true
$sts.Update()
iisreset

Dopo aver eseguito questa operazione, non è più presente alcun cookie FedAuth sul disco. Per ripristinare il comportamento predefinito, è sufficiente invertire i passaggi:

$sts.UseSessionCookies = $false
$sts.Update()
iisreset

Per configurare questo comportamento in modo da ottenere un token SAML con una durata gestibile, è necessario tenere conto di quanto segue:

  1. La proprietà TokenLifetime può essere impostata per relying party in ADFS. Sembra purtroppo che sia possibile impostarla solo quando si crea la relying party. Questo è un problema, perché in questo modo il comportamento predefinito prevede che quando si ottiene un cookie, si è autorizzati a procedere per un periodo di tempo lunghissimo (ancora non ho testato la durata effettiva di questo periodo di validità).

AGGIORNAMENTO 2: Rich Harrison ha fornito l'espressione di codice seguente per aggiornare la proprietà TokenLifetime in ADFS per la relying party:

Set-ADFSRelyingPartyTrust -TargetName "SPS 2010 ADFS" -TokenLifetime 5

where "SPS 2010 ADFS" is the name of the Relying Party Trust entity in AD FS 2.0.

Se pertanto si desidera impostare la proprietà TokenLifetime della relying party in ADFS al momento della creazione, è necessario utilizzare PowerShell. Segue il piccolo script di una riga che ho utilizzato per creare la mia relying party:

Add-ADFSRelyingPartyTrust -Name "FC1" -Identifier "https://fc1/_trust/" -WsFedEndpoint "https://fc1/_trust/" -TokenLifetime 2 -SignatureAlgorithm https://www.w3.org/2000/09/xmldsig#rsa-sha1

Dopo aver creato la relying party in questo modo, è necessario eseguire manualmente le operazioni seguenti:

  1. Aggiungere l'area di autenticazione all'elenco di identificatori, ad esempio urn:sharepoint:foo
  2. Aggiungere una regola di autorizzazione rilascio per concedere l'accesso a tutti gli utenti
  3. Aggiungere una regola di trasformazione rilascio per inviare l'indirizzo di posta elettronica e i ruoli

 

  1. Se si tenta semplicemente di accedere ora, è probabile che dopo l'autenticazione in ADFS si verifichi un ciclo infinito in cui si passa da SharePoint ad ADFS e viceversa. Se si esamina il traffico in Fiddler, risulta che l'autenticazione in ADFS viene eseguita correttamente, si torna a SharePoint dove viene rilasciato il cookie FedAuth e si viene reindirizzati a /_trust/authenticate.aspx nel sito di SharePoint, dove viene cancellato il cookie FedAuth e si viene reindirizzati di nuovo al sito di ADFS. Si rimbalza praticamente avanti e indietro finché ADFS non arresta questo ciclo e genera un messaggio di errore in cui viene indicato ad esempio che la stessa sessione del browser client ha effettuato "6" richieste negli ultimi "12" secondi. Questo messaggio effettivamente ha senso. L'impostazione predefinita di LogonTokenCacheExpirationWindow per il servizio token di sicurezza di SharePoint infatti è 10 minuti. In questo caso, quando ho creato la relying party, ho impostato la durata del token in ADFS su 2 minuti. Nel momento in cui è stata effettuata l'autenticazione, il cookie pertanto è risultato valido per un periodo di tempo inferiore al valore impostato per LogonTokenCacheExpirationWindow e quindi si è tornati al sito di ADFS per rieseguire l'autenticazione, con un ciclo infinito. Per ovviare a questo problema, è sufficiente impostare LogonTokenCacheExpirationWindow su un valore inferiore al valore di TokenLifetime di SAML e quindi è possibile accedere al sito. Viene riportato di seguito un esempio di impostazione di LogonTokenCacheExpirationWindow in SharePoint:

$sts = Get-SPSecurityTokenServiceConfig

$sts.LogonTokenCacheExpirationWindow = (New-TimeSpan -minutes 1)

$sts.Update()

Iisreset

 

Dopo aver configurato queste impostazioni correttamente, la scadenza dell'accesso per gli utenti SAML funziona in modo appropriato. È possibile aprire e chiudere la finestra del browser e continuare ad accedere al sito senza essere reindirizzati a SharePoint per la durata di due minuti. Trascorso questo intervallo di tempo, viene rieseguita l'autenticazione in ADFS.

Questo è un post di blog localizzato. L'articolo originale è disponibile in Setting the Login Token Expiration Correctly for SharePoint 2010 SAML Claims Users.