Con la creazione del .NET Framework Microsoft ha introdotto una nuova struttura formata da classi e attributi, volti ad aumentare la sicurezza delle applicazioni.
Tutto questo prende il nome di CAS (Code Access Security) e si basa sulla raccolta di informazioni quali le zones (intranet, internet), l'evidence (nome assembly, versione, firma, url di provenienza ecc) e i permessi associati alla macchina, gruppo o utente. In funzione di questi dati possiamo discriminare molto di più rispetto al passato l'esecuzione di codice in funzione della tipologia di operazione. Il framework ne prevede molti tipi come accesso ai files, uso dell'UI, della rete, dei dns, dell'event log, della stampa, reflection, registro ecc, ma ne permette anche di crearne custom.

La verifica dei permessi può essere richiesta in modo dichiarativo (mediante l'uso di attributi) o programmatico (chiamando dei metodi appositi). In entrambi i casi utilizzando il permission adatto, è possibile verificare se chi esegue una certa operazione ha il permesso di farlo, vietare un certo accesso, asserire che l'utente lo detiene, unirlo o intersecarlo con un altro.
Il .NET Framework fa già uso di queste classi, ma non ce ne accorgiamo perché i permessi nelle applicazioni ASP.NET sono "Full" e quindi non abbiamo limitazioni.

Ormai applicazioni di media o grossa dimensione sono progettate a strati, divisi tra di loro.
Lo scopo di questo script è sfruttare la CAS per garantire che chi accede allo strato biz abbia i permessi per farlo. Questo serve per aggiungere una ulteriore protezione ad eventuali bug nel sistema di autorizzazione delle pagine o più in generale dello strato di presentazione.

Per tale scopo useremo il PrincipalPermission che ci permette di verificare se un utente è autenticato e che appartenga a certi ruoli. Supponiamo di avere una classe che gestisce i prodotti e vogliamo dare la possibilità di prelevare la lista di prodotti a chiunque, ma di cancellare, aggiornare o aggiungerne solo a chi detiene privilegi di admin.

Ecco come useremo le classi per la security contenute nel namespace System.Security:

public class BizLayerSample
{

  private static StringCollection _products;

  public string[] ListProducts()
  {
    string[] list = new string[_products.Count];
    _products.CopyTo(list, 0);
    return list;
  }


  [PrincipalPermission(SecurityAction.Demand, Role = "Admin")]
  public void DeleteProduct(int index)
  {
    // Cancellazione prodotto
    _products.RemoveAt(index);
  }
}

Nell'esempio usiamo il metodo dichiarativo per chiedere che chi richiama DeleteProduct appartiene al ruolo di Admin. Il motore conosce il ruolo dell'utente perché restituito dall' IPrincipal, oggetto restituito dalla proprietà User delle pagine web. Richiamando infatti il metodo IsInRole validerà la richiesta.

Per approfondire l'argomento potete leggere questo articolo che mostra un esempio di autenticazione a ruoli:
#614 - Forms Authentication con roles e ticket
https://www.aspitalia.com/liste/usag/script.aspx?ID=614

Se volessimo per esempio permettere di prelevare un prodotto e discriminare gli utenti non amministratori per i prodotti con indice inferiore a tre, ci basterà:

public string GetSingleProduct(int index)
{
  if (index > 2)
  {
    // Richiedo i permessi di admin
    PrincipalPermission permission = new PrincipalPermission(HttpContext.Current.User.Identity.Name, 
      "Admin",
      true);
    permission.Demand();
  }
  return _products[index];
}

Da codice chiederemo la verifica dei permessi solo se index > 2. Il metodo Demand non fa altro che generare una SecurityException in caso di mancanza di permesso e di conseguenza interrompere l'esecuzione del metodo. Lo strato di presentazione quindi dovrà prevedere questa possibilità di eccezione e comportarsi di conseguenza:

try
{
  BizLayerSample layer = new BizLayerSample();
  layer.DeleteProduct(e.Item.ItemIndex);
}
catch (System.Security.SecurityException)
{
  Response.Write("Non si dispone dei permessi per eseguire questa operazione");
}

Questo approccio è molto comodo, standard e rende il codice molto elegante. Inoltre il CAS permette di verificare questi permessi anche a livello di assembly e i permission sets sono configurabili a livello di web.config o machine.config.