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).