Configurare l'autenticazione (Office SharePoint Server)

  • Articolo

Contenuto del capitolo:

L'autenticazione è il processo di convalida dell'identità del client, generalmente mediante un'autorità designata. L'autenticazione del sito Web consente di stabilire se un utente che sta tentando di accedere alle risorse del sito può essere verificato come entità autenticata. Un'applicazione di autenticazione ottiene le credenziali da un utente che richiede l'accesso al sito Web. Le credenziali possono corrispondere a diverse forme di identificazione, ad esempio nome utente e password. L'applicazione di autenticazione tenta di convalidare le credenziali a fronte di un'autorità di autenticazione. Se le credenziali sono valide, l'utente che le ha fornite verrà considerato un'identità autenticata.

Autenticazione di Office SharePoint Server

Per determinare il meccanismo di autenticazione di Office SharePoint Server più appropriato, prendere in considerazione gli aspetti seguenti:

  • Per utilizzare un meccanismo di autenticazione di Windows, è necessario un ambiente in grado di supportare account utente autenticabili da un'autorità attendibile.

  • Se si utilizza un meccanismo di autenticazione di Windows, sarà il sistema operativo a eseguire le attività di gestione delle credenziali utente. Se si utilizza un provider di autenticazione diverso da Windows, ad esempio l'autenticazione Forms, sarà necessario pianificare e implementare un sistema di gestione delle credenziali e decidere dove archiviare le credenziali utente.

  • Potrebbe essere necessario implementare un modello di rappresentazione/delega che consenta di passare il contesto di protezione a livello di sistema operativo di un utente tra diversi livelli. In questo modo, il sistema operativo può rappresentare l'utente e delegare il contesto di protezione dell'utente al sottosistema a valle successivo.

Microsoft Office SharePoint Server è un'applicazione distribuita suddivisa, dal punto di vista logico, in tre livelli: il livello del server Web front-end, il livello del server applicazioni e il livello del database back-end. Ogni livello è un sottosistema attendibile ed è possibile richiedere l'autenticazione per l'accesso a ogni livello. Per la convalida delle credenziali è necessario un provider di autenticazione. I provider di autenticazione sono componenti software che supportano meccanismi di autenticazione specifici. L'autenticazione di Microsoft Office SharePoint Server 2007 è basata sul modello di autenticazione ASP.NET e include tre provider di autenticazione:

  • Provider di autenticazione di Windows

  • Provider di autenticazione Forms

  • Provider di autenticazione SSO Web

Per l'autenticazione, è possibile utilizzare il servizio directory Active Directory oppure è possibile progettare l'ambiente in modo da eseguire la convalida delle credenziali utente in base ad altri archivi dati, ad esempio un database di Microsoft SQL Server, una directory LDAP (Lightweight Directory Access Protocol) o qualsiasi altra directory che disponga di un provider di appartenenze ASP.NET 2.0. Il provider di appartenenze specifica il tipo di archivio dati che verrà utilizzato. Il provider di appartenenze ASP.NET 2.0 predefinito prevede l'utilizzo di un database di SQL Server. Microsoft Office SharePoint Server 2007 include un provider di appartenenze LDAP v3 e ASP.NET 2.0 include un provider di appartenenze di SQL Server.

È inoltre possibile distribuire più provider di autenticazione per consentire, ad esempio, l'accesso Intranet utilizzando l'autenticazione di Windows e l'accesso esterno utilizzando l'autenticazione Forms. L'utilizzo di più provider di autenticazione richiede l'utilizzo di più applicazioni Web. Per ogni applicazione Web devono essere disponibili un'area designata e un singolo provider di autenticazione.

