Newsgroup: it.comp.java
Titolo: [Architettura] Gestione delle ACL

Salve a tutto il ng,
volevo un vostro parere relativamente alla realizzazione di ACL in ambito 
J2EE. Vi spiego la situazione: l'architettura / business logic a cui faccio 
riferimento eroga N "servizi". Ogni utente correttamente loggato sul sistema 
puň, in base al proprio profilo, richiedere l'accesso ad un servizio. Il 
componente Java che implementa il servizio verifica che l'utente sia 
abilitato a quel servizio e, in caso contrario, ne vieta l'utilizzo.
Ora, l'impiego dei ruoli come previsto in J2EE non mi soddisfa, in quanto le 
combinazioni di servizi assegnati ai singoli utenti sono molto numerose. Per 
fissare le idee, se avessimo 5 servizi {A,B, C, D, E} potrei avere utenti 
con le seguenti ACL : {A}, {A,B,C}, {A,E}, {B,D}, {C,D} e cosě via, fino ad 
avere una corrispondenza quasi uno-uno con un utente ed il suo profilo.
Pertato ho pensato di caricare una ACL ad ogni login (che, banalmente, č una 
lista dei codici di servizio da assegnare all'utente come abilitati; ma 
questo poco importa) e di mantenerla in memoria sull'application server. Sul 
client che esegue l'autenticazione, viene inviata l'ACL in modo che sia 
possibile predisporre un "menů di servizi" ad hoc.
Questa proposta č stata bocciata in parte, in quanto si č ritenuto che 
memorizzare liste di servizi per ogni utente collegato fosse un onere in 
termini di memoria eccessivo per l'appserver (cosa che č in un certo senso 
possibile, si parla di un migliaio di servizi e sottoservizi e circa 
cinquemila utenti), e l'operazione di controllo dell'abilitazione un inutile 
spreco di calcolo (si tratta di ricercare un codice in un elenco...). 
Pertanto, si č scelto di inviare al client la lista delle ACL e di rendere 
l'architettura "cieca" di fronte all'accesso non autorizzato.
Se l'utente X richiede il servizio Q, si suppone che esso sia stato 
preventivamente autorizzato dal processo di login.
In pratica, il controllo d'accesso č sul client in massima parte, soluzione 
che a me preoccupa un po'. Vorrei pertanto chiedere un vostro parere su come 
affrontereste il problema.
Saluti,
    Scorpio.

 spreco di calcolo (si tratta di ricercare un codice in un elenco...).
Secondo me invece è un'ottima scelta, per diversi motivi:
- coincide con le richieste dell'applicazione;
- è relativamente semplice da implementare;
- offre spunti per molte ottimizzazioni.
Non mi piace per niente la gestione delle ACL lato client...ma scusa,
a questo punto non servono nemmeno, visto che ogni client fa quello
che gli pare!
Prova a pensare a delle ottimizzazioni possibili e proporle al team di
sviluppo, ad esempio:
- memoria: pensa a qualche struttura dati che possa ottimizzare
l'utilizzo della memoria; già solo con wildcard e/o gerarchie di
permessi puoi cambiare la complessità da polinomiale a logaritmica!
- tempo di calcolo: con il caching si risolvono molti problemi
di...stress da calcolo.
Io voto per l'ACL sul server...magari dai un'occhiata ad Acegi:
http://www.acegisecurity.org/
che è stra-usatissimo (io non ho ancora avuto il piacere, eh) e
dovrebbe essere quindi molto stabile e supportato.
Facce sapé!!!
Dimitri

di...stress da calcolo.
Il team (due persone oltre al sottoscritto) era d'accordo con l'uso dell'ACL 
replicata...al management è sembrato uno spreco di memoria (e ci sta tutto, 
questo, tranne il termine "spreco") e di tempo macchina (questo, invece, è 
risibile).
 L'ultima parola, quindi, è già stata data.....
Però, mi ha fatto piacere sentire un altro parere. E' confortante :-)
Saluti,
    Scorpio.


CIAO!
ma non potresti mantenere il sessione il profilo del client,
e fare che ogni servizio vada a vedere se il profilo del client è
compatibile?
l'elenco servizi/profli lo puoi mettere sul DB, quindi ogni servizio
farebbe una query sul DB.
è una query in piu, ma se hai l'ID del profilo in sessione, alla fine
non vedo come ti possano bucare!
Stefano

Stefano
Questo è verissimo, potrebbe essere un'idea, però a quel punto conviene un 
caching in memoria delle acl: pago in
memoria quello che pagherei, IMHO in termini maggiori, come accesso al 
database. Anche perchè gli utenti,
in prospettiva, sono parecchi.
Scorpio.