Pianificare i metodi di autenticazione degli utenti in SharePoint Server

 

**Si applica a:**SharePoint Server 2013, SharePoint Server 2016

**Ultima modifica dell'argomento:**2018-03-02

Riepilogo: informazioni sulla pianificazione della modalità di utilizzo dei vari metodi di autenticazione degli utenti per creare un'esperienza sicura con le applicazioni Web in SharePoint Server 2013 e SharePoint Server 2016.

Tipi e metodi di autenticazione utente supportati in SharePoint Server e come determinare quali utilizzare per le aree e le applicazioni Web.

Contenuto dell'articolo:

• Introduzione

• Autenticazione basata sulle attestazioni

• Tipi e metodi di autenticazione supportati

• Pianificazione dell'autenticazione di Windows

• Pianificazione dell'autenticazione basata su moduli

• Pianificazione dell'autenticazione basata su token SAML

• Pianificazione delle aree per le applicazioni Web

Introduzione

L'autenticazione utente è la convalida dell'identità di un utente tramite un provider di autenticazione, ovvero una directory o un database contenente le credenziali dell'utente e in grado di confermare se tali credenziali sono state inviate correttamente dall'utente. Un esempio di provider di autenticazione è rappresentato da Servizi di dominio Active Directory. Altri termini relativi al provider di autenticazione sono directory degli utenti e archivio di attributi.

Un metodo di autenticazione è uno scambio specifico di credenziali dell'account e altre informazioni che confermano l'identità di un utente. Il risultato del metodo di autenticazione è la prova, in genere in forma di token contenente attestazioni, che un utente è stato autenticato da un provider di autenticazione.

Un tipo di autenticazione è un modo specifico per convalidare le credenziali tramite uno o più provider di autenticazione, talvolta utilizzando un protocollo standard del settore. Un tipo di autenticazione può prevedere l'utilizzo di più metodi di autenticazione.

Dopo la convalida dell'identità di un utente, tramite il processo di autorizzazione vengono determinati i siti, il contenuto e le altre caratteristiche a cui l'utente può accedere.

Tramite la pianificazione dei metodi e dei tipi di autenticazione utente è necessario determinare gli aspetti seguenti:

• Metodi e tipi di autenticazione utente per ogni area e applicazione Web

• Infrastruttura di autenticazione necessaria per supportare i tipi e i metodi di autenticazione scelti

  Nota

  L’autenticazione di Windows in modalità classica non è più supportata in SharePoint Server 2016.

Autenticazione basata sulle attestazioni

L'identità dell'utente in Servizi di dominio Active Directory è basata su un account utente. Per consentire l'autenticazione, l'utente specifica il nome dell'account e la password. Per determinare l'accesso alle risorse, tramite le applicazioni potrebbe essere necessario eseguire una query in Servizi di dominio Active Directory per gli attributi dell'account e altre informazioni, ad esempio l'appartenenza a gruppi o il ruolo nella rete. Sebbene questa procedura funzioni in modo appropriato negli ambienti Windows, non consente però la scalabilità orizzontale a provider di autenticazione di terze parti e ambienti multi-fornitore che supportano modelli di elaborazione basati su cloud, partner o Internet.

Con le identità basate sulle attestazioni, un utente ottiene un token di sicurezza con firma digitale da un provider di identità comunemente ritenuto attendibile. Il token contiene un insieme di attestazioni. Ogni attestazione rappresenta un elemento specifico di dati relativi a un utente, ad esempio il nome, l'appartenenza a gruppi e il ruolo nella rete. L'autenticazione basata sulle attestazioni è un'autenticazione utente per la quale vengono utilizzate infrastrutture e tecnologie di identità basate sulle attestazioni. Le applicazioni che supportano l'identità basata sulle attestazioni ottengono un token di sicurezza, anziché le credenziali, da un utente e le informazioni nelle attestazioni vengono utilizzate per determinare l'accesso alle risorse. Non sono necessarie query distinte in un servizio directory come Servizi di dominio Active Directory.