I provider di autenticazione vengono utilizzati per effettuare l'autenticazione sulla base di credenziali utente e di gruppo archiviate in Active Directory, in un database di SQL Server o in un servizio directory LDAP non Active Directory, ad esempio NDS. Per ulteriori informazioni sui provider di appartenenze ASP.NET, vedere Configurazione di un'applicazione ASP.NET per l'utilizzo dell'elemento membership (https://go.microsoft.com/fwlink/?linkid=87014&clcid=0x410).

Provider di autenticazione di Windows

Il provider di autenticazione di Windows supporta i metodi di autenticazione seguenti:

  • Autenticazione anonima

    L'autenticazione anonima consente agli utenti di trovare risorse nelle aree pubbliche dei siti Web senza dover fornire credenziali di autenticazione. Internet Information Services (IIS) crea l'account IUSR_nomecomputer per autenticare gli utenti anonimi in risposta a una richiesta di contenuto Web. L'account IUSR_nomecomputer, dove nomecomputer è il nome del server in cui è in esecuzione IIS, concede all'utente l'accesso alle risorse in modo anonimo nel contesto dell'account IUSR. L'accesso utente anonimo può essere reimpostato in modo che venga utilizzato qualsiasi account di Windows valido. In un ambiente autonomo l'account IUSR_nomecomputer è disponibile nel server locale. Se il server è un controller di dominio, l'account IUSR_nomecomputer è definito per il dominio. Per impostazione predefinita, l'accesso anonimo è disattivato quando si crea una nuova applicazione Web. Con l'accesso anonimo disattivato, viene garantito un ulteriore livello di protezione, in quanto IIS rifiuta le richieste di accesso anonimo prima che possano essere elaborate.

  • Autenticazione di base

    L'autenticazione di base richiede credenziali dell'account di Windows assegnate in precedenza per l'accesso utente. L'autenticazione di base consente a un Web browser di fornire credenziali quando effettua una richiesta durante una transazione HTTP. Poiché le credenziali utente non sono crittografate per la trasmissione in rete, ma vengono inviate in testo normale, non è consigliabile utilizzare questo tipo di autenticazione per una connessione HTTP non protetta. Per utilizzare l'autenticazione di base, è consigliabile attivare la crittografia SSL (Secure Sockets Layer).

  • Autenticazione del digest

    L'autenticazione del digest offre le stesse funzionalità dell'autenticazione di base, ma garantisce una maggiore protezione. Le credenziali utente vengono crittografate anziché essere inviate in rete come testo normale. Vengono inviate come digest del messaggio MD5 in cui il nome utente e la password originali non possono essere decifrati. Questo tipo di autenticazione utilizza un protocollo In attesa/Risposta secondo il quale colui che richiede l'autenticazione deve presentare credenziali valide in risposta all'attesa del server. Per l'autenticazione nel server, il client deve fornire un digest del messaggio MD5 in una risposta contenente una stringa con una password segreta condivisa. L'algoritmo del digest del messaggio MD5 è descritto in dettaglio in RFC 1321 di Internet Engineering Task Force (IETF) (http://www.ietf.org (informazioni in lingua inglese)).

    Per utilizzare l'autenticazione del digest, tenere presente i requisiti seguenti:

    • L'utente e il server IIS devono essere membri dello stesso dominio o essere considerati attendibili da esso.

    • Gli utenti devono disporre di un account utente di Windows valido in Active Directory nel controller di dominio.

    • Il dominio deve utilizzare un controller di dominio Microsoft Windows Server 2003.

    • È necessario installare il file IISSuba.dll nel controller di dominio. Questo file viene copiato automaticamente durante l'installazione di Windows Server 2003.

  • Autenticazione integrata di Windows

    L'autenticazione integrata di Windows può essere implementata utilizzando NTLM o la delega vincolata Kerberos. La delega vincolata Kerberos è il metodo di autenticazione più sicuro. L'autenticazione integrata di Windows è indicata in un ambiente Intranet in cui gli utenti dispongono di account di dominio di Windows. Con l'autenticazione integrata di Windows il browser cerca di utilizzare le credenziali dell'utente corrente da un accesso di dominio e, se il tentativo ha esito negativo, viene richiesto all'utente di immettere un nome utente e una password. Se si utilizza l'autenticazione integrata di Windows, la password dell'utente non viene trasmessa al server. Se l'utente ha eseguito l'accesso al computer locale come utente di dominio, non è necessario che esegua di nuovo l'autenticazione quando accede a un computer di rete in tale dominio.

  • Autenticazione Kerberos

    Questo metodo è indicato per i server che eseguono Active Directory in Microsoft Windows 2000 Server e nelle versioni più recenti di Windows. Kerberos è un protocollo protetto che supporta l'autenticazione tramite ticket. Un server di autenticazione Kerberos concede un ticket in risposta a una richiesta di autenticazione di un computer client contenente credenziali utente valide. Il computer client utilizza quindi il ticket per accedere alle risorse di rete. Per abilitare l'autenticazione Kerberos, i computer client e server devono disporre di una connessione trusted al centro distribuzione chiavi del dominio. Il computer client e server devono inoltre poter accedere ad Active Directory. Per ulteriori informazioni sulla configurazione di un server virtuale per l'utilizzo dell'autenticazione Kerberos, vedere l'articolo della Microsoft Knowledge Base 832769: Configurazione di un server virtuale Windows SharePoint Services per l'utilizzo dell'autenticazione Kerberos e passaggio dall'autenticazione Kerberos all'autenticazione NTLM (https://go.microsoft.com/fwlink/?linkid=115572&clcid=0x410).

  • Delega vincolata Kerberos

    L'autenticazione vincolata è la configurazione che offre la maggiore protezione per la comunicazione tra più livelli dell'applicazione. È possibile utilizzare la delega vincolata per passare l'identità del chiamante originale tra più livelli dell'applicazione, ad esempio da un server Web a un server applicazioni a un server database. La delega vincolata Kerberos è anche la configurazione che offre maggiore protezione per l'accesso alle origini dati back-end dai server applicazioni. La rappresentazione consente l'esecuzione di un thread in un contesto di protezione diverso da quello del processo proprietario del thread. Nella maggior parte delle distribuzioni in una server farm in cui i server Web front-end e i server applicazioni sono in esecuzione in computer diversi, per la rappresentazione è necessaria la delega vincolata Kerberos.

  • Rappresentazione e delega Kerberos

    La delega Kerberos consente a un'entità autenticata di rappresentare le credenziali di un utente o di un computer all'interno dello stesso insieme di strutture. Quando la rappresentazione è attivata, l'entità che esegue la rappresentazione può utilizzare le credenziali per l'esecuzione di attività al posto dell'utente o del computer rappresentato.

    Durante la rappresentazione, le applicazioni ASP.NET possono essere eseguite utilizzando le credenziali di un'altra entità autenticata. Per impostazione predefinita, la rappresentazione ASP.NET è disattivata. Se la rappresentazione è attivata per un'applicazione ASP.NET, l'applicazione viene eseguita utilizzando le credenziali del token di accesso passato da IIS ad ASP.NET. Tale token può essere un token utente autenticato, ad esempio un token per un utente di Windows che ha eseguito l'accesso, oppure il token fornito da IIS per gli utenti anonimi (in genere l'identità IUSR_nomecomputer).

    Quando la rappresentazione è attivata, solo il codice dell'applicazione viene eseguito nel contesto dell'utente rappresentato. Le applicazioni vengono compilate e le informazioni di configurazione vengono caricate utilizzando l'identità del processo ASP.NET.

    Per ulteriori informazioni sulla rappresentazione, vedere Rappresentazione ASP.NET (https://go.microsoft.com/fwlink/?linkid=115573&clcid=0x410).

  • Autenticazione NTLM

    Questo metodo è destinato ai server Windows che non eseguono Active Directory in un controller di dominio. L'autenticazione NTLM è necessaria per le reti che ricevono richieste di autenticazione provenienti da computer client che non supportano l'autenticazione Kerberos. NTLM è un protocollo protetto che supporta la crittografia e la trasmissione delle credenziali utente in una rete. Il protocollo NTLM è basato sulla crittografia dei nomi utente e delle password prima del loro invio nella rete. L'autenticazione NTLM è obbligatoria nelle reti in cui il server riceve richieste provenienti da computer client che non supportano l'autenticazione Kerberos. NTLM è il protocollo di autenticazione utilizzato in ambienti di gruppo di lavoro Windows 2000 Server e Windows NT Server e in numerose distribuzioni di Active Directory. NTLM viene utilizzato negli ambienti di dominio Active Directory Windows 2000 misti in cui è necessaria l'autenticazione di sistemi Windows NT. Quando Windows 2000 Server viene convertito in modalità nativa e non sono presenti controller di dominio Windows NT precedenti, il protocollo NTLM viene disattivato e Kerberos diventa quindi il protocollo di autenticazione predefinito per l'organizzazione.

Provider di autenticazione Forms

Il provider di autenticazione Forms supporta l'autenticazione a fronte di credenziali archiviate in Active Directory, in un database quale un database di SQL Server o in un archivio dati LDAP come ad esempio Novell eDirectory, Novell Directory Services (NDS) o Sun ONE. L'autenticazione Forms consente l'autenticazione degli utenti sulla base della convalida delle credenziali immesse in un modulo di accesso. Le richieste non autenticate vengono reindirizzate a una pagina di accesso, in cui l'utente deve specificare credenziali valide e inoltrare il modulo. Se la richiesta può essere autenticata, il sistema genererà un cookie contenente una chiave per ristabilire l'identità per le richieste successive.

Provider di autenticazione SSO (Single Sign-On) Web

L'autenticazione SSO Web è nota anche come autenticazione federativa o come autenticazione delegata perché supporta le comunicazioni protette oltre i confini della rete.

SSO è un metodo di autenticazione che consente di accedere a più risorse protette dopo un'unica autenticazione riuscita delle credenziali utente. Per l'autenticazione SSO sono disponibili diverse implementazioni. L'autenticazione SSO Web supporta le comunicazioni protette tra più reti consentendo agli utenti che sono stati autenticati in un'organizzazione di accedere alle applicazioni Web in un'altra organizzazione. Questo tipo di autenticazione è supportato da Active Directory Federation Services (ADFS). In uno scenario ADFS due organizzazioni possono creare una relazione di trust federativa che consente agli utenti di un'organizzazione di accedere alle applicazioni basate sul Web controllate dall'altra organizzazione. Per informazioni sull'utilizzo di ADFS per configurare l'autenticazione SSO Web, vedere Configurare l'autenticazione SSO Web mediante ADFS (Office SharePoint Server). Per informazioni su come eseguire questa procedura utilizzando lo strumento da riga di comando Stsadm, vedere Authentication: operazione Stsadm (Office SharePoint Server).

Scaricare il manuale

Questo argomento è incluso nel manuale seguente, che può essere scaricato per una lettura e una stampa più agevoli:

Per un elenco completo dei manuali disponibili, vedere la Raccolta di documentazione tecnica su Office SharePoint Server (informazioni in lingua inglese).