Partager via

Utilizzo delle attestazioni SAML in SharePoint 2010 con siti in modalità intestazione host

  • Article

Articolo originale pubblicato domenica 19 giugno 2011

Qualcuno ha sollevato l'interessante quesito se fosse possibile utilizzare le attestazioni SAML con siti in modalità host in SharePoint 2010. Istintivamente la mia risposta è stata affermativa, ma ho voluto approfondire ulteriormente la questione. In breve la risposta è affermativa, ma non è semplice come ritenevo che fosse inizialmente. Ho creato a scopo esemplificativo un'applicazione Web all'indirizzo https://hh.vbtoys.com e due siti in modalità intestazione host: https://ash.vbtoys.com e https://josh.vbtoys.com. Pur non rispettando interamente il modello classico di siti in modalità intestazione host (ovvero URL di reindirizzamento a microsito), è necessario ricordare che alcune delle restrizioni previste con le attestazioni SAML e SharePoint prevedono che i siti utilizzino SSL. Ho deciso pertanto di semplificare la procedura e di utilizzare un certificato con caratteri jolly anziché creare un certificato SSL con nomi alternativi del soggetto. Questo è sufficiente per dimostrare il funzionamento della soluzione e illustrare la configurazione necessaria, ma indica anche i fattori di cui tenere conto se si desidera utilizzare siti in modalità intestazione host e l'autenticazione SAML.

Ho eseguito pertanto un semplice test iniziale per verificare lo scenario utopistico in cui apportare una sola modifica alla configurazione e fare in modo che tutti i siti in modalità intestazione host continuino a funzionare. Ho effettuato due operazioni:

  1. Ho creato una nuova relying party in ADFS in cui viene utilizzato https://hh.vbtoys.com/_trust/ come endpoint WS-Federation e un URN definito come urn:sharepoint:hh.
  2. Ho aggiunto un'area di autenticazione di provider all'elemento SPTrustedIdentityTokenIssuer esistente come indicato di seguito:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://hh.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:hh")
$ap.Update()

Ho tentato a questo punto di accedere a https://hh.vbtoys.com e non ho riscontrato problemi. Sono riuscito ad accedere al sito senza difficoltà. Nel test reale dello scenario utopistico ho tentato di accedere a https://ash.vbtoys.com. Purtroppo sono stato reindirizzato a un diverso SPTrustedIdentityTokenIssuer. Ritengo che SharePoint abbia effettuato una ricerca nell'elenco delle aree di autenticazione di provider, non abbia trovato https://ash.vbtoys.com e abbia utilizzato pertanto il primo SPTrustedIdentityTokenIssuer del mio elenco.

Non tutto era perduto però... Come potete immaginare, sono riuscito comunque a far funzionare entrambi i miei siti in modalità intestazione host. È stato necessario tuttavia creare quanto segue:

  1. Una nuova relying party in ADFS per ogni raccolta siti in modalità intestazione host.
  2. Una nuova area di autenticazione di provider per ogni raccolta siti in modalità intestazione host. Le aree di autenticazione sono state aggiunte a SPTrustedIdentityTokenIssuer. Ho utilizzato quindi lo stesso comando di PowerShell sopra riportato, modificando soltanto l'URL e l'URN di ognuna. Nell'esempio riportato di seguito indico in che modo ho aggiunto il supporto per https://ash.vbtoys.com:

$ap = Get-SPTrustedIdentityTokenIssuer -identity "ADFS IdP"
$uri = new-object System.Uri("https://ash.vbtoys.com")
$ap.ProviderRealms.Add($uri, "urn:sharepoint:ash")
$ap.Update()

In poche parole, ho aggiunto una nuova relying party e una nuova area di autenticazione di provider (URI e URN) per ogni raccolta siti in modalità intestazione host e quindi sono riuscito ad accedere a ogni sito utilizzando l'autenticazione SAML.

Questo è un post di blog localizzato. L'articolo originale è disponibile in Using SAML Claims in SharePoint 2010 with Host Header Sites.