Di Daniele Bochicchio - Microsoft MVP

Uno degli scenari più diffusi nelle applicazioni web e al tempo stesso più difficile da gestire, specie con le versioni 1.x di ASP.NET, riguarda l’autenticazione e l’autorizzazione all’accesso a pagine protette.È una funzionalità da cui moltissime applicazioni web ormai non possono più prescindere, perché consente di dare accesso ad alcune aree solo a determinati utenti, provvisti di certi privilegi, così da rendere possibile, ad esempio, l’aggiunta di un’area ad accesso riservato, che consente di amministrare in tutta sicurezza e autonomia l’applicazione.ASP.NET 2.0 introduce, in quest’ ambito, sostanziose e interessanti novità, volte soprattutto a rendere più semplice l’implementazione di queste funzionalità, attraverso Membership e Roles API, costruite intorno al Provider Model, un modello teso a favorire lo sviluppo di applicazioni basate su provider, facili da creare e immediati da configurare.

In questa pagina

 I concetti di autenticazione e autorizzazione
 Un passo indietro: il Provider Model
 L’utente per ASP.NET: Principal e Identity
 Gestione degli utenti con Membership API
 Il Membership Provider per SQL Server
 Il Membership Provider per Active Directory
 Roles API: gestione dei ruoli
 Il Roles Provider per SQL Server
 I nuovi server control di login
 CreateUserWizard
 Login
 LoginStatus e LoginName
 ChangePassword e PasswordRecovery
 LoginView
 Provider aggiuntivi e custom
 Conclusioni

I concetti di autenticazione e autorizzazione

Per comprendere in modo adeguato quanto sia potente l’approccio usato da ASP.NET, è necessario per prima cosa fare una piccola parentesi sui meccanismi di autenticazione utilizzati sin dalle prime versioni, che poi rappresentano la base su cui Membership e Roles API si poggiano.

Questi componenti non fanno altro che utilizzare un pezzo dell’architettura di HttpRuntime, cioè del cuore di ASP.NET, chiamato HttpModule. Si tratta di classi particolari che si registrano per gli eventi di HttpApplication, che rappresenta l’applicazione ASP.NET, così da poter inserire delle proprie personalizzazioni in risposta agli eventi che quest’ultima scatena durante il proprio ciclo di vita. Un HttpModule, infatti, implementa l’interfaccia IHttpModule ed è molto semplice da creare, poiché nel proprio metodo Init generalmente si registra per alcuni eventi.

Nel caso degli AuthenticationModule, questo evento è AuthenticateRequest di HttpApplication, che si scatena ogni volta che ASP.NET ha bisogno di autenticare una richiesta.

ASP.NET, sin dalla prima versione, è provvisto di tre HttpModule specifici, ognuno per la differente tipologia di autenticazione, di cui il nome già rappresenta un segno:

• FormsAuthenticationModule;

• WindowsAuthenticationModule;

• PassportAuthenticationModule.

<configuration>

<system.web>

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

</system.web>

</configuration>

Il primo è rivolto essenzialmente a siti pubblici che non rientrino nell’ambito delle Intranet, per cui è consigliabile il secondo. Sull’ultimo, specifico per Passport, si può anche sorvolare, dato che è un servizio che difficilmente incontrerete nel vostro cammino, considerando che è ad uso e consumo di Microsoft.

Per aggiungere un po’ di chiarezza, occorre sottolinea che l’autenticazione è quella fase in cui si stabilisce che, date le credenziali fornite, l’utente possa essere riconosciuto con certezza. Le diverse tipologie di autenticazione supportate da ASP.NET sono in realtà tutte riconducibili allo stesso risultato finale, anche se partono da punti differenti, per adattarsi alle diverse modalità con cui si può decidere di proteggere l’applicazione.

L’autorizzazione, d’altra parte, è quel processo con cui si verifica che un utente, che può essere già stato autenticato o essere anonimo, può avere accesso alle risorse che richiede.

Anche se sono utilizzate insieme, questi due ambiti sono separati, tanto è vero che in ASP.NET 2.0 gli HttpModule preposti a gestire l’autorizzazione sono chiamati AuthorizationModule, perché intercettano l'evento AuthorizeRequest di HttpApplication, che si verifica per garantire che l’accesso a una certa risorsa sia possibile.

ASP.NET include l’UrlAuthorizationModule, che si occupa di gestire l'accesso agli URL, ed il FileAuthorizationModule, che invece confronta l’utente secondo le ACL di Windows.

