I controlli da codice consentono ovviamente di avere la massima libertà sulle modalità di controllo degli accessi a risorse e operazioni applicative, ma prima di iniziare a scriverci funzioni e assembly di controllo è bene valutare se il meccanismo di Authorization nativo di ASP.NET può essere sufficiente; almeno per alcune sezioni dell’applicazione.

Ancora una volta le impostazioni sulle autorizzazioni per utenti e ruoli si effettuano nel file Web.Config dell’applicazione. I tag per configurare gli accessi all’intera applicazione sono autoesplicativi:

<authorization>
    <deny users=“?” />
    <allow roles=“DevLeap\Sviluppatori” />
    <allow users=”DevLeap\RobertoB” />
    <deny users=“*” />
</authorization>

La sezione <authorization> deve essere inserita nella sottosezione <system.web> della sezione <configuration>.
Come si nota dall’esempio esistono due clausole, allow e deny, all’interno delle quali viene specificato il tipo di utenza (utente o ruolo) e il nome dell’utenza stessa (come sempre preceduta dal nome del dominio).
I settaggi si applicano secondo la regola “First Match Wins”. Quindi nell’esempio seguente il secondo tag verrebbe ignorato

    <allow users=”DevLeap\RobertoB” />
    <deny users=”DevLeap\RobertoB” />

in quanto, a fronte di un accesso di RobertoB, il primo tag ha un match esatto con l’utente (consentendogli l’accesso).

I due caratteri speciali, usati nell’esempio precedente, “*” e “?”, significano rispettivamente “All users” e “Anonymous User”.
Ad esempio, per negare l’accesso all’applicazione agli utenti non autenticati occorre inserire il tag <deny users=”?” /> seguito da <allow users=”*” />. Il primo tag blocca l’account anonimo e il secondo di conseguenza consente l’accesso a tutti gli altri utenti.

Per continuare con gli esempi, non ha senso la seguente configurazione:

<authorization>
    <deny users=“?” />
    <allow roles=“DevLeap\Sviluppatori” />
    <allow users=”DevLeap\RobertoB” />
    <allow users=“*” />
</authorization>

in quanto i primi due “allow” sarebbero già contenuti nel terzo “allow”.

Se l’account RobertoB fosse membro del gruppi sviluppatori del dominio DevLeap non avrebbe senso neanche:

<authorization>
    <deny users=“?” />
    <allow roles=“DevLeap\Sviluppatori” />
    <allow users=”DevLeap\RobertoB” />
</authorization>

La lista di “allow/deny” di un’applicazione in realtà è più complessa, in quanto vengono presi in considerazione tutti i file Web.Config nella gerarchia delle directory dell’applicazione. Mi spiego meglio: se la nostra applicazione è memorizzata nella directory c:\WebApps\Applicazione1, oltre al file Web.Config presente in tale directory, viene considerato anche il file Web.Config evenutalmente presente nella directory WebApps e per assurdo anche il file Web.Config evenutalmente presente su C:\.

Ancora un esempio per chiarire il concetto:

La nostra applicazione in c:\WebApps\Applicazione1 contiene le seguenti impostazioni nel file Web.Config

 <deny users=”?” />
 <allow roles=”DevLeap\Sviluppatori” />

La directory parent (C:\WebApps) contiene le seguenti impostazioni nel file Web.Config

 <deny users=”DevLeap\Segreteria” />
 <allow roles=”DevLeap\Administrators” />

L’elenco di “allow/deny” per l’applicazione in questione risulterà il seguente:

 <deny users=”?” />
 <allow roles=”DevLeap\Sviluppatori” />
 <deny users=”DevLeap\Segreteria” />
 <allow roles=”DevLeap\Administrators” />

All’elenco di “allow/deny” derivante dalla somma di tutti i file Web.Config delle directory applicative viene aggiunto anche l’elenco presente nel file Machine.Config (nella directory X:\WINNT\Microsoft.NET\Framework\versione\CONFIG).

N.B.: per default nel file Machine.Config è presente il tag <allow users=”*” />, che, come abbiamo visto, consente l’accesso a chiunque.

Quindi proseguendo il nostro esempio precedente il risultato finale sarà:

 <deny users=”?” />
 <allow roles=”DevLeap\Sviluppatori” />
 <deny users=”DevLeap\Segreteria” />
 <allow roles=”DevLeap\Administrators” />
 <allow users=”*” />

E’ necessario quindi, oltre a porre attenzione a questa gerarchia, inserire sempre un tag <deny users=”*” /> in tutte le applicazioni a cui devono accedere solo gli utenti indicati con un <allow> specifico, altrimenti, l’impostazione del file machine.config consentirà sempre l’accesso a tutti gli utenti non esplicitamente bloccati dai vari Web.Config.

