Pianificare i metodi di autenticazione (SharePoint Server 2010)

 

Si applica a: SharePoint Foundation 2010, SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo vengono descritti i metodi e le modalità di autenticazione supportati da Microsoft SharePoint Server 2010. Per autenticazione si intende il processo di convalida dell'identità di un utente. Dopo la convalida dell'identità di un utente, il processo di autorizzazione determina i siti, il contenuto e le altre caratteristiche a cui può accedere l'utente. Le modalità di autenticazione determinano il modo in cui vengono utilizzati internamente gli account da SharePoint Server 2010.

Contenuto dell'articolo:

• Modalità di autenticazione: classica o basata sulle attestazioni

• Modalità di autenticazione: classica o basata sulle attestazioni

• Implementazione dell'autenticazione basata su token SAML

• Scelta dell'autenticazione per gli ambienti LDAP

• Implementazione dell'autenticazione basata su token SAML

• Scelta dell'autenticazione per gli ambienti LDAP

• Pianificazione delle aree per le applicazioni Web

• Architettura per i provider basati su token SAML

Metodi di autenticazione supportati

SharePoint Server 2010 supporta i metodi di autenticazione inclusi nelle versioni precedenti e introduce inoltre come opzione l'autenticazione basata su token che utilizza lo standard SAML (Security Assertion Markup Language). Nella tabella riportata di seguito vengono elencati i metodi di autenticazione supportati.

Metodo	Esempi	Note
Windows	NTLM Kerberos Anonima Di base Del digest	L'autenticazione basata su certificati di Windows attualmente non è supportata.
Autenticazione basata su moduli	LDAP (Lightweight Directory Access Protocol) Database SQL o altro database Provider di appartenenze e di ruoli personalizzati o di terze parti
Autenticazione basata su token SAML	Active Directory Federation Services (ADFS) 2.0 Provider di identità di terze parti LDAP (Lightweight Directory Access Protocol)	Supportata solo con SAML 1.1 basato su WS-Federation Passive Requestor Profile.

Modalità di autenticazione: classica o basata sulle attestazioni

In SharePoint Server 2010 è stata introdotta l'autenticazione basata sulle attestazioni, che utilizza Windows Identity Foundation (WIF). È possibile avvalersi di uno qualsiasi dei metodi di autenticazione supportati con l'autenticazione basata sulle attestazioni oppure dell'autenticazione in modalità classica, che supporta l'autenticazione di Windows.

Quando si crea un'applicazione Web, si seleziona una delle due modalità di autenticazione da utilizzare con essa, ovvero la modalità basata sulle attestazioni o la modalità classica.

Se si seleziona la modalità classica, è possibile implementare l'autenticazione di Windows. In questo caso gli account utente verranno gestiti da SharePoint Server 2010 come account di Servizi di dominio Active Directory.

Se si seleziona l'autenticazione basata sulle attestazioni, SharePoint Server 2010 converte automaticamente tutti gli account utente in identità basate sulle attestazioni, generando un token delle attestazioni per ogni utente. Nel token delle attestazioni sono contenute le attestazioni relative all'utente. Gli account di Windows vengono convertiti in attestazioni di Windows. Gli utenti di appartenenza basata su moduli vengono trasformati in attestazioni di autenticazione basata su moduli. Le attestazioni incluse nei token basati su SAML possono essere utilizzate da SharePoint Server 2010. Gli sviluppatori e gli amministratori di SharePoint inoltre possono incrementare i token utente con ulteriori attestazioni. Gli account utente di Windows e quelli basati su moduli ad esempio possono essere incrementati con ulteriori attestazioni utilizzate da SharePoint Server 2010.

Nella tabella riportata di seguito viene riepilogato il supporto dei tipi di autenticazione per ogni modalità di autenticazione.

Tipo	Autenticazione in modalità classica	Autenticazione basata sulle attestazioni
Windows NTLM Kerberos Anonima Di base Del digest	Sì	Sì
Autenticazione basata su moduli LDAP Database SQL o altro database Provider di appartenenze e di ruoli personalizzati o di terze parti	No	Sì
Autenticazione basata su token SAML ADFS 2.0 Windows Live ID Provider di identità di terze parti LDAP	No	Sì