L'autenticazione basata sulle attestazioni in Windows si basa su Windows Identity Foundation (WIF), ovvero un set di classi di .NET Framework utilizzate per implementare l'identità basata sulle attestazioni. È inoltre basata su standard quali WS-Federation e WS-Trust e protocolli come SAML (Security Assertion Markup Language).

Per ulteriori informazioni sull'autenticazione basata sulle attestazioni, vedere le risorse seguenti:

• Identità basata sulle attestazioni per Windows (white paper)

• Home page di Windows Identity Foundation

Visto il diffuso utilizzo dell'autenticazione basata sulle attestazioni per l'autenticazione utente, delle app e da server a server, è consigliabile utilizzare l'autenticazione basata sulle attestazioni per tutte le aree e le applicazioni Web di una farm di SharePoint Server. Per ulteriori informazioni, vedere Pianificare l'autenticazione da server a server in SharePoint Server. Quando si utilizza l'autenticazione basata sulle attestazioni, per le applicazioni Web sono disponibili tutti i metodi di autenticazione supportati ed è possibile utilizzare le nuove caratteristiche e i nuovi scenari di SharePoint Server che prevedono l'autenticazione delle app e da server a server.

Per l'autenticazione basata sulle attestazioni, tutti gli account utente vengono convertiti automaticamente da SharePoint Server in identità basate sulle attestazioni. Come conseguenza, viene generato un token di sicurezza, detto anche 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. Gli sviluppatori e gli amministratori di SharePoint possono inoltre incrementare i token utente con ulteriori attestazioni. Gli account utente di Windows e quelli basati su moduli possono ad esempio essere incrementati con ulteriori attestazioni utilizzate da SharePoint Server.

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

Autenticazione in modalità classica in SharePoint Server 2013

In SharePoint 2013, quando si crea un'applicazione Web in Amministrazione centrale, è possibile specificare solo i tipi e i metodi di autenticazione per l'autenticazione basata sulle attestazioni. Nelle versioni precedenti di SharePoint, è possibile anche configurare l'autenticazione in modalità classica per le applicazioni Web in Amministrazione centrale. Per l'autenticazione in modalità classica viene utilizzata l'autenticazione di Windows e gli account utente vengono trattati da SharePoint 2013 come account di Servizi di dominio Active Directory.

Per configurare un'applicazione Web per l'utilizzo dell'autenticazione in modalità classica, è necessario utilizzare il cmdlet New-SPWebApplication PowerShell per la sua creazione. Nelle applicazioni Web di Prodotti SharePoint 2010 configurate per l'autenticazione in modalità classica vengono mantenute le impostazioni di autenticazione quando si esegue l'aggiornamento a SharePoint 2013. È tuttavia consigliabile eseguire la migrazione delle applicazioni Web all'autenticazione basata sulle attestazioni prima di eseguire l'aggiornamento a SharePoint 2013.

Una farm di SharePoint 2013 può includere una combinazione di applicazioni Web in cui vengono utilizzate entrambe le modalità. Per alcuni servizi non viene fatta differenza tra account utente tradizionali di Windows e account basati sulle attestazioni di Windows.

Per ulteriori informazioni sull'esecuzione della migrazione prima dell'aggiornamento, vedere Eseguire la migrazione dall'autenticazione in modalità classica a quella basata su attestazioni in SharePoint 2013.

Per ulteriori informazioni sull'esecuzione della migrazione dopo l'aggiornamento, vedere Eseguire la migrazione dall'autenticazione in modalità classica a quella basata su attestazioni in SharePoint 2013.

Per ulteriori informazioni su come creare applicazioni Web in cui viene utilizzata l'autenticazione in modalità classica in SharePoint 2013, vedere Creare applicazioni web che utilizzano l'autenticazione in modalità classica in SharePoint Server. Si noti che non è possibile eseguire la migrazione di un'applicazione Web in cui viene utilizzata l'autenticazione basata sulle attestazioni in modo da utilizzare l'autenticazione in modalità classica.