Quindi un file Web.Config adeguato per un’applicazione che consenta l’accesso solo ai gruppi Sviluppatori e Administrators del dominio DevLeap dovrebbe essere il seguente:

 <deny users=”?” />
 <allow roles=”DevLeap\Sviluppatori” />
 <allow roles=”DevLeap\Administrators” />
 <deny users=”*” />

in modo che l’aggiunta del tag <allow users=”*” /> presente nel file machine.config non abbia alcun effetto sull’applicazione (ricordate “First Match Wins”).

Questa gerarchia delle impostazioni presenti nei vari Web.Config consente di raggruppare applicazioni con impostazioni di autorizzazioni simili in sottodirectory di una directory padre (madre se per voi directory è femminile :-)). Nel file Web.Config della directory padre si impostano le autorizzazioni comuni, mentre nei Web.Config specifici si impostano le eccezioni.

Lo stesso ragionamento si può applicare al file Machine.config: se tutte (o molte) applicazioni di un server web contengono le stesse impostazioni di sicurezza potremmo decidere di settare gli “allow/deny” comuni in tali file e gestire le eccezioni nei vari Web.config delle applicazioni, che ricordiamo, vengono comunqu valutati prima.

Oltre ai settaggi comuni a tutta l’applicazione, che abbiamo finora analizzato, i tag di autorizzazione possono essere inseriti nel tag location (utilizzabile anche per altre impostazioni applicative) per indicare permessi di accesso specifici per una risorsa/directory applicativa.

Ad esempio se un’applicazione dovesse
1) Consentire accesso all’utente anonimo per alcune sezioni di sito
2) Bloccarne l’accesso anonimo per la directory “News” consentendone l’utilizzo solo ai gruppi “NewsUsers” e “Sviluppatori”
3) Negare l’accesso agli utenti non autenticati alla pagina “ComunicatiStampa.aspx”

il file Web.config dovrebbe essere impostato come segue:
 <authorization>
  <allow users=”?” />
 </authorization>
 <location path=”News” />
  <authorization>
   <deny users=”?” />
   <allow roles=”DevLeap\NewsUsers” />
   <allow roles=”DevLeap\Sviluppatori” />
  </authorization>
 </location>  
 <location path=”ComunicatiStampa.aspx” />
  <authorization>
   <deny users=”?” />
  </authorization>
 </location>  

Concludiamo questo articolo con l’ultimo dettaglio: le classi .NET che si occupano di gestire l’autenticazione Windows e le autorizzazioni sulle risorse nell’environment ASP.NET.
Per un approfondimento sul concetto di Handler e Module si rimanda all’articolo ASP.NET Process Model.

Sappiamo che le impostazioni di configurazione di ASP.NET si trovano nel file Machine.Config e che ogni applicazioni ASP.NET può aggiungere o rimuovere elementi di configurazione nel file Web.Config. Per default la configurazione dei moduli (HttpModule) che si incaricano di gestire autenticazione e autorizzazione sono nel file Machine.Config.

Il codice seguente è stato estratto, senza modifiche, dal file Machine.Config:

<httpModules>
            <add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule, System.Web, Version=1.0.2411.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

Come si può notare il modulo che si incarica di gestire l’autenticazione Windows per le applicazioni ASP.NET è denominato WindowsAuthentication ed è gestito dalla classe System.Web.Security.WindowsAuthenticationModule dell’assembly condiviso System.Web.dll.

Il codice seguente (sempre estratto senza modifiche dal file Machine.Config) fa invece riferimento ai moduli http che si incaricano, rispettivamente, di controllare le autorizzazioni sugli url e sul file system. Ancora una volta le classi (System.Web. Security.UrlAuthorizationModule e System.Web.Security.FileAuthorizationModule) fanno parte dell’assembly System.Web.dll

<httpModules>

            <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule, System.Web, Version=1.0.2411.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
            <add name="FileAuthorization" type="System.Web.Security.FileAuthorizationModule, System.Web, Version=1.0.2411.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

Ricordiamoci che i moduli http vengono attraversati in seguenza per ogni richiesta http e nella sequenza inversa per ogni risposta Http, come mostrato dalla seguente figura estratta dall’articolo ASP.NET Process Model a cui si rimanda per ulteriori informazioni sull’architettura e le componenti del processo ASP.NET

 

Un ultimo appunto: negli esempi di codice è necessario modificare il nome del dominio, degli utenti e dei gruppi per far riferimento alla propria configurazione.