Per via del suo funzionamento, è il primo dei due a essere utilizzato nella quasi totalità dei casi, specificando le politiche di accesso all'interno del web.config, potendo impostare sia le policy relative a utenti che ai ruoli.

<configuration>
  <system.web>
    <authorization>
      <allow roles="utente1;utente2" />
      <deny users="*" />
      <deny users="?" />
    </authorization>
  </system.web>

  <location path="pagina.aspx">
    <system.web>
      <authorization>
        <allow roles="ruolo1;ruolo2" />
        <deny users="*" />
  <deny users="?" />
      </authorization>
    </system.web>
  </location>
</configuration>

Con deny si nega un ruolo o utente, con allow invece si concede l'accesso. Il carattere "*" rappresenta tutti gli utenti autenticati (o ruoli), mentre "?" indica gli utenti anonimi. Qualora ci sia bisogno di avere un controllo più granulare, la definizione delle policy può essere fatta utilizzando il tag location, specificando nuovamente la stessa struttura del ramo principale. Le policy vengono applicate secondo un algoritmo di short-circuiting, per cui la prima che dovesse verificarsi, fa sì che le successive vengano ignorate.

Questa tipologia di protezione è utile in quasi tutti i casi, ma qualora non sia sufficiente, la soluzione è quella di creare un proprio HttpModule, che intercetti, così come fanno quelli di default, l’evento scatenato con l’autorizzazione. Questo scenario è da preferire, ad esempio, se i ruoli applicativi sono dettati da parametri non fissi, come ad esempio l’ora del giorno o il risultato di una query.

Un passo indietro: il Provider Model

Il Provider Model è un design pattern, cioè un insieme di linee guida da utilizzare in fase di design dell'applicazione web, il tentativo di rendere in forma teorica ciò che ci viene dettato dall'esperienza quotidiana. Un pattern è in pratica un nome dato a una problematica e alla relativa soluzione, così che universalmente ci si possa riferire a un concetto usando un nome.

Il Provider Model può essere considerato come l’uso congiunto di altri pattern già definiti, dove lo Strategy Pattern, che appartiene alla famiglia dei pattern GOF (Gang of Four), è sicuramente quello che si nota con maggior facilità: si basa sulla creazione di una famiglia di algoritmi, incapsulati e resi intercambiabili tra di loro, richiamati in maniera indipendente dal contesto.

In parole povere si basano sull'esistenza di un'implementazione generica, che sarà sfruttata dall’esterno (le API), ed una concreta (il provider), che sarà utilizzata da quella generica come ponte verso il conseguimento del risultato desiderato.

Il vantaggio di questo approccio è che cambiando il provider non è necessario cambiare il codice che richiama le API, che è poi l'unica interfaccia utilizzata dalle applicazioni. Grazie a questa caratteristica è possibile creare applicazioni che, basate sulle API, siano in grado di funzionare in qualsiasi situazione, perché è sufficiente cambiare il provider per cambiare il modo in cui l’applicazione stessa agisce.

Nel caso di ASP.NET, il provider è specificato attraverso il web.config e caricato, attraverso un'operazione di Dependency Injection, quando le API hanno bisogno di fornire una determinata funzionalità.

Il vantaggio di questo modello è che qualsiasi sviluppatore può creare un provider, dato che le API rappresentano un ponte verso il provider, che è l'effettivo componente che fornisce l’implementazione concreta, avendo al tempo stesso il medesimo approccio, garantito dall’utilizzo di una classe astratta come base comune per queste classi.

L’utente per ASP.NET: Principal e Identity

ASP.NET utilizza due classi per rappresentare le informazioni relative all’utente, che sono implementate in maniera tale da essere indipendenti dal tipo di autenticazione.

Il Principal contiene le informazioni di protezione relative all'utente, sotto forma di un oggetto che implementa l'interfaccia IIdendity , e dei ruoli a cui lo stesso appartiene. È inoltre rappresentato da una serie di oggetti che implementano l'interfaccia IPrincipal.

Principal ed Identity sono legati tra di loro e variano a seconda del tipo di autenticazione utilizzato: nel caso dell'autenticazione Windows gli oggetti utilizzati saranno rispettivamente WindowsPrincipal e WindowsIdentity, mentre con Forms Authentication abbiamo GenericPrincipal e GenericIdentity

All'interno dell'identità dell'utente è dunque contenuta l'appartenenza ai ruoli, secondo le modalità specifiche del tipo di autenticazione.