Una farm di SharePoint Server 2010 può includere una combinazione di applicazioni Web basate su entrambe le modalità. I servizi non fanno differenziazioni tra gli account utente di Windows tradizionali e gli account basati sulle attestazioni di Windows. Un utente che appartiene a siti configurati per l'utilizzo di una combinazione di modalità di autenticazione riceverà pertanto risultati di ricerca che includono i risultati di tutti i siti a cui ha accesso, indipendentemente dalla modalità configurata per le applicazioni Web. L'utente non verrà gestito come due account utente diversi, poiché i servizi e le applicazioni di servizio utilizzano le identità basate sulle attestazioni per le comunicazioni tra farm, indipendentemente dalla modalità selezionata per le applicazioni Web e gli utenti.

Gli utenti che appartengono a più archivi utenti riconosciuti dalle applicazioni Web di SharePoint Server vengono gestiti invece come account utente separati, a seconda dell'identità utilizzata per l'accesso.

Le informazioni aggiuntive fornite di seguito consentiranno di scegliere la modalità da utilizzare:

• Per le nuove implementazioni di SharePoint Server 2010, utilizzare l'autenticazione basata sulle attestazioni. Con questa opzione, per le applicazioni Web sono disponibili tutti i tipi di autenticazione supportati. Non esiste alcun motivo pratico per cui scegliere l'autenticazione in modalità classica per le nuove distribuzioni, anche se l'ambiente include solo account di Windows. L'autenticazione di Windows viene implementata comunque, indipendentemente dalla modalità selezionata. Non sono previste operazioni aggiuntive per l'implementazione dell'autenticazione di Windows quando si utilizza la modalità di autenticazione basata sulle attestazioni.

• Se si aggiorna a SharePoint Server 2010 una soluzione di una versione precedente e tale soluzione include solo account di Windows, è possibile utilizzare l'autenticazione in modalità classica, che consente di utilizzare la stessa struttura per le aree e gli URL.

• Se si effettua l'aggiornamento di una soluzione che richiede l'autenticazione basata su moduli, l'unica opzione è l'aggiornamento all'autenticazione basata sulle attestazioni.

Se si effettua l'aggiornamento da una versione precedente a SharePoint Server 2010 e si seleziona l'autenticazione basata sulle attestazioni, tenere conto delle considerazioni seguenti:

• Potrebbe essere necessario aggiornare il codice personalizzato. È questo il caso delle web part o di altro codice personalizzato che utilizza le identità di Windows o si basa su di esse. Se il codice personalizzato utilizza le identità di Windows, implementare l'autenticazione in modalità classica finché non viene aggiornato.

• La migrazione di un numero elevato di utenti di Windows a identità basate sulle attestazioni richiede tempo. Quando si modifica un'applicazione Web passando dall'autenticazione in modalità classica all'autenticazione basata sulle attestazioni durante il processo di aggiornamento, è necessario utilizzare Windows PowerShell per convertire le identità di Windows in identità basate sulle attestazioni. Poiché questo processo può richiedere tempo, ricordarsi durante l'aggiornamento di allocare tempo sufficiente per il completamento di questa attività.

• Con l'autenticazione basata sulle attestazioni attualmente non sono supportati gli avvisi per la ricerca.

L'autenticazione basata sulle attestazioni utilizza WIF. WIF è un insieme di classi .NET Framework utilizzate per implementare l'identità basata sulle attestazioni. L'autenticazione basata sulle attestazioni utilizza standard quali WS-Federation e WS-Trust e protocolli come SAML. Per ulteriori informazioni sull'autenticazione basata sulle attestazioni, vedere le risorse seguenti:

• Identità basata sulle attestazioni per Windows: introduzione ad Active Directory Federation Services 2.0, Windows CardSpace 2.0 e Windows Identity Foundation (white paper) (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=198942&clcid=0x410)

• Home page di Windows Identity Foundation (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=198943&clcid=0x410)

Non è necessario essere un architetto di attestazioni per utilizzare l'autenticazione basata sulle attestazioni in SharePoint Server 2010. Per l'implementazione dell'autenticazione basata su token SAML è necessario tuttavia coordinarsi con gli amministratori del proprio ambiente basato sulle attestazioni, come descritto più avanti in questo articolo.