Tipi e metodi di autenticazione supportati

In SharePoint Server sono supportati diversi metodi e provider di autenticazione per i tipi di autenticazione seguenti:

• Autenticazione di Windows

• Autenticazione basata su moduli

• Autenticazione basata su token SAML

Autenticazione di Windows

Il tipo di autenticazione di Windows prevede l'utilizzo del provider di autenticazione di Windows esistente (Servizi di dominio Active Directory) e dei protocolli di autenticazione utilizzati da un ambiente di dominio di Windows per convalidare le credenziali dei client che eseguono la connessione. Il metodo di autenticazione di Windows, utilizzato dall'autenticazione basata sulle attestazioni, include quanto segue:

• NTLM

• Kerberos

• Del digest

• Di base

Per ulteriori informazioni, vedere Pianificazione dell'autenticazione di Windows in questo articolo.

Video sull'autenticazione delle attestazioni di Windows in SharePoint 2013 e SharePoint Server 2016

In SharePoint Server è supportata anche l'autenticazione anonima, sebbene non si tratti di un tipo di autenticazione di Windows. Gli utenti possono accedere al contenuto di SharePoint senza convalidare le proprie credenziali. L'autenticazione anonima è disabilitata per impostazione predefinita. In genere, l'autenticazione anonima viene utilizzata quando si utilizza SharePoint Server per pubblicare contenuto che non richiede sicurezza e che è disponibile per tutti gli utenti, ad esempio per un sito Web Internet pubblico.

Si noti che oltre ad abilitare l'autenticazione anonima, è anche necessario configurare l'accesso anonimo (autorizzazioni) nei siti e nelle risorse dei siti.

Autenticazione basata su moduli

L'autenticazione basata su moduli è un sistema di gestione dell'identità basato sulle attestazioni che si basa sull'autenticazione dei provider di ruoli e di appartenenze ASP.NET. L'autenticazione basata su moduli può essere utilizzata facendo riferimento a credenziali archiviate in un provider di autenticazione, ad esempio i seguenti:

• Servizi di dominio Active Directory

• Un database, ad esempio un database di SQL Server

• Un archivio dati LDAP (Lightweight Directory Access Protocol), come Novell eDirectory, Novell Directory Services (NDS) o Sun ONE

Tramite l'autenticazione basata su moduli gli utenti vengono convalidati in base alle credenziali digitate in un modulo di accesso (in genere una pagina Web). Le richieste non autenticate vengono reindirizzate a una pagina di accesso, in cui l'utente deve specificare credenziali valide e inviare il modulo. Per le richieste autenticate viene emesso dal sistema un cookie contenente una chiave che consente di ristabilire l'identità per le richieste successive.

Video sull'autenticazione basata su moduli in SharePoint 2013 e SharePoint Server 2016

Per ulteriori informazioni, vedere Pianificazione dell'autenticazione basata su moduli.

Autenticazione basata su token SAML

Per l'autenticazione basata su token SAML in SharePoint Server vengono utilizzati il protocollo SAML 1.1 e WS-Federation Passive Requestor Profile (WS-F PRP). Per questa autenticazione è necessario coordinarsi con gli amministratori dell'ambiente basato sulle attestazioni, sia esso interno o di un partner. Se si utilizza Active Directory Federation Services (ADFS) 2.0, si dispone di un ambiente di autenticazione basato su token SAML.

Un ambiente di autenticazione basato su token SAML include un servizio token di sicurezza di provider di identità. Tramite questo servizio vengono emessi token SAML per conto degli utenti i cui account sono inclusi nel provider di autenticazione associato. I token possono includere un numero qualsiasi di attestazioni relative a un utente, ad esempio un nome utente e i gruppi a cui l'utente appartiene. Un server ADFS 2.0 è un esempio di servizio token di sicurezza di provider di identità.

