PARTE 5 – CAPITOLO 16 – AUTHORIZATION E ROLES
Dopo aver autenticato l’utente, è necessario analizzare i permessi che gli sono stati assegnati per determinare quali sono le azioni che può compiere. La più semplice strategia di autorizzazione è la URL Authorization: permette o nega l’accesso ad una risorsa utilizzando solo l’utente e l’URL relativa. Quando si applicano restrizioni particolari (ad esempio ad una cartella riservata solo ad un utente) bisogna specificare prima gli “allow” e poi i “deny” perché ASP.NET analizza tutte le proprietà di autorizzazione valide dal Top al Bottom e si ferma alla prima valida per il contesto corrente, ignorando quelle successive. Nel caso di root-subdirectory, le indicazioni per la subdirectory hanno priorità maggiore rispetto a quelle della root (un utente può essere autorizzato a vedere solo la root ma non una subdirectory). La scelta migliore è negare gli accessi agli anonimi (?), consentire l’allow a un gruppo ristretto e dichiarare un deny per tutti gli utenti subito dopo. Un’altra strategia di autorizzazione, utilizzata solo con la Windows Authentication, è la File Authorization (che controlla i permessi ACL sul file impostati grazie alle funzionalità del formato NTFS). Con le Authorization Checks in Code è possibile controllare le autorizzazioni prima di cercare di eseguire task particolari. Un primo esempio è il metodo User.IsInRole(“Ruolo”). Un’altra possibilità è la PrincipalPermission Class (si imposta – una volta sola – una regola e poi con un blocco try-catch si testa l’aderenza alla regola e si gestiscono le eccezioni). Due regole create con PrincipalPermission possono essere combinate in OR usando “(PrincipalPermission)pp1.Union(pp2)”. Le impostazioni di sicurezza fin qui introdotte funzionano solo con i tipi di file che possono essere gestiti direttamente da ASP.NET. L’accesso ad altri tipi di file (ad esempio una immagine GIF) bypassa completamente le impostazioni di sicurezza definite. Per ovviare al problema è necessario aggiungere un nuovo File Type Mapping a IIS. Dopo aver mappato l’estensione è necessario creare un custom HTTP handler (descrive come trattare il file) e aggiungere un riferimento nella sezionedel blocco. Il tipo di accesso all’interno di una applicazione web deve rimanere lo stesso. Quando l’applicazione è su più subdirectory, prima viene letta la parte di authorization del web config più indentato e poi si va a risalire. Appena viene trovata una regola che si applica la ricerca viene interrotta. Si può anche usare il tag location (fuori da system.web ma subito dentro configuration) per impostare i permessi di uno specifico file. Per gestire al meglio le Permission, gli Users sono spesso raggruppati in Roles. Con la Windows Authentication i Roles sono i gruppi di Windows (quelli di default o quelli aggiunti manualmente). La File Authorization, funzionante solo con Windows Authentication e basata su ACL, controlla se l’utente ha il permesso di leggere/eseguire una particolare risorsa. Tutti gli oggetti che ereditano da IPrincipal possono usare la IsInRole per controllare se un utente fa parte di un gruppo (o di un Windows Group – Nome macchina per i custom e BUILTIN per i default). Con PrincipalPermission e il metodo Demand() posso controllare se l’utente fa parte di un determinato gruppo e gestire gli scenari con un blocco try/catch (il metodo infatti solleva una eccezione se le credenziali non sono sufficienti). I roles possono essere dichiarati anche programmaticamente.
