In questa pagina

	Argomenti del modulo
	Obiettivi
	Ambito di applicazione
	Utilizzo del modulo
	Architettura della protezione di ASP.NET
	Strategie di autenticazione e autorizzazione
	Configurazione della protezione
	Programmazione della protezione
	Autenticazione di Windows
	Autenticazione basata su moduli
	Autenticazione Passport
	Autenticazione personalizzata
	Identità del processo per ASP.NET
	Rappresentazione
	Accesso alle risorse di sistema
	Accesso agli oggetti COM
	Accesso alle risorse di rete
	Comunicazione protetta
	Archiviazione di segreti
	Protezione dello stato di sessione e visualizzazione
	Considerazione sulle Web farm
	Riepilogo

Argomenti del modulo

ASP.NET è fondamentale per lo sviluppo delle applicazioni Web distribuite descritte in questa guida. Offre infatti un insieme di funzionalità di protezione completo e facilmente accessibile che semplifica la creazione di applicazioni Web sicure. Sebbene sia stato progettato per l'integrazione con le funzionalità di protezione esistenti di Internet Information Services (IIS), della piattaforma Windows e di .NET Framework, ASP.NET è comunque flessibile ed estensibile. Pertanto consente di creare meccanismi di protezione personalizzati strettamente integrati con le applicazioni in uso.

In questo modulo sono riportati consigli e indicazioni per la risoluzione dei problemi di autenticazione, autorizzazione e comunicazione protetta che possono verificarsi durante la creazione di applicazioni Web ASP.NET sicure.

Nota: la maggior parte delle indicazioni e dei consigli presentati in questo modulo è applicabile anche allo sviluppo di servizi Web ASP.NET e di oggetti .NET Remoting che risiedono in ASP.NET, descritti in dettaglio rispettivamente nei moduli 10 e 11.

Inizio pagina

Obiettivi

Il modulo consente di:

Inizio pagina

Ambito di applicazione

Le informazioni contenute in questo modulo sono valide per i seguenti prodotti e tecnologie:

Inizio pagina

Utilizzo del modulo

Per trarre il massimo vantaggio dal modulo:

Inizio pagina

Architettura della protezione di ASP.NET

Le funzionalità di ASP.NET unite a quelle di IIS, di .NET Framework e dei servizi di protezione sottostanti forniti dal sistema operativo, consentono di disporre di una serie di meccanismi di autenticazione e di autorizzazione riepilogati nella figura 8.1.

Figura 8.1
Servizi di protezione di ASP.NET

La figura 8.1 illustra i meccanismi di autenticazione e autorizzazione forniti da IIS e da ASP.NET. Quando un client invia una richiesta Web, viene attivata la sequenza di meccanismi di autenticazione e autorizzazione seguente:

Gatekeeper

I punti di autorizzazione, o gatekeeper, all'interno di un'applicazione Web ASP.NET sono forniti da IIS e da ASP.NET:

IIS

Quando l'autenticazione anonima è disattivata, IIS autorizza esclusivamente le richieste degli utenti che è in grado di autenticare nel proprio dominio o in un dominio trusted.

Per eseguire il controllo dell'accesso nel caso di file di tipo statico, ad esempio quelli con estensione jpg, gif e htm a cui non è associata un'estensione ISAPI, IIS utilizza le autorizzazioni NTFS associate al file richiesto.

ASP.NET

I gatekeeper ASP.NET includono le richieste di autorizzazione e i controlli dei ruoli UrlAuthorizationModule, FileAuthorizationModule e del principal.

UrlAuthorizationModule

Per controllare gli utenti e i gruppi di utenti a cui deve essere consentito l'accesso all'applicazione, è possibile configurare gli elementi <authorization> all'interno del file web.config dell'applicazione. L'autorizzazione è basata sull'oggetto IPrincipal archiviato in HttpContext.User.

FileAuthorizationModule

Per i tipi di file che IIS allega all'estensione ISAPI ASP.NET (Aspnet_isapi.dll), i controlli di accesso automatici vengono eseguiti tramite il token di accesso di Windows dell'utente autenticato, ad esempio IUSR_MACHINE, rispetto all'ACL allegato al file ASP.NET richiesto.

Nota: per l'autorizzazione del file non è necessaria la rappresentazione.

La classe FileAuthorizationModule esegue i controlli di accesso esclusivamente rispetto al file richiesto mentre non controlla i file a cui accede il codice della pagina richiesta, anche nel caso in cui l'accesso sia controllato da IIS.

Se ad esempio si richiede il file Default.aspx contenente il controllo utente incorporato Usercontrol.ascx, che a sua volta include un tag immagine che fa riferimento a Image.gif, la classe FileAuthorizationModule esegue un controllo dell'accesso per i file Default.aspx e Usercontrol.ascx in quanto IIS associa questi tipi di file all'estensione ISAPI ASP.NET.

Image.gif è un file statico gestito internamente da IIS e la classe FileAuthorizationModule non ne esegue il controllo. Poiché i controlli di accesso dei file statici vengono eseguiti da IIS, all'utente autenticato deve comunque essere concessa l'autorizzazione di lettura del file tramite un ACL opportunamente configurato.

Tale scenario è illustrato nella figura 8.2.

Nota per gli amministratori di sistema: l'utente autenticato deve disporre delle autorizzazioni NTFS in lettura per tutti i file dello scenario. L'unica variabile riguarda il gatekeeper utilizzato per applicare il controllo dell'accesso. L'account del processo ASP.NET richiede l'accesso in lettura soltanto per i tipi di file registrati in ASP.NET.

Figura 8.2
Integrazione di IIS e dei gatekeeper ASP.NET.

In questo scenario è possibile impedire l'accesso al gate dei file. Se si configura l'ACL allegato al file Default.aspx e si nega l'accesso a un determinato utente, il controllo utente e le eventuali immagini incorporate non potranno essere inviate al client dal codice presente nel file Default.aspx. Se invece l'utente richiede direttamente le immagini, IIS esegue direttamente i controlli di accesso.

Richieste di autorizzazione del principal e controlli dei ruoli espliciti

Oltre ai gatekeeper configurabili IIS e ASP.NET, è possibile utilizzare le richieste di autorizzazione del principal, sia a livello dichiarativo che di programmazione, come ulteriore meccanismo specifico di controllo dell'accesso. I controlli delle autorizzazioni del principal eseguiti dalla classe PrincipalPermissionAttribute consentono di controllare l'accesso alle classi, ai metodi o ai singoli blocchi di codice sulla base dell'identità e dell'appartenenza ai gruppi dei singoli utenti, secondo quanto definito dall'oggetto IPrincipal allegato al thread corrente.

Nota: le richieste di autorizzazione del principal utilizzate per richiedere l'appartenenza ai ruoli differiscono dalle chiamate a IPrincipal.IsInRole eseguite per verificare l'appartenenza ai ruoli; nel primo caso, se il chiamante non appartiene al ruolo specificato, il risultato è un'eccezione; nel secondo caso, invece, il risultato è semplicemente un valore booleano che conferma l'appartenenza ai ruoli.

Con l'autenticazione di Windows, ASP.NET allega automaticamente un oggetto WindowsPrincipal che rappresenta l'utente autenticato alla richiesta Web corrente mediante l'utilizzo di HttpContext.User. L'autenticazione basata su moduli e l'autenticazione Passport creano un oggetto GenericPrincipal con l'identità corretta ma senza ruoli che viene allegato a HttpContext.User.

Ulteriori informazioni

Inizio pagina

Strategie di autenticazione e autorizzazione

ASP.NET fornisce numerosi meccanismi di autorizzazione a livello dichiarativo e di programmazione da utilizzare insieme a una vasta gamma di schemi di autenticazione, consentendo lo sviluppo di una strategia di autorizzazione su più livelli che può essere configurata in modo da disporre di diversi gradi di granularità, ad esempio per utente o per gruppo di utenti (basati sui ruoli).

In questa sezione vengono illustrate le opzioni di autorizzazione disponibili, sia a livello di configurazione che di programmazione, per un insieme di opzioni di autenticazione comunemente usate.

Le opzioni di autenticazione descritte sono elencate di seguito.

Opzioni di autorizzazione disponibili

Nella tabella che segue viene illustrato l'insieme di opzioni di autorizzazione disponibili. Per ciascuna di esse la tabella indica se sono necessarie o meno l'autenticazione di Windows e/o la rappresentazione. Se l'autenticazione di Windows non è necessaria, l'opzione di autorizzazione specifica è disponibile per tutti gli altri tipi di autenticazione. Utilizzare la tabella per perfezionare la strategia di autenticazione/autorizzazione adottata.