L'accesso a queste informazioni è regolato attraverso la proprietà User, che viene restituita sia attraverso la classe HttpContext, che direttamente come proprietà della classe Page.

Sono gli HttpModule forniti con i differenti tipi di autenticazione che nell'evento AuthenticateRequest impostano questa proprietà, tecnica ben nota a chi ha sfruttato la Forms Authentication con ruoli con ASP.NET 1.1.

Attraverso il metodo IsInRole si può verificare l’appartenenza a un certo ruolo, mentre IIdentity ha la proprietà Name, con si può risalire al nome utente, e quella IsAuthenticated, che stabilisce se l’utente è stato autenticato.

Questo è il codice necessario a verificare queste informazioni, quando ce ne fosse bisogno, in maniera programmatica.

VB

Dim username as String = User.Identity.Name

Dim isAuthenticated as Boolean = User.Identity.IsAuthenticated

Dim isInRole as Boolean = User.IsInRole(“ruolo”)

C#

string username = User.Identity.Name;

bool isAuthenticated = User.Identity.IsAuthenticated;

bool isInRole = User.IsInRole(“ruolo”);

Gestione degli utenti con Membership API

Membership API rappresenta il primo modo per mettere in pratica, al tempo stesso, i concetti propri del Provider Model e quelli dell’autorizzazione integrata in ASP.NET, attraverso gli HttpModule.

Si tratta di una serie di funzionalità che forniscono l’infrastruttura comune a tutti i provider, in grado di garantire un’uniformità di creazione della parte di gestione degli utenti, offrendo funzionalità come la creazione o rimozione di un utente, il cambio password, etc.

Grazie all’uso del Provider Model, Membership API è composto da due componenti fondamentali:

• le API, richiamate direttamente dallo sviluppatore ed implementate attraverso la classe statica Membership;

• i provider, che forniscono le funzionalità specifiche in base allo storage e che derivano dalla classe base astratta MembershipProvider.

In un modello del genere, i metodi della classe Membership richiamano il corrispondente metodo definito all'interno del provider, usando un'istanza dello stesso, creata a partire dalle impostazioni specificate nel web.config.

I due provider inclusi in ASP.NET 2.0 si trovano nel namespace System.Web.Security e sono:

• SqlMembershipProvider, per SQL Server 7, 2000 e 2005;

• ActiveDirectoryMembershipProvider, che fornisce il supporto per Active Directory.

Ognuno ha i propri pregi e difetti, ma tutto sommato, grazie all’uso del Provider Model, hanno la stessa tipologia di funzionamento.

Il Membership Provider per SQL Server

Il provider di default lavora con un’istanza locale di SQL Server 2005 Express, utilizzando una User Istance, e pertanto difficilmente viene utilizzato in produzione, per via dei limiti che questa scelta comporta. D’altra parte analizzare come funziona un singolo provider, per via del funzionamento che hanno in comune, coincide inevitabilmente con comprendere come funzionano tutti.

Quello che contraddistingue ogni provider è la presenza di un tool differente per la relativa installazione, che spesso consiste nel creare una struttura ad hoc all’interno di un database.

Il Membership Provider per SQL Server è distribuito insieme al tool da riga di comando aspnet_regsql.exe, che si trova nella directory di .NET Framework 2.0, posta sotto il percorso %WinDir%\Microsoft.NET\Framework\v2.0.50727\.

Ha anche un’interfaccia grafica, per cui attraverso un wizard si occupa di creare nel database specificato tutte le tabelle e le stored procedure per Membership, Roles e Profile API.

La scelta di come installare un provider è chiaramente legata al produttore dello stesso, dunque non è detto che provider aggiuntivi, ad esempio per altri database, forniscano la stessa facilità di configurazione.

Il passo successivo è quello di specificare, nel web.config, le impostazioni del provider. Ognuno è distribuito con una tipologia specifica di sezione di configurazione, che in genere si trova insieme alla documentazione. Nel caso di SQL Server, la parte di configurazione è la seguente:

<configuration>
  <connectionStrings>
    <add connectionString="Data Source=localhost; Initial Catalog=users; Integrated Security=SSPI;" name="localhost"/>
  </connectionStrings>
  <system.web>
    <membership defaultProvider="SqlServer">
     <providers>
      <add
         connectionStringName="localhost"
         enablePasswordRetrieval="false"
         enablePasswordReset="true"
         requiresQuestionAndAnswer="true"
         applicationName="/"
         requiresUniqueEmail="false"
         passwordFormat="Hashed"
         maxInvalidPasswordAttempts="5"
         minRequiredPasswordLength="7"
         minRequiredNonalphanumericCharacters="1"
         passwordAttemptWindow="10"
         passwordStrengthRegularExpression=""
         name="SqlServer"
         type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
     </providers>
    </membership>
  </system.web>
