Nell'articolo ASP.NET Windows Authentication abbiamo visto una panoramica sui metodi di autenticazione in .NET e poi siamo scesi un po' più in dettaglio sull'autenticazione Windows di ASP.NET.
Rimandiamo a tale articolo (sezione iniziale) per l'introduzione ai concetti di autenticazione e autorizzazione Windows.

In questo articolo, in cui dapprima riproponiamo alcuni dei concetti dell'articolo precedente, vedremo in dettaglio il meccanismo di autenticazione via form (Forms Authentication) di ASP.NET.

.NET Security Basics
Ogni thread del CLR gira con un suo Security Principal .NET su cui il codice può effettuare controlli d’accesso.
Un Security Principal .NET è composto da un utente (Identity) e una serie di gruppi associati all'utente stesso (Ruoli).

Esistono due tipi di Identity:
1) WindowsIdentity: l’utente corrisponde all’utente Windows
2) GenericIdentity: l’utente viene definito dall’applicazione

Un esempio di WindowsIdentity in C#:

using System;
using System.Security.Principal;

public class demo
{
 public static void Main()
 {
  Console.WriteLine(WindowsIdentity.GetCurrent().Name);
 }
} .....

Un esempio di costruzione di una GenericIdentity in una pagina ASP.NET
using System;
using System.Security.Principal;

public class demo
{
 public static void Main()
 {
  GenericIdentity MyIdentity = new GenericIdentity("Roberto");
  Console.WriteLine(MyIdentity.Name);
 }
}

Nel primo esempio di codice, l’applicazione recupera la Windows Identity con il metodo GetCurrent, nel secondo esempio, invece, viene costruita da codice una Generic Identity.

Abbiamo più volte detto nell'articolo ASP.NET Windows Security, che un’Identity forma, insieme ai ruoli, un Security Principal, quindi di conseguenza avremo un
1) Windows Principal quando l’applicazione utilizza utente e gruppi del sistema operativo Windows
2) Generic Principal quando utenti e gruppi vengono ridefiniti nell’applicazione

Nell’esempio seguente costruiamo un Windows Principal .NET locale (MyWP) partendo dalla Windows Identity fornita dal Sistema Operativo, per poi visualizare l’utente e controllarne l’appartenenza al gruppo “DevLeap\Administrator”:

using System;
using System.Security.Principal;

public class demo
{
 public static void Main()
 {
  WindowsPrincipal MyWP = new WindowsPrincipal(WindowsIdentity.GetCurrent());
  Console.WriteLine(MyWP.Identity.Name);
  Console.WriteLine(MyWP.IsInRole("DevLeap\Administrators"));
 }
}

Utilizzando un Generic Principal invece dovremmo costruire utente e ruoli da codice, come si vede dall’esempio seguente:

using System;
using System.Threading;
using System.Security.Principal;

public class demo
{
 public static void Main()
 {
  GenericIdentity MyIdentity = new GenericIdentity("Roberto");
  String[] MyRoles = {"Publisher", "User", "Writer"};
  GenericPrincipal MyGP = new GenericPrincipal(MyIdentity, MyRoles);
  Thread.CurrentPrincipal = MyGP;
  Console.WriteLine(MyGP.Identity.Name);
  Console.WriteLine(MyGP.Identity.IsAuthenticated);
  Console.WriteLine(MyGP.IsInRole("Writer"));
 }
}

 

ASP.NET Forms Authentication

Autenticazione Windows, Windows Identity e compagni sono sicuramente validi in scenari Intranet, o comunque in scenari in cui gli account degli utenti vengano "custoditi" in Active Directory (Windows 2000) o nel SAM (NT4).
Sicuramente applicare questo meccanismo a scenari Internet, in cui spesso il numero numero degli utenti non è predeterminabile in fase di progettazione, comporta task amministrativi enormi per la gestione degli account/password.
Inoltre, l'autenticazione Windows pura (NTLM per intenderci) normalmente non passa da firewall e Proxy server in quanto si basa sul protocollo Challenge/Response.
In ogni caso far passare account windows del dominio sul web rende sicuramente più attaccabile il nostro sistema.

ASP.NET fornisce ancora una volta un'infrastruttura che evita, nella maggioranza dei casi, di dover sviluppare un meccanismo di autenticazione proprietario.
Le idee di fondo sono queste:
1) Utilizzare i cookie (come normalmente avviene su tutti i siti web pubblici che necessitano di autenticazione)
2) Automatizzare la redirezione dalla pagina richiesta dall'utente alla pagina di login in assenza di credenziali e la successiva redirezione a fronte di un login valido.
3) Fornire una forma di ammistrazione (per adesso manuale) per gestire gli utenti

Nella forma più semplice di Forms Authentication, gli step da eseguire sono molto semplici
1) Configurare il tipo di autenticazione nel web.config
2) Indicare il path della pagina di login nel web.config
3) Indicare le pagine da proteggere nel web.config
4) Configurare utenti e relative password nel file web.config
5) Costruire la pagina di login utilizzando le classi fornite per validare l'autenticazione

Analizziamo ogni singolo step, per poi rimandarvi a due articoli separati in cui vedremo rispettivamente autenticazioni su Database e la costruzione di ruoli custom per proteggere in modo più intelligente le pagine dell'applicazione.

Step 1: Configurare il tipo di autenticazione del web.config

Nella sezione <configuration>, sottosezione <system.web> inserire i seguenti tag XML

<authentication mode="Forms">
</authentication>

Quest'impostazione indica al motore ASP.NET il metodo di autenticazione Forms Authentication

Step 2: Indicare il path della pagina di login nel web.config

Inserire nella sezione <authentication> appena creata l'indicazione del path della pagina di login

<forms loginUrl="Login.aspx" name="DevLeap" />

loginUrl specifica il path della pagina di login che creeremo nello Step 5
name="DevLeap" indica il nome del cookie che verrà utilizzato per memorizzare l'account dell'utente
Nel nostro esempio abbiamo usato "DevLeap" per ovvi motivi.
L'indicazione name è opzionale: il default è ".ASPXAUTH"
N.B. Nella beta precedenti l'attributo loginUrl era redirectUrl

Nella seconda parte dell'articolo vedremo gli altri 3 step e proseguiremo con con qualche indicazione utile sulla protezione degli account