In SharePoint Server vengono utilizzate le attestazioni incluse nei token emessi da un servizio token di sicurezza di provider di identità per gli utenti autorizzati. 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. In SharePoint Server 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ò rappresentare più voci del servizio token di sicurezza Relying Party nel servizio token di sicurezza di provider di identità.

Video sull'autenticazione basata su SAML in SharePoint 2013 e SharePoint Server 2016

L'insieme di provider di autenticazione per l'autenticazione basata su token SAML dipende dal servizio token di sicurezza di provider di identità nell'ambiente basato su attestazioni. Se si utilizza ADFS 2.0, i provider di autenticazione (noti come archivi di attributi per ADFS 2.0) possono includere i seguenti:

• Windows Server 2003 Active Directory e Servizi di dominio Active Directory in Windows Server 2008

• Tutte le edizioni di SQL Server 2005 e SQL Server 2008

• Archivi di attributi personalizzati

Per ulteriori informazioni, vedere Pianificazione dell'autenticazione basata su token SAML.

Scelta dei tipi di autenticazione per gli ambienti LDAP

L'autenticazione basata su moduli o l'autenticazione basata su token SAML consente l'utilizzo di ambienti LDAP. È consigliabile utilizzare il tipo di autenticazione corrispondente all'ambiente LDAP corrente. Se non si dispone già di un ambiente LDAP, è consigliabile utilizzare l'autenticazione basata su moduli perché meno complessa. Se tuttavia nell'ambiente di autenticazione sono già supportati WS-Federation 1.1 e SAML 1.1, è consigliabile utilizzare SAML. In SharePoint Server è disponibile un provider LDAP predefinito.

Pianificazione dell'autenticazione di Windows

Il processo di pianificazione e implementazione dei metodi di autenticazione di Windows è simile all’autenticazione basata sulle attestazioni. L'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 di pianificazione per i metodi di autenticazione di Windows.

NTLM e protocollo Kerberos

Sia il protocollo Kerberos che NTLM sono metodi di autenticazione integrata di Windows che consentono agli utenti di effettuare l'autenticazione senza problemi, senza che vengano richieste le credenziali. Ad esempio:

• Gli utenti che accedono ai siti di SharePoint da Internet Explorer utilizzano, per l'autenticazione, le credenziali con cui è in esecuzione il processo di Internet Explorer. Per impostazione predefinita, si tratta delle stesse credenziali utilizzate dall'utente per accedere al computer.

• Nei servizi o nelle applicazioni in cui vengono utilizzati i metodi di autenticazione integrata di Windows per accedere alle risorse di SharePoint viene eseguito un tentativo di utilizzare, per l'autenticazione, 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 e in genere non richiede configurazioni aggiuntive o un'infrastruttura di autenticazione. È sufficiente selezionare questa opzione quando si crea o si configura l'applicazione Web.

Il protocollo Kerberos 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.

I motivi per cui considerare la possibilità di utilizzare l'autenticazione Kerberos sono i seguenti:

• Kerberos è il protocollo di autenticazione integrata di Windows più sicuro e supporta caratteristiche di sicurezza avanzate, tra cui la crittografia AES (Advanced Encryption Standard) e l'autenticazione reciproca di client e server.

• Il protocollo Kerberos consente la delega delle credenziali client.

• Di tutti i metodi di autenticazione sicura disponibili, Kerberos richiede la quantità minore di traffico di rete verso i controller di dominio Servizi di dominio Active Directory. Kerberos può ridurre la latenza delle pagine in alcuni scenari o aumentare il numero di pagine che un server Web front-end può gestire in determinati scenari. Kerberos può inoltre ridurre il carico nei controller di dominio.

• Kerberos è un protocollo aperto supportato da molte piattaforme e numerosi fornitori.

I motivi per cui l'autenticazione Kerberos potrebbe non essere appropriata sono i seguenti:

