Pianificare i metodi di autenticazione degli utenti in SharePoint Server
SI APPLICA A:
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
Nota
I metodi di autenticazione utente indicati qui si applicano a SharePoint Server 2013, SharePoint Server 2016, SharePoint Server 2019 e SharePoint Server Subscription Edition.
Tipi e metodi di autenticazione utente supportati in SharePoint Server e come determinare quali utilizzare per le aree e le applicazioni Web.
Informazioni sull'autenticazione di SharePoint in Microsoft 365.
Nota
In SharePoint Server Subscription Edition è ora supportata l'autenticazione OIDC 1.0. Per altre informazioni su come usare questo nuovo tipo di autenticazione, vedere Autenticazione di OpenID Connect 1.0.
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 asseriscono 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.
La pianificazione per i tipi e i metodi di autenticazione utente deve determinare:
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 in modalità classica di Windows non è più supportata in SharePoint Server 2016, SharePoint Server 2019 e SharePoint Server Subscription Edition.
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. Anche se questa funzionalità funziona bene per gli ambienti Windows, non si adatta ai provider di autenticazione di terze parti e agli ambienti multi-fornitore che supportano modelli di calcolo basati su Internet, partner o cloud.
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 agli utenti, ad esempio i nomi, le appartenenze ai 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:
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. Questa modifica comporta un token di sicurezza (noto anche come token di 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. Inoltre, gli sviluppatori e gli amministratori di SharePoint possono aumentare i token utente con più attestazioni. Ad esempio, gli account utente di Windows e gli account basati su moduli possono essere aumentati con attestazioni aggiuntive usate da SharePoint Server.
Non è necessario essere un architetto delle attestazioni per usare 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à. Alcuni servizi non distinguono tra gli account utente che sono account windows tradizionali e gli account delle attestazioni di Windows.
Per ulteriori informazioni sull'esecuzione della migrazione prima dell'aggiornamento, vedere Eseguire la migrazione dall'autenticazione in modalità classica all'autenticazione basata sulle attestazioni.
Per ulteriori informazioni sull'esecuzione della migrazione dopo l'aggiornamento, vedere Migrate from classic-mode to claims-based authentication in SharePoint Server.
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. Non è possibile eseguire la migrazione di un'applicazione Web che usa l'autenticazione basata sulle attestazioni per usare l'autenticazione in modalità classica.
Importante
[!IMPORTANTE] Office Online può essere utilizzato solo dalle applicazioni Web di SharePoint 2013 che utilizzano l'autenticazione basata sulle attestazioni. Il rendering e la modifica di Office Online non funzioneranno nelle applicazioni Web di SharePoint 2013 che utilizzano l'autenticazione in modalità classica. Se si esegue la migrazione di applicazioni Web di SharePoint 2010 che utilizzano l'autenticazione in modalità classica a SharePoint 2013, è necessario eseguire la migrazione all'autenticazione basata sulle attestazioni per consentire alle applicazioni di funzionare con Office Online.
Tipi e metodi di autenticazione supportati
SharePoint Server supporta diversi metodi di autenticazione 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, usato da entrambe le attestazioni, include:
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 si usa l'autenticazione anonima quando si usa SharePoint Server per pubblicare contenuto che non richiede sicurezza ed è disponibile per tutti gli utenti, ad esempio un sito Web Internet pubblico.
Oltre ad abilitare l'autenticazione anonima, è necessario configurare anche l'accesso anonimo (autorizzazioni) nei siti e nelle risorse del sito.
Nota
[!NOTA] Nei siti Web di Internet Information Services (IIS) che vengono creati da SharePoint per le applicazioni Web, i metodi di autenticazione anonima e di autenticazione moduli sono sempre abilitati, anche quando l'impostazione di SharePoint per questi metodi di autenticazione è disabilitata. Si tratta di un'impostazione intenzionale e la disattivazione dei metodi di autenticazione anonima e moduli direttamente nelle impostazioni di IIS comporterebbe errori nel sito di SharePoint.
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 form può essere usata per le credenziali archiviate in un provider di autenticazione, ad esempio:
Active Directory Domain Services
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 un utente deve fornire 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
Nota
Con l'autenticazione basata su moduli, le credenziali dell'account utente vengono inviate come testo non crittografato. Pertanto, non è consigliabile usare l'autenticazione basata su moduli a meno che non si usi anche SSL (Secure Sockets Layer) per crittografare il traffico del sito Web.
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 usa AD FS 2.0, i provider di autenticazione (noti come archivi attributi per AD FS 2.0) possono includere:
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. Usare il tipo di autenticazione corrispondente all'ambiente LDAP corrente. Se non si dispone già di un ambiente LDAP, è consigliabile usare 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 aumenta la complessità dell'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, queste credenziali sono le credenziali usate 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 alcuna configurazione aggiuntiva dell'infrastruttura di autenticazione. Selezionare questa opzione quando si crea o si configura l'applicazione Web.
Il protocollo Kerberos supporta l'autenticazione tramite ticket. L'uso del protocollo Kerberos richiede una maggiore 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. Anche se questa configurazione di rete è comune in una intranet dell'organizzazione, 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:
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.
Creare nomi dell'entità servizio per le applicazioni Web in cui verrà utilizzata l'autenticazione Kerberos.
Installare la farm di SharePoint Server.
Configurare servizi specifici nella farm per l'utilizzo di account specifici.
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 di messaggi MD5 al servizio Internet Information Services (IIS) nel server Web che ospita l'applicazione Web o l'area. Con il metodo di autenticazione di base, le credenziali dell'account utente vengono inviate come testo non crittografato. Pertanto, non è consigliabile usare il metodo di autenticazione di base a meno che non si usi 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 usa l'autenticazione basata sulle attestazioni, vedere:
Pianificazione dell'autenticazione basata su moduli
Per usare l'autenticazione basata su moduli per autenticare gli utenti in un sistema di gestione delle identità non basato su Windows o esterno, è necessario registrare il provider di appartenenze e il gestore dei ruoli nel file di 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 utenti o ruoli di appartenenza dal sito Web Amministrazione centrale, è necessario registrare il provider di appartenenze e il gestore dei ruoli nel file Web.config per il sito Web Amministrazione centrale. Registrare il provider di appartenenze e il gestore dei ruoli nel file Web.config per l'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 Server
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 crea i token SAML usati dalla farm. Il servizio viene creato e avviato automaticamente in tutti i server di una server farm. Il servizio viene usato per la comunicazione tra farm perché tutte le comunicazioni tra farm usano l'autenticazione basata sulle attestazioni. Questo servizio viene usato anche per i metodi di autenticazione implementati per le applicazioni Web che usano l'autenticazione basata sulle attestazioni. Questi metodi includono l'autenticazione di Windows, l'autenticazione basata su form e l'autenticazione basata su token SAML.
Certificato di firma del token (ImportTrustCertificate) Questo certificato è quello esportato da un servizio token di sicurezza IP, quindi copiato in un server della farm e aggiunto all'elenco Autorità radice attendibile della farm. Dopo aver usato questo certificato per creare un SPTrustedIdentityTokenIssuer, non è possibile usarlo 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 da 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 usando 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 SPTrustedIdentityTokenIssuer, si specifica il certificato di firma del token da usare, la prima area di autenticazione, l'attestazione che rappresenta l'attestazione identity e qualsiasi altra attestazione. È possibile associare a un oggetto SPTrustedIdentityTokenIssuer solo un certificato per la firma di token di un servizio token di sicurezza. Tuttavia, dopo aver creato SPTrustedIdentityTokenIssuer, è possibile aggiungere altre aree di autenticazione per applicazioni Web aggiuntive. 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 del provider di identità (IP-STS) Questo servizio è il token sicuro nell'ambiente delle attestazioni che rilascia token SAML per conto degli utenti inclusi nella directory utente 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 diversi parametri, tra cui:
Un'unica attestazione d'identità.
Parametro Single SignInURL .
Il parametro SignInURL specifica l'URL a cui reindirizzare una richiesta utente per eseguire l'autenticazione al servizio token di sicurezza IP.
Un singolo parametro Wreply .
Alcuni server IP-STS richiedono il parametro Wreply , impostato su true o false. L'impostazione predefinita è false. Usare il parametro Wreply solo se è richiesto da IP-STS.
Più aree di autenticazione.
Più mapping di attestazioni.
Per implementare l'autenticazione basata su token SAML con SharePoint Server, implementare i passaggi seguenti che richiedono la pianificazione in anticipo:
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.
Definire l'attestazione che verrà utilizzata come identificatore univoco dell'utente. Questa attestazione è nota come attestazione di 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.
Definire mapping di attestazioni aggiuntivi. Definire le attestazioni aggiuntive dal token in ingresso che verrà usato 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 provenienti da un token in ingresso che non hanno un mapping verranno eliminate.
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. Durante questo processo, specificare l'attestazione di identità e le attestazioni aggiuntive di cui è stato eseguito il mapping. Creare e specificare un'area di autenticazione associata alle prime applicazioni Web di SharePoint che si sta configurando per l'autenticazione basata su token SAML. Dopo aver creato SPTrustedIdentityTokenIssuer, è possibile creare e aggiungere altre aree di autenticazione per applicazioni Web SharePoint aggiuntive. Questa procedura consente di configurare più applicazioni Web per l'uso dello stesso SPTrustedIdentityTokenIssuer.
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à. È possibile creare questa voce prima che esista l'applicazione Web SharePoint. È comunque necessario pianificare l'URL prima della creazione delle applicazioni Web.
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 provenienti da ambienti sts attendibili diversi non sono 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 IP, è consigliabile che l'utente e l'amministratore dell'ambiente delle attestazioni interno stabiliscano una relazione di trust unidirezionale dal servizio token di sicurezza ip interno al servizio token di sicurezza del partner. Questo approccio non richiede l'aggiunta di un provider di autenticazione alla farm di SharePoint Server. Consente inoltre agli amministratori delle attestazioni di gestire l'intero ambiente delle attestazioni.
Importante
Non è più necessario impostare il bilanciamento del carico di rete sull'affinità singola quando si utilizza l'autenticazione basata sulle attestazioni in SharePoint Server.
Nota
[!NOTA] Se un'applicazione Web è configurata per utilizzare l'autenticazione basata su token SAML, la classe SPTrustedClaimProvider non offre funzionalità di ricerca per il controllo Selezione utenti. Tutto il testo immesso nel controllo Selezione utenti viene visualizzato automaticamente come se fosse stato risolto, indipendentemente dal fatto che si tratti di un'attestazione, un gruppo o un utente valido. Se nella soluzione SharePoint Server viene utilizzata l'autenticazione basata su token SAML, è consigliabile pianificare la creazione di un provider di attestazioni personalizzato per implementare funzionalità di ricerca e risoluzione dei nomi personalizzate.
Per le procedure dettagliate per la configurazione dell'autenticazione basata su token SAML tramite ADFS, vedere Configurare l'autenticazione basata su SAML con ADFS in SharePoint Server.
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 caso contrario, non è possibile implementare più di un tipo di autenticazione di Windows in una zona.
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 nella zona predefinita, il componente di ricerca per indicizzazione può usare una zona diversa configurata per l'uso 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 una richiesta non può essere associata a un'area specifica, vengono applicate 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. È quindi probabile che gli utenti finali accertino alla zona predefinita.
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 una zona dedicata per il componente di indice 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 usano una zona diversa a seconda che lavorino in ufficio o lavorino in remoto.