Prima di iniziare ad analizzare la parte riguardante le Permissions, vorrei un attimo visualizzare il tag Pages, che normalmente viene implementato a runtime nel codice della pagina. É chiaro che se devo modificare la modalità di Trace per tutta la mia applicazione andró a farlo nel web.config e non in ogni singola pagina, altrimenti la mia applicazione diventa tutto tranne che riutilizzabile.

<pages
autoEventWireUp="true|false"	'connette da solo il gestore eventi
buffer="true|false"				'il vecchio response buffer
enableSessionState="true|false|readOnly"
enableViewState="true|false"	'stato dei controlli
pageBaseType="typename,assenbly"	'classe da cui si eredita
smartNavigation="true|false"		'
userControlBaseType="typename"		'classe per userControl

Questo elemento è il più interessante. Una volta per poter gestire gli errori customizzabili bisognava poter accedere alla gestione di IIS e configurare le pagine in base all' errore etc etc ... ... Adesso tramite il web.config possiamo decidere a priori, anche in base alla tipologia di errore, cosa fare, che redirect usare e cosi' via. Volendo sarebbe anche possibile implementare una classe che gestisca ogni singolo errore in un' unica pagina, ma non è certo lo scopo dell' articolo.

<customErrors
defaultRedirect=""		'pagina di errore
mode="on|off|RemoteOnly"
		<error
	redirect=""			'pagina errore custom
	statusCode=""		'dice errore esempio : 404

E si, per chi, come me, viene dal buon vecchio Asp farà le capriole con questa nuova gestione customizzata degli errori.

Ok se fino adesso l' argomento è stato pesante, beh allora chiudete qui la cosa e cambiate articolo perchè adesso arriva la parte più tosta. Io seguo l' ordine MSDN e quindi adesso tocca al tag authentication. Da qui possiamo gestire tutta la logica dell' autenticazione, anche se crearne una custom non è cattiva idea ... Prima cosa decidiamo quale usare : 

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

Se decidiamo la prima strada Windows abbiamo finito, chiaramente useremo gli utenti del Network (A.D.) e imposteremo i permessi ai gruppi ... Ma se scegliessimo di usare il metodo Passport?

<passport redirectUrl="" />

Ultimo, se invece decidiamo di usare un login custom, dato da delle credenziali che magari impostiamo noi nel database o in un file xml ...

<forms
loginUrl="url"		'dove risiede la form
name="name"			'nome dcookie di auth.
path="/"			'percorso per il cookie
protection="All|Encription|Validation|None"	'protezione dei cookie
timeout="minuti"	'default 30" durata del login

Parte importante di questo tag sono altri due, il tag credentials e il tag user. Tramite questi tag possiamo impostare le credenziali degli utenti via xml. Microsoft fa notare peró che se il sistema dovessere essere compromesso da attacchi esterni le credenziali sarebbero facilmente raggiungibili. Quindi tecnica sconsigliata!! Strano peró che la cosa venga sponsorizzata anche nei test ...

<credentials passwordFormat="Clear|MD5|SHA1"
		<user name="Pippo" password="*****"

Ok, se la cosa fosse finita qui, vi verrebbe da pensare come diavolo fare a impersonificare e come poter gestire autorizzazioni varie, anche a livello di gruppo. Beh per fare ció abbiamo altri due bellissimi tag che ci aiutano a smaltire il lavoro. Vediamo adesso identity che ci aiuta proprio nella rappresentazione di un utente con particolari permessi
Nota : vi ricordo che per default NET usa o IUSR_MACHINENAME o IWAM_MACHINENAME in base al tipo di processo, in o out-of. 

<identity
	impersonate="true|false"		'se usarla o no
	userName="user"				'qualsiasi account utente
	password="pwd"				'la sua password

Non smetteró mai di ripetere, prudenza prudenza prudenza ...

Bene, abbiamo visto come gestire gli accessi, come impersonare un utente presente nella macchina, magari per effettuare operazioni particolari sul FileSystem, ma cosa manca? Mancano i permessi che sono rappresentati dal tag authorization.

<authorization>
	<allow
		users="userslist"
		roles="rolesList"
		verbs="verbsList"



	<deny ...

Allora con i tag allow e/o deny impostiamo le autorizzazioni di accesso o negazione.
Users consente questi valori (elenco utenti seguiti da virgola, * per tutti, ? per sconosciuti)
Roles consente questi valori (elenco utenti seguiti da virgola, * per tutti, ? per sconosciuti)
Verbs sono i seguenti (GET, POST, DEBUG e HEAD).

Nota : Io ho costruito una classe che tramite un datatable crea una stringa dei gruppi onguno seguito da una virgola, cosi' ho ottenuto una gestione personalizzata (Form) ma con la possibilità di lavorare con i gruppi (finti). Adesso riesco ad accedere a isMemberOf e a ltri metodi utili dell' oggetto permissions.