</configuration>

Gli attributi connectionStringName, name e type servono rispettivamente a specificare il nome della stringa di connessione contenuta nell'apposita sezione connectionStrings, il nome del provider ed il riferimento alla classe da utilizzare ed è spesso quest’ultima a variare quando si cambia un provider.

L'attributo applicationName è importante perché il provider per SQL Server è in grado di supportare più applicazioni contemporaneamente, anche se questa modalità con buona probabilità non è indicata per tutti i progetti. È importante però che venga impostata, perché serve per filtrare le informazioni a cui l’applicazione avrà accesso.

Gli altri attributi regolano al meglio il funzionamento del provider e comunque già nel nome contengono indicazioni sul loro utilizzo, che peraltro può essere recuperato facilmente anche nella documentazione.

Il motivo per cui questo provider è da preferire rispetto ad altre soluzioni, se si parte da zero e non si deve adattare l’applicazione a una struttura esistente, ovviamente utilizzando SQL Server, è che utilizza stored procedure transazionali, garantendo un alto grado di performance e una forte consistenza dei dati, uniti alla sicurezza derivante dal salvataggio della password in formato hashed, a garanzia che non possono essere recuperate a seguito di una qualche falla che dovesse dare accesso diretto al contenuto del database.

Il Membership Provider per Active Directory

Sfruttando la classe ActiveDirectoryMembershipProvider, grazie all’uso del Provider Model, si può utilizzare Membership API anche in unione con Active Directory, senza cambiare approccio né il codice utilizzato, visto che, lo sottolineiamo ancora una volta, le applicazioni faranno sempre riferimento alle API, quando si scrive codice, e mai al provider specifico.

In questo caso la definizione del web.config è la seguente:

<configuration>

  <connectionStrings>
    <add 
      connectionString="LDAP://bochicchio.local/CN=Users,DC=bochicchio,DC=local"
      name="ActiveDirectory"/>
  </connectionStrings>

  <membership defaultProvider="ActiveDirectory">
    <providers>
      <add name="ActiveDirectory"
        type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
        attributeMapUsername="SAMAccountName"
        connectionStringName="ActiveDirectory"
        connectionUsername="bochicchio.local\SAUser"
        connectionPassword="password" />
    </providers>
  </membership>
</configuration>

La stringa di connessione definita nel web.config è questa volta differente, poiché punta al percorso del dominio in Active Directory, laddove il valore dell’attributo attributeMapUsername specifica come forma dell'autenticazione la classica dominio\nome, anziché quella di default, che è nome@dominio.

Gli attributi connectionUsername e connectionPassword, invece, specificano un utente che abbia i giusti permessi per effettuare le query in Active Directory, necessarie a compiere le operazioni specifiche per il provider in uso. Non ha grandi limiti, è in grado di aggiungere, rimuovere o variare i dati di un utente direttamente nel dominio, dunque ben si presta a essere utilizzato all’interno di una intranet.

Roles API: gestione dei ruoli

L’aggiunta dei ruoli alla Forms Authentication è probabilmente una delle operazioni più complesse, almeno la prima volta, e decisamente noiose da effettuare, le volte successive, nelle applicazioni basate su ASP.NET 1.1.

Con lo stesso spirito di Membership API, cioè quello di favorire la semplicità di implementazione di funzionalità ripetitive, Roles API fornisce l’infrastruttura necessaria ad aggiungere anche il supporto per i ruoli applicativi all’utente.

Quello che Roles API fa, attraverso l'HttpModule RoleManagerModule, è aggiungere al Principal i ruoli a cui appartiene l’utente, sostituendolo in automatico grazie ai metodi previsti dal provider, operazione che quindi viene tolta dalle incombenze dello sviluppatore.

Come nel caso di Membership API, anche Roles API è basato su provider, classi derivate dalla classe astratta RoleProvider:

• SqlRoleProvider, per SQL Server 7, 2000 e 2005;

• WindowsTokenRoleProvider, per l'autenticazione di Windows, sfruttando i ruoli assegnati all’utente.

La configurazione va sempre effettuata dal web.config, perché il funzionamento di queste API è di fatto identico:

<configuration>
  <system.web>
    <roleManager enabled="true" defaultProvider="SqlServer">
       <providers>
          <add
             connectionStringName="SqlServer"
             applicationName="/"
             name="SqlServer"
             type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
       </providers>
    </roleManager>

È importante ricordarsi di impostare l’attributo enabled su “true”, così da abilitarne il supporto, per il resto il significato degli attributi è del tutto simile a quelli previsti per la configurazione di Membership API. Non è necessario fare nient’altro, poiché del resto se ne occupa in automatico l’HttpModule specifico.

Per provare se tutto funziona, si possono creare nuovi ruoli sfruttando il metodo statico CreateRole della classe Roles, per poi usare il metodo AddUserToRole per aggiungere un utente esistente ad un ruolo. Tutte queste operazioni dovranno essere effettuate sfruttando un pannello di controllo, così da rendere possibile la definizione dei ruoli in maniera più semplice.

I ruoli a questo punto possono essere controllati, come si è visto nel paragrafo dedicato a Principal e Identity, anche in maniera programmatica, attraverso il metodo IsInRole della classe Principal utilizzata.

Il Roles Provider per SQL Server

Il setup di questo provider coincide con quello di Membership API, che come già detto include il supporto anche per Roles API e Profile API.

Dunque dal punto di vista della configurazione, l’unica difficoltà, se così possiamo definirla, è nella impostazione della stringa di connessione, che sarà utilizzata poi in automatico per recuperare i ruoli ed associarli al Principal corrente, piuttosto che per effettuare le operazioni associate ai vari metodi della classe Roles.

I nuovi server control di login

Per rendere più semplice l'implementazione di queste nuove funzionalità, la versione 2.0 di ASP.NET introduce alcuni nuovi server control di tipo security, che automatizzano al 100% questo genere di operazioni, grazie all'utilizzo di un approccio totalmente dichiarativo.

L’idea è che grazie al fatto che le API sono fisse e non cambiano mai (a farlo è solo il provider), si possono creare dei server control in grado di richiamare queste API, senza necessità di essere cambiati nel tempo.

Le aree in cui questi controlli impattano sono quelle legate alle operazioni più diffuse:

• ChangePassword: consente il cambio password;

• CreateUserWizard: fornisce un wizard per l’iscrizione di un utente;

• Login: fornisce l’infrastruttura necessaria al login;

• LoginName: mostra il nome utente;

• LoginStatus: mostra lo stato dell’utente (autenticato o meno);

• LoginView: supporta la visualizzazione di template in base allo stato dell’utente;

• PasswordRecovery: consente di recuperare la password esistente o di crearne una nuova, quando si utilizza un formato hashed.

Questi controlli coprono quasi il 100% delle necessità presenti in questi scenari, adattandosi in automatico al provider in uso.

CreateUserWizard

CreateUserWizard è il controllo specifico per l'inserimento di un wizard nella pagina per la registrazione di un nuovo utente. Raccoglie le informazioni minime necessarie alla creazione (username, e-mail e password) e procede a invocare il metodo CreateUser della classe Membership, che a sua volta richiamerà lo stesso metodo offerto dal provider. Questo controllo è molto potente e si inserisce nella sua forma base con poche righe di codice:

<form runat="server">
<asp:CreateUserWizard id="wizard1" runat="server" />
</form>

L'effetto con questo controllo è quello di avere già tutto pronto, senza fare niente e senza dover modificare nient'altro che il provider. Nel caso fosse necessario personalizzare la maschera di iscrizione, questo controllo è un derivato di quello Wizard, dunque può avere sia Step aggiuntivi che una personalizzazione del template. Queste informazioni aggiuntive possono poi essere recuperate intercettando l'evento CreateUser, che si verifica quando l'utente è stato correttamente creato attraverso il provider specificato. Il controllo può essere recuperato attraverso un codice del genere:

VB

Dim option as String = DirectCast( wizard1.CreateUserStep.ContentTemplateContainer.FindControl("Options"), DropdownList).SelectedValue;

C#

string option = ((DropDownList) wizard1.CreateUserStep.ContentTemplateContainer.FindControl("Options")).SelectedValue;

In questo esempio viene preso il valore selezionato in una DropDownList il cui ID è "Options", ma si può adattare facilmente a qualsiasi tipologia di controllo, senza particolari limiti o restrizioni.

Login

Il controllo Login, inserisce una maschera per fare il login, che in questo caso richiama il metodo ValidateUser della classe Membership. Anche in questo caso specifico l'inserimento consiste in poche righe di codice:

<asp:Login ID="Login1" runat="server" />

Attraverso le proprietà che espone, è possibile personalizzarne completamente l'aspetto grafico, così come il testo associato ai vari controlli, per averli anche localizzati in italiano. In questo caso i due eventi di riferimento da intercettare sono LoggedIn e LoginError, che servono a eseguire codice nei rispettivi stati.

LoginStatus e LoginName

I controlli LoginStatus e LoginName servono rispettivamente a mostrare lo stato del login, associando un link alla pagina di login o logout a seconda dello stesso, e il nome utente. Forniscono il supporto per funzionalità semplici, ma sono comunque utili come contorno alle applicazioni.

Bentornato <asp:LoginName ID="LoginName1" runat="server" />!

<br /><br />

<asp:LoginStatus ID="LoginStatus1" runat="server" />

ChangePassword e PasswordRecovery

ChangePassword e PasswordRecovery servono rispettivamente per cambiare la password o recuperare la stessa. Il primo va ovviamente messo su pagina riservati agli utenti autenticati, laddove il secondo deve essere aperto a tutti.

<asp:PasswordRecovery ID="PasswordRecovery1" runat="server" />

<asp:ChangePassword ID="ChangePassword" runat="server" />

LoginView

Dove le Roles API danno il meglio è quando cominciamo ad utilizzare il controllo LoginView. Si tratta di un controllo che consente di definire tre tipi di template: utente autenticato, anonimo o appartenente a un ruolo. Il tutto viene fatto in maniera molto semplice, come si può vedere da questo esempio:

<asp:LoginView ID="LoginView1" runat="server">

<RoleGroups>

<asp:RoleGroup Roles="administrator">

<ContentTemplate>Appartenente al ruolo administrator.</ContentTemplate>

</asp:RoleGroup>

</RoleGroups>

<LoggedInTemplate>Autenticato.</LoggedInTemplate>

<AnonymousTemplate>Anonimo.</AnonymousTemplate>

</asp:LoginView>

In base allo stato dell'utente verrà mostrato il template corrispondente.

La cosa interessante di questo controllo è che si possono annidare tra di loro, per supportare quel particolare scenario in cui sia necessario avere un template specifico per gruppi di ruoli.

Provider aggiuntivi e custom

In tutti quei casi in cui SQL Server non sia il database scelto, è possibile cambiare il provider in modo tale che rifletta quello di proprio interesse.

Nel caso di Membership, non ha senso cambiare il provider per aggiungere informazioni aggiuntive come nome, cognome o date di nascita, perché queste non sono informazioni legate all’utente, ma al suo profilo.

In giro si trovano diversi aggiuntivi provider, al momento questi sono quelli disponibili:

• Access

• MySQL

• SQLite 3.0

• Oracle

Qualora si abbia la necessità di creare provider personalizzati, la strada più semplice è quella di prendere uno dei provider inclusi in ASP.NET 2.0 e crearsi quello personalizzato, sfruttando l'apposito toolkit disponibile su questa pagina. Questo è il caso da privilegiare quando si ha già una struttura dati pronta e bisogna adattarsi a quest’ultima e non viceversa.

Creare un provider è abbastanza semplice e non è detto che il provider implementi tutti i metodi che la classe base astratta obbliga a scrivere. Ad esempio il Membership Provider per Active Directory, giustamente, genera un’eccezione quando viene richiamato il metodo GetPassword della classe Membership, perché questa operazione non è possibile stando allo storage utilizzato.

Il codice ed i controlli utilizzati, grazie all’uso del Provider Model, non dovranno essere modificati, perché di fatto si fa sempre riferimento alle API.

Conclusioni

Membership e Roles API aggiungono alle applicazioni ASP.NET 2.0 il supporto per aree personalizzate in un modo che più semplice è probabilmente impossibile, anche grazie all’aggiunta dei nuovi controlli di login inclusi in questa nuova versione.

D’altra parte l’uso del Provider Model favorisce anche un’ottima flessibilità, così da poter creare un’applicazione in grado di adattarsi con estrema facilità al cambio di storage.

Inoltre, è perfettamente lecito e anzi possibile avere provider differenti per le differenti API, così da usare, ad esempio, un provider già incluso e uno custom, qualora si abbia necessità di variarne il comportamento.

In estrema analisi, il Provider Model ha avuto un forte impatto su ASP.NET 2.0, tanto che sono tante e differenti le funzionalità che è possibile modificare a proprio piacimento in quest’ultima versione di ASP.NET.