Progettazione e realizzazione di un’applicazione J2EE Parte 2

Sicurezza proteggere l’accesso alle applicazioni J2EE sicurezza dichiarativa –chi sviluppa e assembla un’applicazione J2EE la accompagna con contratti dichiarativi riguardanti la sicurezza, che dovranno essere rispettati da chi installerà e configurerà tale applicazione –questi contratti *devono poter essere rispettati da chi configurerà l’applicazione *sono espressi in modo dichiarativo nel deployment descriptor sicurezza programmata –decisioni fatte (nel codice di) da applicazioni conscie degli aspetti di sicurezza –quando quella dichiarativa non è abbastanza flessibile –per esempio autorizzazione all’accesso dipendende da *tempo (ora e/o giorno) *parametri di una chiamata *stato interno di unenterprise bean *info contenute in un data base *...

Security role Quando si progetta un enterprise bean o una componente Web occorre pensare ai tipi di utenti che accederanno a tale componente –es., un enterprise bean ContoCorrente può esssere acceduto da clienti, impiegati allo sportello, e direttori di filiale queste categorie di utenti sono dette security role –un raggrupamento logico astratto di utenti, definito da chi assembla l’applicazione –quando un’applicazione è installata, l’installatore mapperà i security role ad identità relative alla sicurezza nell’ambiente operativo dell’applicazione, come principals (identità assegnati ad utenti come il risultato di una autenticazione) o groups

EJB-Tier Security Disponibili meccanismi di sicurezza (dichiarativi e programmativi) che possono essere usati per proteggere le risorse nel tier EJB –tali risorse includono i metodi degli enterprise beans chiamati dalle application clients, Web components, o altri enterprise beans Dichiarare i permessi dei metodi –dopo aver definito i ruoli, è possibile definire i permessi dei metodi, indicando i ruoli che li possono chiamare Usare la sicurezza programmativa –Esiste un metodo getCallerPrincipal che ritorna il principal che ha chiamato il metodo, e uno isCallerInRole che controlla se un principal ammette un certo ruolo –Usandoli è possibile controllare gli accessi

Application Client-Tier Security Un application client può usare il Java Authentication and Authorization Service (JAAS) per l’autenticazione dei clienti JAAS implementa una versione Java del Pluggable Authentication Module (PAM), che permette alle applicazioni di rimanere indipendente dalle sottostanti tecnologie di autenticazione

Propagare le identità di sicurezza Quando si installa un enterprise bean, è possibile specificare le identità di sicurezza che saranno propagate agli enterprise beans chiamati da tale componente

J2EE utenti, reami, e gruppi (1) Un utente J2EE è simile ad un utente di un sistema operativo, es. Tipicamente rappresentano persone, ma non coincidono –il servizio di autenticazione di J2EE non ha conoscenza del nome e della password utilizzati per collegarsi al sistema operativo –il sistema di sicurezza di J2EE non è connesso al meccanismo del sistema operativo Un reame è una collezione di utenti che sono controllati dalla stessa authentication policy Il sistema di autenticazione di J2EE governa utenti in due reami: certificate [basato su certificati, usato dai Web browsers] e default

J2EE utenti, reami, e gruppi (2) Un utente J2EE del default realm può appartenere ad un gruppo J2EE Un gruppo J2EE è una categoria di utenti classificati da tratti comuni categorizare gli utenti in gruppi rende più facile controllare l’accesso di un grand enumero di utenti

Fine lezione

Esercizi 13] Ripetere gli esercizi 6], 7], 8] e 9] per queste slide. 14] Individuate una ragionevole enterprise application (differente da quelle introdotte a lezione), presentare poi esempi ragionevoli dei vari tipi di enterprise beans (session con o senza stato, entity con i vari tipi di persistenza, message-diriven) utilizzabili all’interno di essa. 15] Presentare esempi ragionevoli dei vari tipi di enterprise beans (session con o senza stato, entity con i vari tipi di persistenza, message-diriven) che possono ragionevolemente essere considerati COTS. 16] Presentare esempi ragionevoli di enterprise application che necessitano di almeno tre tipi di client application. 17] Presentare esempi ragionevoli di enterprise application che necessitano di schemi di sicurezza complessi (basati su più ruoli).