Implementazione dell'autenticazione di Windows

Il processo di implementazione dei metodi di autenticazione di Windows è simile per entrambe le modalità di autenticazione (classica o basata sulle attestazioni). La scelta dell'autenticazione basata sulle attestazioni per un'applicazione Web non rende più complessa l'implementazione dei metodi di autenticazione di Windows. In questa sezione viene riepilogato il processo relativo a ogni metodo.

Autenticazione integrata di Windows: Kerberos e NTLM

Sia il protocollo Kerberos che NTLM sono metodi di autenticazione integrata di Windows che consentono ai client di effettuare l'autenticazione senza che vengano richieste le credenziali. Gli utenti che accedono ai siti di SharePoint da Esplora risorse effettueranno l'autenticazione con le credenziali utilizzate per l'esecuzione del processo di Internet Explorer. Per impostazione predefinita, queste sono le stesse credenziali utilizzate dall'utente per accedere al computer. I servizi o le applicazioni che accedono a SharePoint Server con la modalità di autenticazione integrata di Windows tenteranno di effettuare l'autenticazione utilizzando le credenziali del thread in esecuzione, che per impostazione predefinita corrisponde all'identità del processo.

NTLM è la forma più semplice di autenticazione di Windows da implementare. È sufficiente selezionare questa opzione quando si crea un'applicazione Web.

Kerberos invece è un protocollo sicuro che supporta l'autenticazione tramite ticket. Se si utilizza il protocollo Kerberos, è necessario effettuare ulteriori attività di configurazione dell'ambiente. Per abilitare l'autenticazione Kerberos, è necessario che i computer client e server dispongano di una connessione trusted al centro distribuzione chiavi del dominio. La configurazione del protocollo Kerberos comporta la configurazione dei nomi dell'entità servizio (SPN, Service Principal Name) in Servizi di dominio Active Directory prima dell'installazione di SharePoint Server 2010.

Nei passaggi riportati di seguito viene riepilogato il processo di configurazione dell'autenticazione Kerberos:

1. Configurare l'autenticazione Kerberos per le comunicazioni con SQL creando nomi SPN in Servizi di dominio Active Directory per l'account del servizio SQL Server.

2. Creare nomi SPN per le applicazioni Web che utilizzeranno l'autenticazione Kerberos.

3. Installare la farm di SharePoint Server 2010.

4. Configurare servizi specifici nella farm per l'utilizzo di account specifici.

5. Creare le applicazioni Web che utilizzeranno l'autenticazione Kerberos.

Per ulteriori informazioni, vedere Pianificare l'autenticazione Kerberos (SharePoint Server 2010).

Per le applicazioni Web con autenticazione basata sulle attestazioni è inoltre necessario configurare la delega vincolata per le attestazioni per il servizio token Windows. La delega vincolata è necessaria per convertire le attestazioni in token di Windows. Per gli ambienti che includono più foreste, è necessaria una relazione di trust bidirezionale tra le foreste per l'utilizzo delle attestazioni per il servizio token Windows. Per ulteriori informazioni su come configurare questo servizio, vedere Configure Kerberos authentication for the claims to Windows token service (SharePoint Server 2010).

L'autenticazione Kerberos consente la delega di credenziali client per l'accesso a sistemi di dati back-end, che richiede ulteriori attività di configurazione in base allo scenario. Nella tabella riportata di seguito vengono forniti alcuni esempi.

Scenario	Configurazione aggiuntiva
Delega dell'identità di un client a un server back-end. Visualizzazione di feed RSS per contenuto autenticato.	Configurare la delega vincolata Kerberos per computer e account di servizio.
Delega di identità per Microsoft SQL Server Reporting Services (SSRS).	Configurare nomi SPN per gli account di SQL Server Reporting Services. Configurare la delega per SQL Server Reporting Services.
Delega di identità per Excel Services in SharePoint.	Configurare la delega vincolata per i server in cui viene eseguito Excel Services. Configurare la delega vincolata per l'account di servizio di Excel Services.

Per ulteriori informazioni su come configurare l'autenticazione Kerberos, inclusi i passaggi di configurazione per scenari comuni, vedere Configurazione dell'autenticazione Kerberos per Prodotti e tecnologie Microsoft SharePoint 2010 (white paper) (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=197178&clcid=0x410).