Tabella 8.1: Requisiti di autenticazione di Windows e di rappresentazione

Autenticazione di Windows con rappresentazione

I seguenti elementi della configurazione illustrano la procedura per attivare l'autenticazione di Windows (IIS) e la rappresentazione a livello dichiarativo nei file web.config o machine.config.

Nota: è consigliabile configurare l'autenticazione per singola applicazione nel file web.config di ciascuna di esse.

<authentication mode="Windows" />
<identity impersonate="true" />

Con questa configurazione, il codice dell'applicazione ASP.NET rappresenta il chiamante autenticato da IIS.

Protezione configurabile

Quando si utilizza l'autenticazione di Windows con la rappresentazione, sono disponibili le seguenti opzioni di autorizzazione:

<authorization>
  <deny user="DomainName\UserName" />
  <allow roles="DomainName\WindowsGroup" />
</authorization>

Protezione a livello di programmazione

Per protezione a livello di programmazione si intendono i controlli di protezione all'interno del codice dell'applicazione Web. Quando si utilizzano l'autenticazione di Windows e la rappresentazione, sono disponibili le seguenti opzioni di protezione a livello di programmazione:

    PrincipalPermission permCheck = new PrincipalPermission(
                                       null, @"DomainName\WindowsGroup");
    permCheck.Demand();