• Rispetto agli altri metodi di autenticazione, per un corretto funzionamento l'autenticazione Kerberos richiede ulteriori passaggi di configurazione dell'infrastruttura e dell'ambiente. In molti casi, per configurare il protocollo Kerberos è necessaria l'autorizzazione di amministratore del dominio. L'autenticazione Kerberos può risultare complessa da impostare e gestire. Una configurazione errata di Kerberos può impedire la corretta autenticazione nei siti.

• L'autenticazione Kerberos richiede la connettività del computer client a un Centro distribuzione chiavi e a un controller di dominio Servizi di dominio Active Directory. In una distribuzione di Windows, il Centro distribuzione chiavi è un controller di dominio Servizi di dominio Active Directory. Questa è una configurazione di rete comune in una rete Intranet di un'organizzazione, mentre le distribuzioni con connessione Internet in genere non sono configurate in questo modo.

Nei passaggi seguenti viene riepilogata la procedura di configurazione dell'autenticazione Kerberos:

1. Configurare l'autenticazione Kerberos per le comunicazioni di SQL Server creando nomi dell'entità servizio in Servizi di dominio Active Directory per l'account di servizio di SQL Server.

2. Creare nomi dell'entità servizio per le applicazioni Web in cui verrà utilizzata l'autenticazione Kerberos.

3. Installare la farm di SharePoint Server.

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

5. Creare le applicazioni Web in cui verrà utilizzata l'autenticazione Kerberos.

Autenticazione del digest e di base

Con il metodo di autenticazione del digest, le credenziali dell'account utente vengono inviate come digest del messaggio MD5 al servizio Internet Information Services (IIS) nel server Web che ospita l'area o l'applicazione Web. Con il metodo di autenticazione di base, le credenziali dell'account utente vengono inviate come testo non crittografato, pertanto non è consigliabile utilizzare questa autenticazione a meno che non si utilizzi anche SSL per crittografare il traffico del sito Web.

Potrebbe essere necessario utilizzare questi metodi di autenticazione precedenti se nell'ambiente sono utilizzati servizi o Web browser che supportano solo l'autenticazione di base o del digest per i siti Web.

A differenza dei metodi di autenticazione NTLM, Kerberos e anonima, i metodi di autenticazione di base e del digest vengono configurati dalle proprietà del sito Web che corrisponde all'area o all'applicazione Web nello snap-in Internet Information Services (IIS).

Se si utilizza l'autenticazione basata sulle attestazioni, vedere gli articoli seguenti:

• Configurare l'autenticazione del digest per un'applicazione web basata sulle attestazioni in SharePoint Server

• Configurare l'autenticazione di base per un'applicazione web basata sulle attestazioni in SharePoint Server

Pianificazione dell'autenticazione basata su moduli

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. In SharePoint Server 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. 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, è 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 le procedure dettagliate di configurazione dell'autenticazione basata su moduli, vedere Configurare l'autenticazione basata su moduli per un'applicazione Web basata sulle attestazioni in SharePoint 2013

Pianificazione dell'autenticazione basata 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 consente di creare 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 in cui viene utilizzata l'autenticazione basata sulle attestazioni, incluse l'autenticazione di Windows, l'autenticazione basata su moduli e l'autenticazione basata su token SAML.

• Certificato per la firma di token (ImportTrustCertificate) Questo certificato viene esportato da un servizio token di sicurezza di provider di identità e quindi copiato in un server della farm e aggiunto all'elenco di autorità radice attendibili della farm. Dopo aver utilizzato il certificato per creare un oggetto SPTrustedIdentityTokenIssuer, non è possibile riutilizzarlo per crearne un altro. Per utilizzare il certificato per creare un altro oggetto SPTrustedIdentityTokenIssuer, è necessario eliminare prima l'oggetto esistente. Prima di eliminare un oggetto esistente, è necessario annullare l'associazione a tutte le applicazioni Web da cui potrebbe essere utilizzato.