Autenticazione del digest e di base

Per l'implementazione dell'autenticazione del digest e di base è necessario configurare questi metodi di autenticazione direttamente in Internet Information Services (IIS).

Implementazione dell'autenticazione basata su moduli

L'autenticazione basata su moduli è un sistema di gestione delle identità basato sull'autenticazione dei provider di ruoli e di appartenenze ASP.NET. In SharePoint Server 2010 questo metodo è disponibile solo se si utilizza l'autenticazione basata sulle attestazioni.

L'autenticazione basata su moduli può essere utilizzata con le credenziali archiviate in Servizi di dominio Active Directory, in un database come ad esempio un database di SQL Server o in un archivio dati LDAP come Novell eDirectory, Novell Directory Services (NDS) o Sun ONE. L'autenticazione basata su moduli consente di autenticare gli utenti attraverso la convalida delle credenziali immesse da un modulo di accesso. Le richieste non autenticate vengono reindirizzate a una pagina di accesso, in cui l'utente deve specificare credenziali valide e inviare il modulo. Se la richiesta può essere autenticata, il sistema rilascia un cookie contenente una chiave che consente di ristabilire l'identità per le successive richieste.

Per utilizzare l'autenticazione basata su moduli per autenticare gli utenti in un sistema di gestione delle identità esterno o non basato su Windows, è necessario registrare il provider di appartenenze e il manager dei ruoli nel file Web.config. La registrazione del manager dei ruoli è un nuovo requisito di SharePoint Server 2010, mentre nella versione precedente è facoltativo. In SharePoint Server 2010 viene utilizzata l'interfaccia del manager dei ruoli ASP.NET standard per raccogliere informazioni sul gruppo dell'utente corrente. Ogni ruolo ASP.NET viene gestito come un gruppo di dominio dal processo di autorizzazione in SharePoint Server 2010. La registrazione dei manager dei ruoli nel file Web.config viene eseguita in modo analogo a quella dei provider di appartenenze per l'autenticazione.

Se si desidera gestire i ruoli o gli utenti di appartenenza dal sito Web Amministrazione centrale SharePoint, è necessario registrare il provider di appartenenze e il manager dei ruoli nel file Web.config del sito Web Amministrazione centrale e nel file Web.config dell'applicazione Web che ospita il contenuto.

Per ulteriori informazioni su come configurare l'autenticazione basata su moduli, vedere le risorse seguenti:

• Articolo TechNet: Configurare l'autenticazione basata su moduli per un'applicazione Web basata sulle attestazioni (SharePoint Server 2010)

• Articolo di blog su MSDN: Scheda di riferimento rapido sull'autenticazione basata sulle attestazioni (parte 1) (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=198944&clcid=0x410)

• Articolo su MSDN: Autenticazione basata su moduli in Prodotti e tecnologie SharePoint (parte 2): esempi di provider di appartenenze e di ruoli (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=198945&clcid=0x410)

Implementazione dell'autenticazione basata su token SAML

Per l'autenticazione basata su token SAML è necessario coordinarsi con gli amministratori dell'ambiente basato sulle attestazioni, sia esso interno o di un partner. ADFS 2.0 è un esempio di ambiente basato sulle attestazioni.

Un ambiente basato sulle attestazioni include un servizio token di sicurezza di provider di identità. Questo servizio rilascia token SAML per conto degli utenti inclusi nella directory di utenti associata. I token possono includere un numero qualsiasi di attestazioni relative a un utente, ad esempio il nome di un utente e i gruppi a cui appartiene.

SharePoint Server 2010 usufruisce delle attestazioni incluse nei token forniti da un servizio token di sicurezza di provider di identità per autorizzare gli utenti. Negli ambienti basati sulle attestazioni un'applicazione che accetta i token SAML è conosciuta come servizio token di sicurezza Relying Party. Un'applicazione Relying Party riceve il token SAML e utilizza le attestazioni in esso contenute per decidere se concedere al client l'accesso alla risorsa richiesta. Nei Prodotti SharePoint 2010 ogni applicazione Web configurata per l'utilizzo di un provider SAML viene aggiunta al server del servizio token di sicurezza di provider di identità come voce separata del servizio token di sicurezza Relying Party. Una farm di SharePoint può includere più voci di servizio token di sicurezza Relying Party.