[PrincipalPermission(SecurityAction.Demand, 
                  Role=@"DomainName\WindowsGroup)]

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

ContextUtil.IsCallerInRole("Manager")

Raccomandazioni sull'utilizzo

Utilizzare l'autenticazione di Windows e la rappresentazione nei seguenti casi:

Prima di utilizzare la rappresentazione all'interno dell'applicazione, valutare i vantaggi e gli svantaggi di questo approccio rispetto al modello di sottosistema trusted. Per una descrizione dettagliata, vedere "Scelta di un modello di accesso alle risorse" nella sezione "Modalità di autorizzazione" del modulo 3 "Autenticazione e autorizzazione".

Gli svantaggi della rappresentazione comprendono:

Ulteriori informazioni

Autenticazione di Windows senza rappresentazione

I seguenti elementi della configurazione illustrano la procedura per attivare l'autenticazione di Windows (IIS) senza la rappresentazione a livello dichiarativo nel file web.config.

<authentication mode="Windows" />
<!-- The following setting is equivalent to having no identity element -->
<identity impersonate="false" />

Protezione configurabile

Quando si utilizza l'autenticazione di Windows senza la rappresentazione, sono disponibili le seguenti opzioni di autorizzazione:

<authorization>
  <deny user="DomainName\UserName" />
  <allow roles="DomainName\WindowsGroup" />
</authorization>

Protezione a livello di programmazione

Sono disponibili le seguenti opzioni di protezione a livello di programmazione:

    PrincipalPermission permCheck = new PrincipalPermission(
                                         null, @"DomainName\WindowsGroup");
    permCheck.Demand();

[PrincipalPermission(SecurityAction.Demand, 
                  Role=@"DomainName\WindowsGroup")]

IPrincipal.IsInRole(@"DomainName\WindowsGroup");

Raccomandazioni sull'utilizzo

Utilizzare l'autenticazione di Windows senza rappresentazione seguenti casi:

Ulteriori informazioni

Autenticazione di Windows tramite un'identità fissa

L'elemento <identity> contenuto nel file web.config supporta gli attributi di nome utente e password facoltativi che consentono di configurare un'identità fissa specifica da rappresentare per l'applicazione, come illustrato nel seguente frammento del file di configurazione.

<identity impersonate="true"
          userName="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,userName"
          password="registry:HKLM\SOFTWARE\YourSecureApp\
                    identity\ASPNET_SETREG,password" />

In questo esempio viene illustrato l'elemento <identity>, in cui le credenziali vengono crittografate nel Registro di sistema mediante l'utilità aspnet_setreg.exe. I valori di attributo nome utente e password in testo normale sono stati sostituiti con puntatori alla chiave del Registro di sistema e ai valori denominati protetti contenenti le credenziali crittografate. Per informazioni dettagliate su questa utilità e sul relativo download, vedere l'articolo Q329290 "HOW TO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (in inglese) della Microsoft Knowledge Base.

Raccomandazioni sull'utilizzo

L'impiego di un'identità rappresentata fissa non è consigliato in caso di utilizzo di .NET Framework 1.0 nei server Windows 2000, in quanto richiede l'assegnazione del privilegio "Agisci come parte del sistema operativo" all'account di processo ASP.NET. Questo privilegio è necessario per il processo ASP.NET poiché consente di eseguire una chiamata LogonUser utilizzando le credenziali specificate dall'utente.

Nota: nella versione 1.1 di .NET Framework verrà introdotto un miglioramento per questo scenario relativo a Windows 2000. L'accesso verrà eseguito dal processo IIS, in modo che ASP.NET non richieda il privilegio "Agisci come parte del sistema operativo".

Autenticazione basata su moduli

Gli elementi della configurazione riportati di seguito illustrano la procedura per attivare l'autenticazione basata su moduli a livello dichiarativo nel file web.config.

<authentication mode="Forms">
  <forms loginUrl="logon.aspx" name="AuthCookie" timeout="60" path="/">
  </forms>
</authentication>

Protezione configurabile

Quando si utilizza l'autenticazione basata su moduli, sono disponibili le seguenti opzioni di autorizzazione:

<authorization>
<deny users="?" />
  <allow users="Mary,Bob,Joe" roles="Manager,Sales" />
</authorization>

<authorization>
  <deny users="someAccount@domain.corp.yourCompany.com" />
  <allow roles ="CN=Smith James,CN=FTE_northamerica,CN=Users,
                DC=domain,DC=corp,DC=yourCompany,DC=com" />
</authorization>

Protezione a livello di programmazione

Sono disponibili le seguenti opzioni di protezione a livello di programmazione:

    PrincipalPermission permCheck = new PrincipalPermission(
                                         null, "Manager");
    permCheck.Demand();

[PrincipalPermission(SecurityAction.Demand, 
                  Role="Manager")]

IPrincipal.IsInRole("Manager");

Raccomandazioni sull'utilizzo

L'autenticazione basata su moduli è particolarmente indicata per le applicazioni Internet e in generale in tutti i casi in cui:

Ulteriori informazioni

Autenticazione Passport

Gli elementi della configurazione riportati di seguito illustrano la procedura per attivare l'autenticazione Passport a livello dichiarativo nel file web.config.

<authentication mode="Passport" />

Raccomandazioni sull'utilizzo

L'autenticazione Passport viene utilizzata su Internet quando gli utenti delle applicazioni non dispongono di account di Windows e si desidera implementare un soluzione ad accesso singolo. Gli utenti che in precedenza eseguivano l'accesso con un account Passport in un sito Web che aderisce al sistema Passport, non dovranno più eseguire la procedura di accesso se il proprio sito è stato configurato per l'autenticazione Passport.

Inizio pagina

Configurazione della protezione

In questa sezione viene illustrata la procedura di configurazione per la protezione di un'applicazione Web ASP.NET, riepilogata nella figura 8.3.

Figura 8.3
Configurazione della protezione dell'applicazione ASP.NET.

Configurazione delle impostazioni IIS

Per configurare la protezione IIS è necessario attenersi alla seguente procedura:

Configurazione delle impostazioni ASP.NET

Le impostazioni di configurazione a livello dell'applicazione vengono conservate nei file web.config che si trovano nella directory principale virtuale dell'applicazione e, facoltativamente, all'interno di altre sottocartelle; le impostazioni delle sottocartelle possono talvolta ignorare le impostazioni della cartella principale.

<authentication mode="Windows|Forms|Passport|None" />

<identity impersonate="true" />

<authorization>
  <allow users="DomainName\Bob, DomainName\Mary" />
  <deny users="*" />
</authorization>

Note sull'autorizzazione dell'URL

Quando si configura l'autorizzazione dell'URL, tenere presente quanto segue:

<location path="page.aspx" />
  <authorization>
    <allow users="DomainName\Bob, DomainName\Mary" />
    <deny users="*" />
  </authorization>
</location>

Esempi di autorizzazione dell'URL

L'elenco riportato di seguito illustra la sintassi di alcuni esempi tipici di autorizzazione dell'URL:

 <deny users="?" />

<deny users="*"/>

<deny roles="Manager"/>

<configuration>
  <system.web>
      <authentication mode="Forms">
        <forms name=".ASPXUSERDEMO" 
               loginUrl="login.aspx" 
               protection="All" timeout="60" />
      </authentication>
      <authorization>
        <deny users="jdoe@somewhere.com" />
        <deny users="?" />
      </authorization>
  </system.web>
</configuration>

Nota: l'elemento <authorization> è in conflitto con l'oggetto IPrincipal corrente archiviato in HttpContext.User e anche con il metodo di trasferimento dei dati HTTP archiviato in HttpContext.Request.RequestType.

Protezione delle risorse

Blocco delle impostazioni di configurazione

Le impostazioni di configurazione rispettano un ordine gerarchico. Le impostazioni del file web.config nelle sottodirectory ignorano quelle delle directory principali e le impostazioni del file web.config ignorano quelle del file machine.config.

È possibile bloccare le impostazioni di configurazione per evitare che vengano ignorate ai livelli inferiori, utilizzando l'elemento <location> insieme all'attributo allowOverride. Ad esempio:

<location path="somepath" allowOverride="false" />
 . . . arbitrary configuration settings . . .
</location>

Il percorso riportato può fare riferimento a un sito Web o alla directory virtuale ed è valido per la directory citata e per tutte le sottodirectory. Se si imposta allowOverride su "false", si impedisce ai file di configurazione di livello inferiore di ignorare le impostazioni specificate nell'elemento <location>. La possibilità di bloccare le impostazioni di configurazione vale per tutti i tipi di impostazioni e non soltanto per le impostazioni di protezione quali, ad esempio, le modalità di autenticazione.

Nel contesto del file machine.config, il percorso deve essere completo e deve includere il sito Web, il nome della directory virtuale nonché, facoltativamente, una sottodirectory e un nome file. Ad esempio:

<location path="Web Site Name/VDirName/SubDirName/PageName.aspx" >
 . . .
</location>

Nel contesto del file web.config, il percorso è in relazione alla directory virtuale dell'applicazione. Ad esempio:

<location path="SubDirName/PageName.aspx" >
. . .
</location>

Blocco del download dei file

Per impedire che alcuni tipi di file vengano scaricati tramite Web, è possibile utilizzare la classe HttpForbiddenHandler. Tale classe viene utilizzata internamente da ASP.NET per impedire il download di determinati file di sistema, ad esempio i file di configurazione come web.config. Per un elenco completo dei tipi di file a cui applicare le limitazioni descritte, vedere la sezione <httpHandlers> nel file machine.config.

Per i file che l'applicazione utilizza internamente ma di cui non è consentito il download, è consigliabile valutare l'opportunità di utilizzare la classe HttpForbiddenHandler.

Nota: quando si è collegati a un server Web, è inoltre necessario proteggere i file con gli ACL di Windows per controllare a quali utenti sia consentito l'accesso.

<httpHandlers>
  <add verb="*" path="*.abc" 
    type="System.Web.HttpForbiddenHandler"/>
</httpHandlers>

Comunicazione protetta

Per proteggere i collegamenti di comunicazione è consigliabile utilizzare una combinazione di protocolli SSL e IPSec (Internet Protocol Security).

Ulteriori informazioni

Inizio pagina

Programmazione della protezione

Dopo avere stabilito le impostazioni di protezione configurabili dell'applicazione Web, è necessario potenziare e ottimizzare i criteri di autorizzazione delle applicazioni a livello di programmazione. A tale scopo è necessario utilizzare gli attributi .NET dichiarativi negli assembly ed eseguire controlli di autorizzazione imperativi all'interno del codice.

In questa sezione vengono illustrate le principali procedure di programmazione necessarie per eseguire l'autorizzazione in un'applicazione Web ASP.NET.

Modello di autorizzazione

In sintesi, la procedura del modello di base per autorizzare gli utenti all'interno dell'applicazione Web è la seguente:

Importante: se è stata configurata l'autenticazione di Windows, i passaggi da 1 a 5 vengono eseguiti automaticamente da ASP.NET. Nel caso di altri meccanismi di autenticazione, quali la modalità basata su moduli, Passport e personalizzata, per eseguire questi passaggi è necessario scrivere un apposito codice seguendo le indicazioni riportate di seguito.

Recupero delle credenziali

Iniziare la procedura recuperando innanzitutto un insieme di credenziali, ovvero nome utente e password, dall'utente. Se l'applicazione in uso non utilizza l'autenticazione di Windows, è necessario verificare che le credenziali non crittografate siano opportunamente protette in rete tramite il protocollo SSL.

Convalida delle credenziali

Se è stata configurata l'autenticazione di Windows, le credenziali vengono convalidate automaticamente mediante i servizi sottostanti del sistema operativo.

Se si utilizza un meccanismo di autenticazione alternativo, è necessario scrivere un apposito codice per convalidare le credenziali rispetto a un archivio dati, ad esempio un database SQL Server o Active Directory.

Per ulteriori informazioni sulla procedura per archiviare in modo sicuro le credenziali dell'utente in un database SQL Server, vedere la sezione "Autenticazione degli utenti rispetto a un database" nel modulo 12 "Protezione dell'accesso ai dati".

Inserimento degli utenti nei ruoli

L'archivio dati utente dovrebbe inoltre contenere un elenco dei ruoli per ciascun utente. Per recuperare l'elenco dei ruoli relativo all'utente convalidato è necessario scrivere un apposito codice.

Creazione di un oggetto IPrincipal

L'autorizzazione viene eseguita rispetto all'utente autenticato del quale si conservano l'identità e l'elenco dei ruoli all'interno di un oggetto IPrincipal; tale oggetto viene trasmesso nel contesto della richiesta Web corrente.

Se è stata configurata l'autenticazione di Windows, ASP.NET crea automaticamente un oggetto WindowsPrincipal contenente l'identità dell'utente autenticato e un elenco dei ruoli corrispondente all'elenco dei gruppi di Windows a cui appartiene l'utente.

Se si utilizza l'autenticazione basata su moduli, Passport o personalizzata, per creare un oggetto IPrincipal è necessario scrivere un apposito codice all'interno del gestore eventi Application_AuthenticateRequest in Global.asax. Nella maggior parte degli scenari è consigliabile utilizzare la classe GenericPrincipal fornita da .NET Framework.

Inserimento dell'oggetto IPrincipal nel contesto HTTP corrente

Allegare l'oggetto IPrincipal al contesto HTTP corrente mediante la variabile HttpContext.User. Se si utilizza l'autenticazione di Windows, l'operazione viene eseguita automaticamente da ASP.NET; in caso contrario, è necessario allegare manualmente l'oggetto.

Autorizzazione in base all'identità dell'utente e/o all'appartenenza ai ruoli

Se l'applicazione richiede una logica di autorizzazione più specifica, utilizzare i ruoli .NET sia a livello dichiarativo, per ottenere l'autorizzazione a livello di classe o di metodo, sia a livello imperativo all'interno del codice.

È possibile utilizzare richieste di autorizzazione del principal dichiarative o imperative tramite la classe PrincipalPermission oppure eseguire controlli dei ruoli espliciti chiamando il metodo IPrincipal.IsInRole().

L'esempio riportato di seguito presuppone l'esistenza dell'autenticazione di Windows e mostra una richiesta di autorizzazione del principal dichiarativa. Il metodo che segue l'attributo viene eseguito soltanto se l'utente autenticato appartiene al gruppo di Windows Manager. Se il chiamante non appartiene a tale gruppo, viene generata una SecurityException.

[PrincipalPermission(SecurityAction.Demand, 
                     Role=@"DomainName\Manager")]
public void SomeMethod()
{
}

Nell'esempio riportato di seguito viene illustrato un controllo dei ruoli esplicito all'interno del codice e si presuppone che sia stata configurata l'autenticazione di Windows. Se viene utilizzato un meccanismo di autenticazione diverso da quello di Windows, il codice non subisce variazioni significative; anziché eseguire il casting dell'oggetto User a un oggetto WindowsPrincipal, il casting deve essere eseguito a un oggetto GenericPrincipal .

// Extract the authenticated user from the current HTTP context.
// The User variable is equivalent to HttpContext.Current.
User if you are using // an .aspx or .asmx page
WindowsPrincipal authenticatedUser = User as WindowsPrincipal;
if (null != authenticatedUser)
{
  // Note: To retrieve the authenticated user's username, use the 
  // following line of code
  // string username = authenticatedUser.Identity.Name;

  // Perform a role check
  if (authenticatedUser.IsInRole(@"DomainName\Manager") )
  {
    // User is authorized to perform manager functionality
  }
}
else
{
  // User is not authorized to perform manager functionality
}

Ulteriori informazioni

Creazione di una classe IPrincipal personalizzata

È consigliabile utilizzare la classe GenericPrincipal fornita da .NET Framework nella maggior parte dei casi in cui si applica un meccanismo di autenticazione diverso da quello di Windows. In tal modo è possibile garantire i controlli dei ruoli tramite il metodo IPrincipal.IsInRole.

In alcuni casi potrebbe essere necessario implementare una classe IPrincipal personalizzata. La classe IPrincipal personalizzata viene implementata per i seguenti motivi:

CustomPrincipal.IsInAllRoles( "Role", "Role2", "Role3" )
CustomPrincipal.IsInAnyRole( "Role1", "Role2", "Role3" )

string[] roles = CustomPrincipal.Roles;

CustomPrincipal.IsInHigherRole("Manager");
CustomPrincipal.IsInLowerRole("Manager");

CustomIdentity id = CustomPrincipal.Identity;
X509ClientCertificate cert = id.ClientCertificate;

Ulteriori informazioni

Per ulteriori informazioni sulla creazione di una classe IPrincipal personalizzata, vedere "Procedura - Implementazione di IPrincipal" in questa guida.

Inizio pagina

Autenticazione di Windows

È consigliabile utilizzare l'autenticazione di Windows quando gli utenti dell'applicazione dispongono di account di Windows che possono essere autenticati dal server, ad esempio nell'ambito di scenari Intranet.

Se si configura ASP.NET per l'autenticazione di Windows, IIS esegue l'autenticazione dell'utente mediante il meccanismo di autenticazione IIS. L'esempio descritto è illustrato nella figura 8.4.

Figura 8.4
L'autenticazione di Windows ASP.NET utilizza IIS per autenticare i chiamanti

Il token di accesso del chiamante autenticato, che corrisponde all'account utente Internet anonimo nel caso in cui IIS sia stato configurato per l'autenticazione anonima, viene reso disponibile per l'applicazione ASP.NET. È necessario tenere presente quanto segue.

Identificazione dell'utente autenticato

ASP.NET associa un oggetto WindowsPrincipal alla richiesta Web corrente. Tale oggetto contiene l'identità dell'utente di Windows autenticato insieme a un elenco dei ruoli a cui l'utente appartiene. Con l'autenticazione di Windows, l'elenco dei ruoli è costituito dall'insieme dei gruppi di Windows a cui l'utente appartiene.

Il codice riportato di seguito illustra la procedura per ottenere l'identità dell'utente di Windows autenticato ed eseguire una semplice verifica dei ruoli per l'autorizzazione.

WindowsPrincipal user = User as WindowsPrincipal;
if (null != user)
{
  string username = user.Identity.Name;
  // Perform a role check
  if ( user.IsInRole(@"DomainName\Manager") )
  {
    // User is authorized to perform manager functionality
  }
}
else
{
  // Throw security exception as we don't have a WindowsPrincipal
}  

Inizio pagina

Autenticazione basata su moduli

Quando si utilizza l'autenticazione basata su moduli, la sequenza di eventi avviata da un utente autenticato che tenta di accedere a un file o a una risorsa protetti (caso in cui l'autorizzazione dell'URL nega l'accesso all'utente) viene illustrata nella figura 8.5.

Figura 8.5
Sequenza di eventi dell'autenticazione basata su moduli

La sequenza di eventi illustrata nella figura 8.5 è la seguente:

Procedura di sviluppo per l'autenticazione basata su moduli

Nell'elenco riportato di seguito vengono indicati i passaggi principali necessari per implementare l'autenticazione basata su moduli:

Configurazione di IIS per l'accesso anonimo

È necessario configurare la directory virtuale dell'applicazione in IIS per l'accesso anonimo.

Configurazione di ASP.NET per l'autenticazione basata su moduli

Di seguito viene riportato un esempio di configurazione.

<authentication mode="Forms">
  <forms name="MyAppFormsAuth" 
       loginUrl="login.aspx" 
       protection="Encryption"
       timeout="20" 
       path="/" >
  </forms>
</authentication>

Creazione di un modulo Web di accesso e convalida delle credenziali fornite

Convalidare le credenziali rispetto a un database SQL Server o ad Active Directory.

Ulteriori informazioni

Recupero di un elenco dei ruoli dall'archivio dati personalizzato

Ottenere ruoli da una tabella all'interno del database SQL Server o gruppi/liste di distribuzione configurati all'interno di Active Directory. Per informazioni dettagliate, fare riferimento alle risorse precedenti.

Creazione di un ticket di autenticazione basata su moduli

Archiviare i ruoli recuperati nel ticket. L'operazione viene illustrata nel codice riportato di seguito.

// This event handler executes when the user clicks the Logon button
// having supplied a set of credentials
private void Logon_Click(object sender, System.EventArgs e)
{
  // Validate credentials against either a SQL Server database
  // or Active Directory
  bool isAuthenticated = IsAuthenticated( txtUserName.Text, 
                                          txtPassword.Text );
  if (isAuthenticated == true )
  {
    // Retrieve the set of roles for this user from the SQL Server
    // database or Active Directory. The roles are returned as a
    // string that contains pipe separated role names
    // for example "Manager|Employee|Sales|"
    // This makes it easy to store them in the authentication ticket

    string roles = RetrieveRoles( txtUserName.Text, txtPassword.Text );

    // Create the authentication ticket and store the roles in the
    // custom UserData property of the authentication ticket
    FormsAuthenticationTicket authTicket = new 
       FormsAuthenticationTicket(
                    1,                          // version
                    txtUserName.Text,           // user name
                    DateTime.Now,               // creation
                    DateTime.Now.AddMinutes(20),// Expiration
                    false,                      // Persistent
                    roles );                    // User data
     // Encrypt the ticket.
     string encryptedTicket = FormsAuthentication.Encrypt(authTicket);
     // Create a cookie and add the encrypted ticket to the 
     // cookie as data.
     HttpCookie authCookie = 
               new HttpCookie(FormsAuthentication.FormsCookieName,
                              encryptedTicket);

     // Add the cookie to the outgoing cookies collection. 
     Response.Cookies.Add(authCookie); 
     // Redirect the user to the originally requested page
     Response.Redirect( FormsAuthentication.GetRedirectUrl(
                        txtUserName.Text, 
                        false ));
  }
}

Creazione di un oggetto IPrincipal

Creare l'oggetto IPrincipal nel gestore eventi Application_AuthenticationRequest in Global.asax. Utilizzare la classe GenericPrincipal, a meno che sia necessaria la funzionalità estesa basata sui ruoli. In tal caso, creare una classe personalizzata che implementa IPrincipal.

Inserimento dell'oggetto IPrincipal nel contesto HTTP corrente

Di seguito viene illustrata la creazione di un oggetto GenericPrincipal.

protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
  // Extract the forms authentication cookie
  string cookieName = FormsAuthentication.FormsCookieName;
  HttpCookie authCookie = Context.Request.Cookies[cookieName];
  if(null == authCookie)
  {
    // There is no authentication cookie.
    return;
  } 
  FormsAuthenticationTicket authTicket = null;
  try
  {
    authTicket = FormsAuthentication.Decrypt(authCookie.Value);
  }
  catch(Exception ex)
  {
    // Log exception details (omitted for simplicity)
    return;
  }
  if (null == authTicket)
  {
    // Cookie failed to decrypt.
    return; 
  }
  // When the ticket was created, the UserData property was assigned a
  // pipe delimited string of role names.
  string[] roles = authTicket.UserData.Split(new char[]{'|'});

  // Create an Identity object
  FormsIdentity id = new FormsIdentity( authTicket ); 
  // This principal will flow throughout the request.
  GenericPrincipal principal = new GenericPrincipal(id, roles);
  // Attach the new principal object to the current HttpContext object
  Context.User = principal;
}

Autorizzazione dell'utente in base al nome utente o all'appartenenza ai ruoli

Per limitare l'accesso ai metodi, utilizzare le richieste di autorizzazione del principal dichiarative. Per eseguire l'autorizzazione specifica all'interno dei metodi, utilizzare le richieste di autorizzazione del principal imperative e/o i controlli dei ruoli espliciti (IPrincipal.IsInRole).

Indicazioni sull'implementazione dei moduli

Ulteriori informazioni

Hosting di più applicazioni con l'autenticazione basata su moduli

Se si sta eseguendo l'hosting di più applicazioni Web che utilizzano l'autenticazione basata su moduli nello stesso server Web, è possibile che un utente autenticato in un'applicazione invii una richiesta per un'altra applicazione senza tuttavia essere reindirizzato alla pagina di accesso di quest'ultima. È possibile che le regole di autorizzazione dell'URL all'interno della seconda applicazione neghino l'accesso all'utente, senza fornirgli tuttavia la possibilità di immettere le credenziali di accesso nell'apposito modulo.

Ciò si verifica soltanto se gli attributi di nome e percorso dell'elemento <forms> sono gli stessi per più applicazioni e ciascuna di esse utilizza un elemento <machineKey> comune nel file web.config.

Ulteriori informazioni

Per ulteriori informazioni su questo problema e sulle relative tecniche di risoluzione, vedere i seguenti articoli della Knowledge Base:

Autenticazione basata su moduli senza cookie

Se è necessario implementare una soluzione di autenticazione basata su moduli che non preveda l'uso di cookie, è consigliabile valutare l'opportunità di seguire l'approccio utilizzato in Microsoft Mobile Internet Toolkit. L'autenticazione mobile basata su moduli deriva dall'autenticazione semplice basata su moduli ma per trasmettere il ticket di autenticazione utilizza la stringa di query anziché i cookie.

Ulteriori informazioni

Per ulteriori informazioni sull'autenticazione mobile basata su moduli, vedere l'articolo Q311568 "INFO: How To Use Mobile Forms Authentication with Microsoft Mobile Internet Toolkit" della Microsoft Knowledge Base (in inglese).

Inizio pagina

Autenticazione Passport

È consigliabile utilizzare l'autenticazione Passport quando gli utenti dell'applicazione dispongono di account Passport e si desidera implementare una soluzione ad accesso singolo con altri siti che aderiscono al sistema Passport.

Quando si configura ASP.NET per l'autenticazione Passport, all'utente viene richiesto di eseguire una procedura di accesso al termine della quale viene reindirizzato al sito Passport. Una volta convalidate le credenziali, l'utente viene reindirizzato al sito originario.

Configurazione di ASP.NET per l'autenticazione Passport

Per configurare ASP.NET per l'autenticazione Passport, utilizzare le impostazioni del file web.config riportate di seguito.

<authentication mode="Passport">
  <passport redirectUrl="internal" />
</authentication>
<authorization>
  <deny users="?" />
  <allow users="*" />
</authorization>

Mapping di un identità Passport nei ruoli in Global.asax

Per associare un'identità Passport nei ruoli, implementare il gestore eventi PassportAuthentication_OnAuthentication in Global.asax come illustrato di seguito.

void PassportAuthentication_OnAuthenticate(Object sender, 
                                           PassportAuthenticationEventArgs e)
{
  if(e.Identity.Name == "0000000000000001")
  {
    string[] roles = new String[]{"Developer", "Admin", "Tester"};
    Context.User = new GenericPrincipal(e.Identity, roles);
  }
}

Verifica dell'appartenenza ai ruoli

Il frammento di codice riportato di seguito mostra la procedura necessaria per recuperare l'identità Passport autenticata e verificare l'appartenenza ai ruoli in una pagina aspx.

PassportIdentity passportId = Context.User.Identity as PassportIdentity;
if (null == passportId)
{
  Response.Write("Not a PassportIdentity<br>");
  return;
}
Response.Write("IsInRole: Develeoper? " + Context.User.IsInRole("Developer"));

Inizio pagina

Autenticazione personalizzata

Se nessuno dei moduli di autenticazione forniti con .NET Framework soddisfa le esigenze di autenticazione specifiche, è possibile implementare un meccanismo di autenticazione personalizzato. Ad esempio, è possibile che la propria azienda disponga già di una strategia di autenticazione personalizzata ampiamente utilizzata da altre applicazioni.

Per implementare l'autenticazione personalizzata in ASP.NET, effettuare le seguenti operazioni:

<authentication mode="None" />

Ulteriori informazioni

Per ulteriori informazioni sulla procedura di implementazione di un modulo HTTP personalizzato, vedere l'articolo Q307996 "HOW TO: Create an ASP.NET HTTP Module Using Visual C# .NET" (in inglese) della Microsoft Knowledge Base.

Inizio pagina

Identità del processo per ASP.NET

Eseguire ASP.NET, in particolare il processo di lavoro Aspnet_wp.exe, mediante un account con privilegi minimi.

Utilizzo di un account con privilegi minimi

Utilizzare un account con privilegi minimi per ridurre il rischio associato alla compromissione dei processi. Se un pirata informatico particolarmente determinato riesce a compromettere il processo ASP.NET che esegue l'applicazione Web, può facilmente ereditare e sfruttare i privilegi e i diritti di accesso di cui dispone l'account del processo. Un account configurato con privilegi minimi consente di limitare gli eventuali danni potenziali.

Motivi per evitare l'esecuzione come SYSTEM

Evitare di utilizzare l'account SYSTEM, dotato di privilegi massimi, per eseguire ASP.NET e non concedere il privilegio "Agisci come parte del sistema operativo" all'account del processo ASP.NET. In alcuni casi si ricorre a una delle due opzioni per consentire al codice di chiamare l'API LogonUser in modo da ottenere un'identità fissa, in genere per l'accesso alle risorse di rete. Per informazioni su approcci alternativi, vedere più avanti la sezione "Accesso alle risorse di rete" in questo modulo.

È consigliabile evitare di ricorrere all'esecuzione come SYSTEM o di concedere il privilegio "Agisci come parte del sistema operativo" per i seguenti motivi:

Ulteriori informazioni

Per ulteriori informazioni sul privilegio "Agisci come parte del sistema operativo", vedere la rubrica Security Briefs del Microsoft Systems Journal nell'edizione dell'agosto 1999.

Controller di dominio e account del processo ASP.NET

In generale, una compromissione del server comporterebbe la compromissione del dominio e non è pertanto consigliabile eseguire il server Web in un controller di dominio. Se è indispensabile eseguire ASP.NET in un controller di dominio, è necessario concedere all'account del processo ASP.NET i privilegi appropriati, come indicato nell'articolo Q315158 "BUG: ASP.NET Does Not Work with the Default ASPNET Account on a Domain Controller" (in inglese) della Microsoft Knowledge Base.

Utilizzo dell'account predefinito ASPNET

L'account ASPNET locale è stato configurato appositamente per eseguire applicazioni Web ASP.NET con il minor numero possibile di privilegi. Se possibile, è preferibile quindi utilizzare tale account.

Per impostazione predefinita, le applicazioni Web ASP.NET vengono eseguite utilizzando questo account in base alla configurazione dell'elemento <processModel> nel file machine.config.

<processModel userName="machine" password="AutoGenerate" />

Nota: il nome utente machine indica l'account ASPNET. Quanto si installa .NET Framework, viene creato l'account con una password sicura crittografata. Oltre a essere configurata all'interno del database del sistema di gestione degli account di protezione (SAM), la password viene anche archiviata all'interno dell'autorità di protezione locale (LSA) nel computer locale. Quando il sistema avvia il processo di lavoro ASP.NET, recupera la password dall'autorità di protezione locale.

Se l'applicazione accede alle risorse di rete, è necessario che l'account ASPNET possa essere autenticato dal computer remoto. Le opzioni possibili sono due.

Nota: se l'account locale utilizzato viene compromesso, gli unici computer esposti agli attacchi sono quelli in cui sono stati creati account duplicati. Se si utilizza un account di dominio, questo è visibile su ogni computer del dominio. Per accedere agli altri computer, è necessario tuttavia che l'account disponga dell'apposita autorizzazione.

Elemento <processModel>

L'elemento <processModel> nel file machine.config contiene gli attributi userName e password, che specificano l'account da utilizzare per l'esecuzione del processo di lavoro ASP.NET (Aspnet_wp.exe).

Nota: a differenza della modalità di esecuzione delle applicazioni ASP tradizionali, il codice ASP.NET non viene mai eseguito nel processo dllhost.exe o come account IWAM_MACHINENAME, anche quando il livello di protezione dell'applicazione è impostato su Alta (isolata) in IIS.

Le richieste ASP.NET inviate a IIS vengono indirizzate direttamente al processo di lavoro ASP.NET (Aspnet_wp.exe). L'estensione ISAPI ASP.NET, Aspnet_isapi.dll, viene eseguita nello spazio degli indirizzi del processo IIS (Inetinfo.exe) ed è controllata dalla voce di metabase InProcessIsapiApps, che non deve essere modificata. L'estensione ISAPI è responsabile del routing delle richieste al processo di lavoro ASP.NET. Le applicazioni ASP.NET vengono quindi eseguite nel processo di lavoro ASP.NET, dove i relativi domini forniscono i limiti di isolamento.

La versione 6 di IIS consentirà di isolare le applicazioni ASP.NET tramite la configurazione dei pool di applicazioni, dove ogni pool potrà disporre della propria istanza di applicazione.

Per la configurazione dell'attributo <processModel> userName sono disponibili diverse opzioni. Ad esempio:

Archiviazione di credenziali <processModel> crittografate

Se si utilizzano credenziali personalizzate, archiviarle in forma crittografata nel Registro di sistema mediante l'utilità aspnet_setreg.exe. Evitare di archiviare credenziali non crittografate nel file machine.config.

Per informazioni dettagliate su questa utilità e sul relativo download, vedere l'articolo Q329290 "HOW TO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (in inglese) della Microsoft Knowledge Base.

Nell'esempio riportato di seguito viene illustrato il formato degli attributi userName e password rispettivamente prima e dopo l'utilizzo di questa utilità. Si noti che i valori di attributo puntano alla chiave del Registro di sistema e ai valori denominati protetti contenenti le credenziali crittografate.

<!-- Before -->
<processModel userName="SomeCustomAccount"
              password="ClearTextPassword" . . ./>

<!-- After -->
<processModel
        userName="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,userName"
        password="registry:HKLM\SOFTWARE\YourSecureApp\processModel\
                  ASPNET_SETREG,password" . . ./>
   

Ulteriori informazioni

Inizio pagina

Rappresentazione

Con l'introduzione di FileAuthorizationModule e l'utilizzo efficiente dei gatekeeper e dei limiti di attendibilità, la rappresentazione potrebbe presentare più svantaggi che vantaggi per ASP.NET.

Rappresentazione e risorse locali

Se si utilizza la rappresentazione per accedere alle risorse locali dal codice dell'applicazione Web, è necessario configurare gli ACL allegati a ciascuna risorsa protetta in modo che contengano una voce di controllo di accesso che conceda all'utente autenticato almeno l'accesso in lettura.

Un approccio migliore consiste nell'evitare la rappresentazione, concedere le autorizzazioni all'account del processo ASP.NET e utilizzare l'autorizzazione dell'URL, l'autorizzazione del file e una combinazione di controlli basati sui ruoli di tipo sia dichiarativo che imperativo.

Rappresentazione e risorse remote

Se si utilizza la rappresentazione e quindi si accede alle risorse remote dal codice dell'applicazione Web, la procedura di accesso avrà esito positivo solo a condizione che venga utilizzata l'autenticazione di base, basata su moduli o Kerberos. Se si utilizza l'autenticazione Kerberos, è necessario configurare opportunamente gli account utente per la delega e contrassegnarli con l'opzione "L'account è sensibile e non può essere delegato" all'interno di Active Directory.

Ulteriori informazioni

Per ulteriori informazioni sulla procedura di configurazione della delega Kerberos, vedere quanto segue:

Rappresentazione e threading

Se un thread che sta eseguendo la rappresentazione crea un nuovo thread, quest'ultimo eredita il contesto di protezione dell'account del processo ASP.NET anziché quello dell'account rappresentato.

Inizio pagina

Accesso alle risorse di sistema

Per impostazione predefinita, ASP.NET non esegue alcuna rappresentazione. Se l'applicazione Web accede alle risorse del sistema locale, l'accesso viene eseguito pertanto mediante il contesto di protezione associato al processo di lavoro Aspnet_wp.exe. Il contesto di protezione è determinato dall'account utilizzato per eseguire il processo di lavoro.

Accesso al registro eventi

Gli account con privilegi minimi dispongono di autorizzazioni sufficienti per scrivere dei record nel registro eventi mediante le origini eventi esistenti. Non dispongono tuttavia delle autorizzazioni necessarie per creare nuove origini eventi, per le quali è necessario immettere una nuova voce al di sotto dell'hive del Registro di sistema.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<log>

Per evitare questo problema, creare le origini eventi utilizzate dall'applicazione al momento dell'installazione, quando sono disponibili i privilegi di amministratore. Un approccio ottimale consiste nell'utilizzo di una classe del programma di installazione .NET di cui è possibile creare un'istanza mediante Windows Installer se si utilizza la distribuzione msi o, in caso contrario, mediante l'utilità di sistema InstallUtil.exe.

Se non è possibile creare le origini eventi al momento dell'installazione, è necessario aggiungere l'autorizzazione alla chiave del Registro di sistema seguente e concedere l'accesso all'account del processo ASP.NET di qualsiasi account rappresentato, qualora l'applicazione utilizzi la rappresentazione.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog 

Gli account devono disporre delle seguenti autorizzazioni minime:

Per scrivere nel registro eventi dell'applicazione da ASP.NET dopo avere applicato le autorizzazioni al Registro di sistema, è possibile utilizzare il seguente codice:

string source = "Your Application Source";
string logToWriteTo = "Application";
string eventText = "Sample Event";

if (!EventLog.SourceExists(source))
{
  EventLog.CreateEventSource(source, logToWriteTo);
}
EventLog.WriteEntry(source, eventText, EventLogEntryType.Warning, 234);

Accesso al Registro di sistema

Per accedere a qualsiasi chiave del Registro di sistema dall'applicazione è necessario disporre di una voce di controllo di accesso nell'ACL che conceda almeno l'accesso in lettura all'account del processo ASP.NET.

Ulteriori informazioni

Per ulteriori informazioni sulle classi dei programmi di installazione e sull'utilità InstallUtil.exe, vedere la sezione ".NET Framework Tools" (in inglese) nel sito MSDN.

Inizio pagina

Accesso agli oggetti COM

Nei contesti ASP tradizionali, le richieste vengono elaborate mediante thread del pool STA (Single Threaded Apartment). In ASP.NET, le richieste vengono invece elaborate mediante thread del pool MTA (Multithreaded Apartment). Il tipo di elaborazione influisce sulle applicazioni Web ASP.NET che chiamano gli oggetti del modello di threading Apartment.

Oggetti del modello Apartment

Quando un'applicazione Web ASP.NET chiama un oggetto del modello Apartment, ad esempio un oggetto Visual Basic 6 COM, è necessario tenere presente i due punti seguenti:

<%@ Page Language="C#" AspCompat="True" %>

Perché è necessaria l'istruzione AspCompat

Per impostazione predefinita, ASP.NET utilizza i thread MTA per elaborare le richieste. Quando un oggetto del modello Apartment viene chiamato da ASP.NET, si verifica pertanto una commutazione di thread in quanto non è possibile accedere direttamente a tale oggetto mediante thread MTA. In COM, infatti, viene utilizzato un thread STA.

Se si specifica AspCompat, la pagina viene elaborata da un thread STA, evitando in tal modo la commutazione da thread MTA a thread STA. Questo aspetto assume importanza in termini di protezione nel caso in cui l'applicazione Web stia eseguendo la rappresentazione, in quanto la commutazione di thread determina la perdita del token di rappresentazione. In questo caso, al nuovo thread non viene associato alcun token di rappresentazione.

L'istruzione AspCompat non è supportata dai servizi Web ASP.NET. Quando si chiama un oggetto del modello Apartment dal codice del servizio Web, si verifica pertanto una commutazione di thread e si perde il token di rappresentazione del thread, generando di solito un'eccezione di Accesso negato.

Ulteriori informazioni

Perché evitare la creazione di oggetti COM al di fuori di eventi Page specifici

È consigliabile evitare di creare gli oggetti COM al di fuori di gestori eventi Page specifici. Nel frammento di codice riportato di seguito vengono illustrati gli errori da evitare.

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
  // COM object created outside of Page events
  YourComObject obj = new apartmentObject();
  public void Page_Load()
  {
    obj.Foo()
  }
</script>

Quando si utilizzano oggetti del modello Apartment è importante creare l'oggetto all'interno di eventi Page specifici, ad esempio Page_Load, come indicato di seguito.

<%@ Page Language="C#" AspCompat="True" %>
<script runat="server">
public void Page_Load()
{
  YourComObject obj  = new apartmentObject();
  obj.Foo()
}
</script>

Ulteriori informazioni

Per ulteriori informazioni, vedere l'articolo Q308095 , "PRB: Creating STA Components in the Constructor in ASP.NET ASPCOMPAT Mode Negatively Impacts Performance" (in inglese) della Microsoft Knowledge Base.

Oggetti C# e VB .NET in COM+

Lo strumento di sviluppo Microsoft C#(r) e il sistema di sviluppo Microsoft Visual Basic(r) .NET supportano tutti i modelli di threading, ovvero Free-threaded, Neutral, Both e Apartment. Per impostazione predefinita, quando l'hosting degli oggetti C# e Visual Basic .NET viene eseguito in COM+, gli oggetti sono contrassegnati come Both. Di conseguenza, quando vengono chiamati da ASP.NET, l'accesso è diretto e non si verifica alcuna commutazione di thread.

Inizio pagina

Accesso alle risorse di rete

È probabile che l'applicazione debba accedere alle risorse di rete. In tal caso, è importante identificare quanto segue:

Nota: per informazioni specifiche sull'accesso ai database SQL Server remoti, vedere il modulo 12 "Protezione dell'accesso ai dati".

È possibile accedere alle risorse remote dall'applicazione ASP.NET mediante una delle seguenti tecniche:

Utilizzo dell'identità del processo ASP.NET

Se l'applicazione non è configurata per la rappresentazione e tenta di accedere alle risorse remote, l'identità del processo ASP.NET fornisce l'identità predefinita. Se si desidera utilizzare l'account del processo ASP.NET per l'accesso alle risorse remote, è possibile scegliere tra le tre alternative seguenti:

Ulteriori informazioni

Per ulteriori informazioni sulla configurazione di un account del processo ASP.NET, vedere "Procedura - Creazione di un account personalizzato per eseguire ASP.NET" in questa guida.

Utilizzo di un componente servito

Per accedere alle risorse di rete è possibile utilizzare un componente servito out-of-process, configurato per essere eseguito come identità fissa. L'approccio descritto è illustrato nella figura 8.6.

Figura 8.6
Utilizzo di un componente servito out-of-process per fornire un'identità fissa per l'accesso alle risorse di rete

L'utilizzo di un componente servito out-of-process in un'applicazione server Enterprise Services presenta i seguenti vantaggi:

Utilizzo dell'account utente Internet anonimo

Se IIS viene configurato per l'autenticazione anonima, è possibile accedere alle risorse di rete utilizzando l'account utente Internet anonimo. Tale approccio è consigliato se è vera una delle due condizioni seguenti:

<identity impersonate="true" />

Importante: se si esegue la rappresentazione dell'account anonimo, ad esempio IUSR_MACHINE, è necessario proteggere le risorse rispetto a questo account mediante ACL opportunamente configurati. È necessario che le risorse a cui l'applicazione deve accedere concedano almeno l'accesso in lettura per l'account anonimo. Tutte le altre risorse dovrebbero invece negare l'accesso all'account anonimo.

Hosting di più applicazioni Web

È possibile utilizzare un account utente Internet anonimo distinto per ciascuna directory principale virtuale contenuta nel sito Web. In un ambiente di hosting, ciò consente di autorizzare, registrare e controllare separatamente le richieste generate da applicazioni Web diverse. L'approccio descritto è illustrato nella figura 8.7.

Figura 8.7
Rappresentazione di account utente Internet anonimi per singola applicazione (v-dir)

Utilizzo di LogonUser e rappresentazione di un'identità di Windows specifica

È possibile eseguire la rappresentazione di un'identità specifica configurando gli attributi di nome utente e password nell'elemento <identity> del file web.config o chiamando l'API LogonUser Win32(r) nel codice dell'applicazione.

Importante: Come descritto in precedenza in questo modulo, non è consigliabile utilizzare LogonUser o un'identità rappresentata fissa con .NET Framework 1.0 su server Windows 2000, in quanto impone l'assegnazione del privilegio "Agisci come parte del sistema operativo" all'account del processo ASP.NET.

In Windows .NET Server 2003 questa limitazione verrà eliminata. Nella versione 1.1 di .NET Framework verrà introdotto inoltre un miglioramento per questo scenario relativo a Windows 2000. L'accesso verrà eseguito dal processo IIS, in modo che ASP.NET non richieda il privilegio "Agisci come parte del sistema operativo".

Utilizzo del chiamante originale

Per utilizzare l'identità del chiamante originale per l'accesso remoto alle risorse è necessario che il server Web sia in grado di delegare il contesto di protezione del chiamante al computer remoto.

Avviso sulla scalabilità: l'accesso al livello dei servizi dati dell'applicazione tramite la rappresentazione dell'identità del chiamante originale influisce negativamente sulla scalabilità dell'applicazione, in quanto limita l'efficienza del pooling delle connessioni al database. Il contesto di protezione delle connessioni al database è diverso per ciascun utente.

La delega è supportata dai seguenti schemi di autenticazione:

<authentication mode="Window" />
<identity impersonate="true" />

Ulteriori informazioni

Accesso ai file in una condivisione file UNC

Se l'applicazione deve accedere ai file inclusi in una condivisione UNC (Universal Naming Convention) tramite ASP.NET, è importante aggiungere le autorizzazioni NTFS alla cartella della condivisione. È necessario impostare anche le autorizzazioni della condivisione affinché concedano almeno l'accesso in lettura all'account del processo ASP.NET o all'identità di cui si esegue la rappresentazione, qualora sia prevista dalla configurazione dell'applicazione.

Accesso a risorse di rete diverse da Windows

Se l'applicazione deve accedere a risorse diverse da Windows quali i database situati in piattaforme o in applicazioni mainframe diverse da Windows, è necessario tenere presente quanto segue:

Se la risorsa deve essere in grado di autenticare il chiamante originale e non è possibile scegliere l'autenticazione di Windows, sono disponibili le seguenti opzioni:

Inizio pagina

Comunicazione protetta

Utilizzare il protocollo SSL per proteggere il collegamento di comunicazione tra browser e server Web. Il protocollo SSL garantisce la riservatezza e l'integrità dei messaggi. Utilizzare il protocollo SSL e/o IPSec per fornire un canale sicuro dal server Web al server applicazioni o al server di database.

Ulteriori informazioni

Per ulteriori informazioni sulla comunicazione protetta, vedere il modulo 4 "Comunicazione protetta".

Inizio pagina

Archiviazione di segreti

Per le applicazioni Web, spesso è necessario archiviare i segreti per salvaguardarli da amministratori inaffidabili e utenti Web malintenzionati.

Di seguito vengono elencati alcuni esempi tipici di segreti.

<identity impersonate="true" userName="bob" password="inClearText"/>

<process userName="cUsTuMUzerName" password="kUsTumPazzWerD" >

<sessionState ... stateConnectionString="tcpip=127.0.0.1:42424"
                sqlConnectionString="data source=127.0.0.1;
                user id=UserName;password=MyPassword" />

Opzioni per l'archiviazione di segreti in ASP.NET

Gli sviluppatori di applicazioni Web .NET possono disporre di vari approcci per l'archiviazione di segreti, tra cui:

Ulteriori informazioni

Per ulteriori informazioni, vedere le voci relative a crittografia, CryptoAPI e CAPICOM in Platform SDK (in inglese) nel sito MSDN.

Archiviazione di segreti in file su volumi logici distinti

È possibile installare le directory delle applicazioni Web in un volume logico diverso da quello in cui è installato il sistema operativo, ad esempio E: anziché C:. In tal caso il file machine.config situato nella directory C:\WINNT\Microsoft.NET e gli eventuali altri file contenenti segreti, ad esempio i file UDL (Universal Data Link), si trovano in un volume logico diverso rispetto alle directory delle applicazioni Web.

L'obiettivo logico di questo approccio è garantire la protezione contro la normalizzazione dei file e gli errori di attraversamento delle directory, in quanto:

Tuttavia non è stata ancora pubblicata alcuna documentazione sull'errore precedentemente descritto che espone i file in altri volumi logici.

Inizio pagina

Protezione dello stato di sessione e visualizzazione

Le applicazioni Web devono gestire tipi diversi di stato, tra cui lo stato di visualizzazione e lo stato di sessione. In questa sezione viene descritta la gestione protetta dello stato per le applicazioni Web ASP.NET.

Protezione dello stato di visualizzazione

Se le applicazioni Web ASP.NET utilizzano lo stato di visualizzazione, effettuare le seguenti operazioni:

<% @ Page enableViewStateMac=true %>

Protezione dei cookie

Durante il trasferimento, è consigliabile proteggere i cookie contenenti dati di autenticazione, di autorizzazione o altri dati riservati tramite il protocollo SSL. Per l'autenticazione basata su moduli, è possibile utilizzare il metodo FormsAuthentication.Encrypt per crittografare il ticket di autenticazione scambiato tra client e server in un cookie.

Protezione dello stato di sessione SQL

Il gestore predefinito (in-process) dello stato di sessione ASP.NET presenta alcune limitazioni. Ad esempio, non può essere utilizzato nei computer di una Web farm. Per ovviare a questa limitazione, ASP.NET consente l'archiviazione dello stato di sessione in un servizio di stato remoto o un database SQL Server.

È possibile configurare lo stato di sessione SQL nei file machine.config o web.config. L'impostazione predefinita nel file machine.config è riportata di seguito.

<sessionState mode="InProc" 
              stateConnectionString="tcpip=127.0.0.1:42424" 
              stateNetworkTimeout="10"
              sqlConnectionString="data source=127.0.0.1;user id=sa;password="
              cookieless="false" timeout="20"/>

Per impostazione predefinita, lo script SQL InstallSqlState.sql, impiegato per la creazione del database utilizzato per lo stato di sessione SQL, viene installato nel seguente percorso:

C:\WINNT\Microsoft.NET\Framework\v1.0.3705

Quando si utilizza lo stato di sessione SQL, occorre tenere conto di due problemi.

Protezione della stringa di connessione al database

Se si utilizza l'autenticazione SQL per la connessione al server, la stringa di connessione specificata nell'attributo sqlConnectionString contiene un nome utente e una password. Per archiviare una stringa di connessione crittografata nel Registro di sistema, utilizzare l'utilità aspnet_setreg.exe. Nell'esempio riportato di seguito viene illustrato l'elemento <sessionState> rispettivamente prima e dopo l'utilizzo di aspnet_setreg.exe.

<!-- Before -->
<sessionState 
    mode="SQLServer", 
    sqlConnectionString="data source=Server;user id=userID;password=pwd" . . . />
<!-- After -->
<sessionState mode="SQLServer"
              sqlConnectionString="registry:HKLM\SOFTWARE\YourSecureApp\
              sessionState\ASPNET_SETREG,sqlConnectionString" />

Nota: se si utilizza il servizio di stato ASP.NET, è possibile utilizzare aspnet_setreg.exe anche per crittografare l'attributo stateConnectionString.

Se possibile, utilizzare l'autenticazione di Windows nel database di stato SQL Server in quanto presenta due vantaggi aggiuntivi, ovvero le credenziali non sono contenute nella stringa di connessione e non vengono trasferite in rete al server di database.

Successivamente è possibile modificare la stringa di connessione per utilizzare una connessione trusted, come illustrato di seguito.

sqlConnectionString="server=127.0.0.1;
                     database=StateDatabase;
                     Integrated Security=SSPI;"

Protezione dello stato di sessione nella rete

Potrebbe essere necessario proteggere lo stato di sessione durante il trasferimento in rete al database SQL Server. Ciò dipende dal livello di protezione della rete che esegue l'hosting del server Web e dei server di dati. Se il database è protetto fisicamente in un ambiente trusted, potrebbe essere possibile fare a meno di questa misura di protezione aggiuntiva.

È possibile utilizzare il protocollo IPSec per proteggere tutto il traffico IP tra i server Web e SQL Server oppure, in alternativa, utilizzare il protocollo SSL per proteggere il collegamento a SQL Server. Questo approccio consente inoltre di crittografare esclusivamente la connessione utilizzata per lo stato di sessione anziché tutto il traffico scambiato tra i computer.

Ulteriori informazioni

Inizio pagina

Considerazione sulle Web farm

Nello scenario di una Web farm, non vi è alcuna garanzia che le richieste successive dello stesso client vengano elaborate dallo stesso server Web. Questo fatto ha implicazioni precise sulla gestione dello stato e su qualsiasi tipo di crittografia basata sugli attributi gestiti dall'elemento <machineKey> nel file machine.config.

Stato di sessione

La gestione dello stato di sessione in-process ASP.NET predefinito, che rispecchia la precedente funzionalità ASP, determina l'affinità con il server e non può quindi essere utilizzata in uno scenario di una Web farm. Per la distribuzione in una Web farm è necessario che lo stato di sessione sia archiviato con modalità out-of-process nel servizio di stato ASP.NET o in un database SQL Server, come descritto in precedenza.

Nota: poiché lo stato dell'applicazione non è condiviso da più processi o computer, non è possibile affidare ad esso la gestione dei contatori globali o dei valori univoci negli scenari di Web farm, in cui l'applicazione Web è configurata per l'esecuzione su più server, o Web garden, in cui l'applicazione Web è configurata per l'esecuzione su più processori.

DPAPI

L'interfaccia DPAPI può essere utilizzata con l'archivio del computer oppure con l'archivio dell'utente, che richiede il caricamento di un profilo utente. Nel primo caso, la stringa crittografata è specifica di un determinato computer e pertanto è necessario generare i dati crittografati su ogni computer. Non copiare i dati crittografati da un computer all'altro in una Web farm o in un cluster.

Se invece si utilizza l'interfaccia DPAPI con l'archivio dell'utente, è possibile decrittografare i dati in qualsiasi computer mediante un profilo utente comune.

Ulteriori informazioni

Per ulteriori informazioni sull'interfaccia DPAPI, vedere il modulo 12 "Protezione dell'accesso ai dati".

Utilizzo dell'autenticazione basata su moduli in una Web farm

Se si utilizza l'autenticazione basata su moduli, è essenziale che tutti i server della Web farm condividano una chiave del computer comune per la crittografia, la decrittografia e la convalida del ticket di autenticazione.

La chiave del computer viene gestita dall'elemento <machineKey> all'interno del file machine.config. Di seguito è riportata l'impostazione predefinita.

<machineKey validationKey="AutoGenerate" 
            decryptionKey="AutoGenerate" 
            validation="SHA1"/> 

In base a questa impostazione, tutti i computer generano una chiave di convalida e di decrittografia diversa. È necessario modificare l'elemento <machineKey> e inserire valori di chiave comuni in tutti i server della Web farm.

Elemento <machineKey>

L'elemento <machineKey> configurare le chiavi utilizzate per la crittografia e la decrittografia dei dati del cookie di autenticazione basata su moduli, nonché per il controllo e la crittografia dell'integrità dello stato di visualizzazione.

Quando vengono chiamati i metodi FormsAuthentication.Encrypt o FormsAuthentication.Decrypt e viene creato o recuperato lo stato di visualizzazione, vengono consultati i valori contenuti nell'elemento <machineKey>.

<machineKey validationKey="autogenerate|value"
            decryptionKey="autogenerate|value"
            validation="SHA1|MD5|3DES" />

Attributo validationKey

Il valore dell'attributo validationKey viene utilizzato per creare e convalidare i codici MAC per lo stato di visualizzazione e i ticket di autenticazione basata su moduli. L'attributo di convalida indica l'algoritmo da utilizzare per la generazione dei codici MAC. È necessario tenere presente quanto segue.

Attributo decryptionKey

Il valore dell'attributo decryptionKey viene utilizzato per crittografare e decrittografare i ticket di autenticazione basata su moduli e lo stato di visualizzazione. Vengono utilizzati gli algoritmi DES o Triple DES (3DES). La scelta dell'algoritmo specifico viene effettuata a seconda che sul server sia installato o meno Windows 2000 High Encryption Pack. Se è installato, viene utilizzato 3DES; in caso contrario, viene utilizzato DES. È necessario tenere presente quanto segue.

Attributo Validation

L'attributo determina l'algoritmo da utilizzare durante la convalida, la crittografia o la decrittografia. Può assumere i valori SHA1, MD5 o 3DES descritti di seguito.

Ulteriori informazioni

Inizio pagina

Riepilogo

In questo modulo è stata descritta una vasta gamma di tecniche e approcci per la protezione delle applicazioni Web ASP.NET. La maggior parte delle indicazioni e dei consigli presentati in questo modulo è valida anche per lo sviluppo di servizi Web ASP.NET e di oggetti .NET Remoting il cui hosting è eseguito da ASP.NET. I concetti di base di questo modulo possono essere riassunti nei punti seguenti:

Inizio pagina

9 - 14