• 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. Possono includere ruoli utente, gruppi di utenti o altri tipi di attestazioni come l'età. 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. È possibile aggiungere ulteriori aree di autenticazione dopo aver creato l'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'identificatore dell'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à ed eventuali attestazioni aggiuntive. È possibile associare a un oggetto SPTrustedIdentityTokenIssuer solo un certificato per la firma di token di un servizio token di sicurezza. 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 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 token SAML di SharePoint Server.

Architettura delle attestazioni dei token SAML

L'oggetto SPTrustedIdentityTokenIssuer viene creato con più parametri, tra cui:

• Un'unica attestazione d'identità.

• Un unico parametro SignInURL.

  Il parametro SignInURL specifica l'URL a cui reindirizzare una richiesta utente per l'autenticazione nel servizio token di sicurezza di provider di identità.

• Un unico parametro Wreply.

  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à.

• Più aree di autenticazione.

• Più mapping di attestazioni.

Per implementare l'autenticazione basata su token SAML con SharePoint Server sono necessari i passaggi seguenti, che richiedono una pianificazione avanzata:

1. Esportare il certificato per la firma di token dal servizio token di sicurezza di provider di identità. Copiare il certificato in un server nella farm di SharePoint Server.

2. Definire l'attestazione che verrà utilizzata come identificatore univoco dell'utente. Questo processo è conosciuto come attestazione d'identità. Come identificatore dell'utente viene spesso utilizzato il nome dell'entità utente o l'alias di posta elettronica dell'utente. 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 Microsoft PowerShell.

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

4. Utilizzare PowerShell per creare un nuovo provider di autenticazione per l'importazione del 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. Configurare un'applicazione Web di SharePoint nuova o esistente per l'utilizzo del provider di autenticazione appena creato. Il provider di autenticazione viene visualizzato come provider di identità attendibile in Amministrazione centrale quando si crea un'applicazione Web.

È possibile configurare più provider di autenticazione basata su token SAML. Un certificato per la firma di token può tuttavia essere utilizzato solo una volta in una farm. Tutti i provider configurati vengono 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 unidirezionale dal servizio token di sicurezza di provider di identità interno al servizio token di sicurezza del partner. Questo approccio non richiede l'aggiunta di un provider di autenticazione alla farm di SharePoint Server e consente inoltre agli amministratori delle attestazioni di gestire l'intero ambiente basato sulle attestazioni.

Per le procedure dettagliate per la configurazione dell'autenticazione basata su token SAML tramite ADFS, vedere Configurare l'autenticazione delle attestazioni basata su SAML con ADFS in SharePoint 2013.

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 si crea un'applicazione Web, in Amministrazione centrale viene creata l'area predefinita. Per creare aree aggiuntive, estendere l'applicazione Web e selezionare uno dei nomi di area restanti: Intranet, Extranet, Internet o Personalizzata.

La pianificazione delle aree dipende dagli aspetti seguenti:

• Autenticazione basata sulle attestazioni (consigliata): è possibile 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 implementa più di un metodo di autenticazione, è consigliabile implementare metodi di autenticazione multipli nell'area predefinita. In questo modo verrà utilizzato lo stesso URL per tutti gli utenti.

Se si implementano più metodi 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 di base e integrata di Windows. 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. È possibile configurare più provider SAML nella stessa area.

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

Più tipi di autenticazione implementati nell'area predefinita

Nella figura utenti di archivi directory diversi utilizzano lo stesso URL per accedere al sito Web del partner. Un riquadro tratteggiato intorno alle società partner mostra la relazione tra la directory di utenti e il tipo di autenticazione configurato nell'area predefinita.

Pianificazione della ricerca per indicizzazione nel contenuto

Il componente di ricerca per indicizzazione richiede NTLM per accedere al contenuto. È 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 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 viene associata a un nuovo dominio e a un nuovo sito di 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 consentire l'utilizzo di tipi di autenticazione diversi per un sito di collaborazione di partner.

Un'area per ogni tipo di autenticazione

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.