L'implementazione dell'autenticazione basata su token SAML con i Prodotti SharePoint 2010 prevede l'esecuzione dei processi seguenti che richiedono una pianificazione avanzata:

1. Esportare il certificato per la firma di token dal servizio token di sicurezza di provider di identità. Questo certificato è conosciuto come ImportTrustCertificate. Copiare il certificato in un computer server nella farm di SharePoint Server 2010.

2. Definire l'attestazione che verrà utilizzata come identificatore univoco dell'utente. Questo processo è conosciuto come attestazione d'identità. In molti esempi di questo processo viene utilizzato l'alias di posta elettronica dell'utente come identificatore univoco. Consultarsi con l'amministratore del servizio token di sicurezza di provider di identità per determinare l'identificatore corretto, poiché solo il proprietario di tale servizio conosce il valore del token che sarà sempre univoco per ogni utente. L'individuazione dell'identificatore univoco dell'utente fa parte del processo di mapping delle attestazioni. I mapping delle attestazioni vengono creati utilizzando Windows PowerShell.

3. Definire mapping di attestazioni aggiuntive. Definire quali altre attestazioni del token in ingresso verranno utilizzate dalla farm di SharePoint Server 2010. I ruoli utente sono un esempio di attestazione che può essere utilizzata per le risorse di autorizzazione nella farm di SharePoint Server 2010. Tutte le attestazioni di un token in ingresso prive di mapping verranno ignorate.

4. Creare un nuovo provider di autenticazione utilizzando Windows PowerShell per importare il certificato per la firma di token. Con questo processo viene creato l'oggetto SPTrustedIdentityTokenIssuer. Nel corso del processo è necessario specificare l'attestazione d'identità e le altre attestazioni di cui è stato eseguito il mapping. È inoltre necessario creare e specificare un'area di autenticazione associata alle prime applicazioni Web di SharePoint che vengono configurate per l'autenticazione basata su token SAML. Dopo la creazione dell'oggetto SPTrustedIdentityTokenIssuer, è possibile creare e aggiungere ulteriori aree di autenticazione per altre applicazioni Web di SharePoint. In questo modo vengono configurate più applicazioni Web per l'utilizzo dello stesso oggetto SPTrustedIdentityTokenIssuer.

5. Per ogni area di autenticazione aggiunta all'oggetto SPTrustedIdentityTokenIssuer, è necessario creare una voce del servizio token di sicurezza Relying Party nel servizio token di sicurezza di provider di identità. Questa operazione può essere eseguita prima della creazione dell'applicazione Web di SharePoint. È comunque necessario pianificare l'URL prima della creazione delle applicazioni Web.

6. Creare una nuova applicazione Web di SharePoint e configurarla per l'utilizzo del provider di autenticazione appena creato. Il provider di autenticazione viene visualizzato come opzione in Amministrazione centrale quando viene selezionata la modalità basata sulle attestazioni per l'applicazione Web.

È possibile configurare più provider di autenticazione basata su token SAML. Un certificato per la firma di token tuttavia può essere utilizzato solo una volta in una farm. Tutti i provider configurati verranno visualizzati come opzioni in Amministrazione centrale. Le attestazioni di ambienti di servizi token di sicurezza attendibili diversi non saranno in conflitto.

Se si implementa l'autenticazione basata su token SAML con una società partner e il proprio ambiente include un servizio token di sicurezza di provider di identità, è consigliabile consultarsi con l'amministratore dell'ambiente basato sulle attestazioni interno per stabilire una relazione di trust tra il servizio token di sicurezza di provider di identità interno e il servizio token di sicurezza del partner. Questo approccio non richiede l'aggiunta di un ulteriore provider di autenticazione alla farm di SharePoint Server 2010 e consente inoltre agli amministratori delle attestazioni di gestire l'intero ambiente basato sulle attestazioni.

Nota

L'utilizzo dell'autenticazione basata su token SAML con ADFS in una farm di SharePoint Server 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 Server 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 Server 2010, con un possibile rifiuto del token. Dopo che il token è stato rifiutato, SharePoint Server 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 la possibilità di impostare il bilanciamento del carico di rete sull'affinità singola. In questo modo le richieste di token SAML verranno isolate in un singolo server Web.

Per ulteriori informazioni su come configurare l'autenticazione basata su token SAML, vedere le risorse seguenti:

• Articolo TechNet: Configurare l'autenticazione tramite un token di sicurezza SAML (SharePoint Server 2010)

• Articolo di blog su MSDN: Scheda di riferimento rapido sull'autenticazione basata sulle attestazioni (parte 2) (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=198946&clcid=0x410)

• Articolo di blog su MSDN: Considerazioni sulla pianificazione per l'autenticazione basata sulle attestazioni in SharePoint 2010 (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=198947&clcid=0x410)

• Articolo di blog su TechNet: Creazione di un'attestazione d'identità e di un'attestazione di ruolo per un'applicazione di SharePoint 2010 con autenticazione basata sulle attestazioni (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=198948&clcid=0x410)

• Articolo di blog su TechNet: Creazione di più applicazioni Web con autenticazione basata sulle attestazioni in una singola farm di SharePoint 2010 (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=198949&clcid=0x410)

Scelta dell'autenticazione per gli ambienti LDAP

Gli ambienti LDAP possono essere implementati utilizzando l'autenticazione basata su moduli o l'autenticazione basata su token SAML. È consigliabile utilizzare l'autenticazione basata su moduli perché meno complessa. Se tuttavia l'ambiente supporta WS-Federation 1.1 e SAML Token 1.1, è consigliabile utilizzare SAML. La sincronizzazione dei profili non è supportata con i provider LDAP non associati ad ADFS 2.0.

Pianificazione delle aree per le applicazioni Web

Le aree rappresentano percorsi logici diversi per l'accesso agli stessi siti in un'applicazione Web. Ogni applicazione Web può includere fino a cinque aree. Quando viene creata un'applicazione Web, viene creata anche l'area predefinita. È possibile creare aree aggiuntive estendendo l'applicazione Web e selezionando uno dei nomi di area restanti: Intranet, Extranet, Internet o Personalizzata.

Nelle versioni precedenti le aree vengono utilizzate per implementare tipi diversi di autenticazione per utenti provenienti da reti o provider di autenticazione diversi. Nella versione corrente l'autenticazione basata sulle attestazioni consente di implementare più tipi di autenticazione nella stessa area.

La pianificazione delle aree dipenderà da quale modalità tra quelle elencate di seguito verrà selezionata per un'applicazione Web:

• Modalità classica. Simile alle versioni precedenti, consente di implementare un solo tipo di autenticazione per area. Nella versione corrente tuttavia è possibile implementare solo l'autenticazione di Windows quando viene selezionata la modalità classica. È possibile pertanto utilizzare più aree solo per implementare più tipi di autenticazione di Windows oppure per implementare lo stesso tipo di autenticazione di Windows per archivi Active Directory diversi.

• Autenticazione basata sulle attestazioni. Consente di implementare più provider di autenticazione in una singola area. È inoltre possibile utilizzare più aree.

Implementazione di più tipi di autenticazione in una singola area

Se si utilizza l'autenticazione basata sulle attestazioni e si implementano più tipi di autenticazione, è consigliabile implementare più tipi di autenticazione nell'area predefinita. In questo modo verrà utilizzato lo stesso URL per tutti gli utenti.

Se si implementano più tipi di autenticazione nella stessa area, si applicano le restrizioni seguenti:

• È possibile implementare una sola istanza di autenticazione basata su moduli in un'area.

• Amministrazione centrale consente di utilizzare contemporaneamente i metodi di autenticazione integrata di Windows e di autenticazione di base. In altri casi non è possibile implementare più tipi di autenticazione di Windows in un'area.

Se per una farm sono configurati più provider di autenticazione basata su token SAML, tutti questi provider vengono visualizzati come opzioni quando si crea un'applicazione Web o una nuova area. Nella stessa area possono essere configurati più provider SAML.

Nella figura seguente vengono illustrati più tipi di autenticazione implementati nell'area predefinita per un sito di collaborazione di partner.

Nella figura gli utenti di archivi directory diversi accedono al sito Web partner utilizzando lo stesso URL. Un riquadro tratteggiato intorno alle società partner mostra la relazione tra la directory di utenti e il tipo di autenticazione configurato nell'area predefinita. Per ulteriori informazioni su questo esempio di struttura, vedere Esempio di progettazione: distribuzione aziendale (SharePoint Server 2010).

Pianificazione della ricerca per indicizzazione nel contenuto

Il componente di ricerca per indicizzazione necessita dell'accesso al contenuto tramite NTLM. È necessario pertanto configurare almeno un'area per l'utilizzo dell'autenticazione NTLM. Se l'autenticazione NTLM non è configurata nell'area predefinita, il componente di ricerca per indicizzazione può utilizzare un'altra area configurata per l'utilizzo dell'autenticazione NTLM.

Implementazione di più aree

Se si prevede di implementare più aree per le applicazioni Web, attenersi alle linee guida seguenti:

• Utilizzare l'area predefinita per implementare le impostazioni di autenticazione più sicure. Se non è possibile associare una richiesta a un'area specifica, verranno applicati le impostazioni di autenticazione e altri criteri di sicurezza dell'area predefinita. L'area predefinita viene creata quando si crea inizialmente un'applicazione Web. Le impostazioni di autenticazione più sicure sono in genere definite per l'accesso degli utenti finali. È probabile pertanto che quest'area venga utilizzata per l'accesso da parte degli utenti finali.

• Utilizzare il numero minimo di aree necessarie per consentire l'accesso agli utenti. Ogni area è associata a un nuovo dominio e a un nuovo sito IIS per l'accesso all'applicazione Web. Aggiungere nuovi punti di accesso solo quando sono necessari.

• Verificare che almeno un'area sia configurata per l'utilizzo dell'autenticazione NTLM per il componente di ricerca per indicizzazione. Non creare un'area dedicata per il componente di indicizzazione, a meno che non sia necessario.

Nella figura seguente vengono illustrate diverse aree implementate per l'utilizzo di tipi di autenticazione diversi per un sito di collaborazione di partner.

Nella figura l'area predefinita viene utilizzata per i dipendenti remoti. A ogni area è associato un URL diverso. I dipendenti utilizzano un'area diversa a seconda che lavorino in ufficio o da postazione remota. Per ulteriori informazioni su questo esempio di struttura, vedere Esempio di progettazione: distribuzione aziendale (SharePoint Server 2010).

Architettura per i provider basati su token SAML

L'architettura per l'implementazione di provider basati su token SAML include i componenti seguenti:

Servizio token di sicurezza di SharePoint   Questo servizio crea i token SAML utilizzati dalla farm. Il servizio viene creato e avviato automaticamente in tutti i server di una server farm. Viene utilizzato per le comunicazioni tra farm, poiché per queste comunicazioni viene applicata l'autenticazione basata sulle attestazioni. Questo servizio viene utilizzato inoltre per i metodi di autenticazione implementati per le applicazioni Web che si avvalgono dell'autenticazione basata sulle attestazioni, incluse l'autenticazione di Windows, l'autenticazione basata su moduli e l'autenticazione basata su token SAML. Il servizio token di sicurezza deve essere configurato durante il processo di distribuzione. Per ulteriori informazioni, vedere Configurare il servizio token di sicurezza (SharePoint Server 2010).

Certificato per la firma di token (ImportTrustCertificate)   Questo certificato viene esportato da un servizio token di sicurezza di provider di identità e viene copiato in un server della farm. Dopo aver utilizzato il certificato per creare un oggetto SPTrustedIdentityTokenIssuer, non è possibile riutilizzarlo per crearne un altro. Se si desidera utilizzare il certificato per creare un altro oggetto SPTrustedIdentityTokenIssuer, sarà necessario eliminare prima l'oggetto esistente. Prima di eliminare un oggetto esistente, è necessario annullare l'associazione alle applicazioni Web che possono utilizzarlo.

Attestazione d'identità   Per attestazione d'identità si intende l'attestazione di un token SAML utilizzata come identificatore univoco dell'utente. Solo il proprietario del servizio token di sicurezza di provider di identità conosce quale valore del token sarà sempre univoco per ogni utente. L'attestazione d'identità viene creata come normale mapping delle attestazioni durante il processo di mapping di tutte le attestazioni desiderate. L'attestazione utilizzata come attestazione d'identità viene dichiarata quando viene creato l'oggetto SPTrustedIdentityTokenIssuer.

Altre attestazioni   Queste attestazioni sono costituite da attestazioni aggiuntive di un ticket SAML che descrivono gli utenti. Includono ruoli utente, gruppi di utenti o altri tipi di attestazioni come la durata. Tutti i mapping di attestazioni vengono creati come oggetti replicati nei server di una farm di SharePoint Server.

Area di autenticazione   Nell'architettura delle attestazioni di SharePoint l'URI o l'URL associato a un'applicazione Web di SharePoint configurata per l'utilizzo di un provider basato su token SAML rappresenta un'area di autenticazione. Quando si crea un provider di autenticazione basata su SAML nella farm, è necessario specificare una per volta le aree di autenticazione, o URL delle applicazioni Web, che devono essere riconosciute dal servizio token di sicurezza di provider di identità. La prima area di autenticazione viene specificata quando si crea l'oggetto SPTrustedIdentityTokenIssuer. Altre aree di autenticazione possono essere aggiunte dopo la creazione dell'oggetto SPTrustedIdentityTokenIssuer. Le aree di autenticazione vengono specificate utilizzando una sintassi simile alla seguente: $realm = "urn:sharepoint:mysites". Dopo aver aggiunto l'area di autenticazione all'oggetto SPTrustedIdentityTokenIssuer, è necessario creare una relazione di trust tra il servizio token di sicurezza Relying Party e l'area di autenticazione nel server del servizio token di sicurezza di provider di identità. Per eseguire questo processo è necessario specificare l'URL dell'applicazione Web.

SPTrustedIdentityTokenIssuer   Questo oggetto creato nella farm di SharePoint include i valori necessari per comunicare con il servizio token di sicurezza di provider di identità e ricevere token da esso. Quando si crea l'oggetto SPTrustedIdentityTokenIssuer, è necessario specificare quale certificato per la firma di token utilizzare, la prima area di autenticazione, l'attestazione che rappresenta l'attestazione d'identità e altre eventuali attestazioni aggiuntive. È possibile associare a un oggetto SPTrustedIdentityTokenIssuer solo un certificato per la firma di token di un servizio di sicurezza token. Dopo la creazione dell'oggetto SPTrustedIdentityTokenIssuer, è tuttavia possibile aggiungere ulteriori aree di autenticazione per altre applicazioni Web. Dopo aver aggiunto un'area di autenticazione all'oggetto SPTrustedIdentityTokenIssuer, è inoltre necessario aggiungerla al servizio token di sicurezza di provider di identità come relying party. L'oggetto SPTrustedIdentityTokenIssuer viene replicato nei server della farm di SharePoint Server.

Servizio token di sicurezza Relying Party   In SharePoint Server 2010 ogni applicazione Web configurata per l'utilizzo di un provider SAML viene aggiunta al server del servizio token di sicurezza di provider di identità come voce di servizio token di sicurezza Relying Party. Una farm di SharePoint Server può includere più voci di servizio token di sicurezza Relying Party.

Servizio token di sicurezza di provider di identità   È il servizio token di sicurezza dell'ambiente basato sulle attestazioni che rilascia token SAML per conto degli utenti inclusi nella directory di utenti associata.

Nella figura seguente viene illustrata l'architettura delle attestazioni dei Prodotti SharePoint 2010.

L'oggetto SPTrustedIdentityTokenIssuer viene creato utilizzando diversi parametri. Nella figura seguente vengono illustrati i parametri chiave.

Come illustrato nella figura, un oggetto SPTrustedIdentityTokenIssuer può includere solo un'attestazione d'identità, un parametro SignInURL e un parametro Wreply. Può includere tuttavia più aree di autenticazione e più mapping di attestazioni. Il parametro SignInURL specifica l'URL a cui reindirizzare una richiesta utente per l'autenticazione nel servizio token di sicurezza di provider di identità. Alcuni server del servizio token di sicurezza di provider di identità richiedono il parametro Wreply, che può essere impostato su true o su false. L'impostazione predefinita è false. Utilizzare il parametro Wreply solo se richiesto dal servizio token di sicurezza di provider di identità.