martedì, settembre 16, 2008

J2EE SecurityService: potente ma...

...decisamente "entropico"!

Niente da dire su JAAS lato autenticazione, realizzato un po' sul modello di PAM (con cui tra l'altro può interagire), JAAS è decisamente costruito bene dal punto di vista dell'autenticazione.. per J2SE.. in J2EE le cose non vanno altrettanto bene dato che:
  1. ci si può autenticare in Ackerman(N,N) modi con N>3... il che tradotto da "modoDiDire" a "italiano standard" significa "troppi";
  2. l'autenticazione avvenuta in ognuno di questi modi porta a risultati diversi.. se almeno uno potesse scegliere una delle modalità di autenticazione qualunque (la più standard, la più comoda, ...) ottenendo lo stesso risultato... invece ci si può autenticare:
    • lato web-tier, utilizzando uno dei metodi vari (BASE,FORM,DIGEST,CUSTOM ecc) con identità salvata lato web-tier e propagata lato EJB;
    • direttamente tramite API dell'AS (come "com.sun.appserv.security.ProgrammaticLogin" in glassfish) saltando tutti i meccanismi di autenticazione standard.. e anche questo lato web e lato business con enormi differenze sul risultato;
    • utilizzando librerie che interagiscano con JAAS e con il SO, ad esempio per effettuare il login usando l'identità locale dell'utente (ad esempio un client di una applicazione EE potrebbe usare le credenziali di Windows o di PAM in Linux, Unix, MacOSX, "/.*[xX]/");
    • creando un proprio LoginModule e Realm (tanto per aggiungere entropia.. finiremo per confonderci con il "rumore di fondo"!!!)...
    • ...mi fermo ma potrei proseguire, sicuramente uno standard (anche de-facto) farebbe piacere.
  3. autenticazione=??? Ok, abbiamo controllato tutti i LoginModule di questa terra, username+password, impronte digitali, scansione retinica, statistiche di digitazione, impronta vocale, eco nel padiglione auricolare destro, ecc ecc... e mò? Salvataggio di Subject, Principal, Credentials... Tutto qui? E poi? Perché devo scrivere nel subject che sono "Gabriele Lombardi", creare un principal con dentro scritto "Gabirele Lombardi" e magari salvare le credenziali "Gabriele Lombardi"+"PasswdFuffa"???
Ma mica abbiamo finito.. eh no! Diamo un occhio lato autorizzazioni, da questo lato l'architettura è stra-fine: gestione di risorse, gestione di policy sulle risorse, di regole nelle policy, di permissions sulle risorse, di...
...insomma un casino!

Allora, dico io, va bene che bisogna poter fare mille cose.. che la sicurazza è una cosa, che bisogna essere generali e che usare i DesignPatterns aiuta a sviluppare software riutilizzabile e corretto... però a tutto c'é un limite! OPPURE...
Bene.. cari Sunnisti, esiste un simpatico BANALE pattern GOF di nome "Facade", lo usate sempre... ci sono package che fanno anche il caffé e nelle API pubbliche se ne vedono 4 classi/interfacce/annotazioni in croce! (Vedasi javax.persistence... fa l'impossibile.. ma "di nascosto")... usarlo anche per il SecurityService no eh? Magari usarlo UNA SOLA VOLTA ma bene.. creando un solo standard di accesso al servizio... non 27 modi diversi, non standard, vendor-dependent... e in generale diversi o peggio... quasi uguali ma con sfumature "cangianti"!!!

DETTO QUESTO...

Butto li una domanda-esempio: se volessi gestire dinamicamente utenti (e gruppi di utenti/gruppi organizzati in un DAG) nonché risorse (organizzate ad albero o DAG anche loro)... e poi volessi creare dei permessi che associno risorse e utilizzatori (utenti o gruppi) in maniera da poter risolvere i permessi sfruttando ereditarietà sia sulle risorse che sugli utenti/gruppi... come potrei fare? Ovviamente il tutto lo voglio fare dinamicamente.. non voglio uno staticissimo policy-file!

ESEMPIO:

RISORSE:
  • PhotoGallery
    • Gallery1
    • Gallery2
con permessi ordinati "edit">"comment"> "browse" (cioè che si implicano l'un l'altro).

UTENTI:
  • Users
    • Admin
    • Owner
    • KnownUser
PERMESSI:

  • Admin->Risorse: "*"
  • Owner->PhotoGallery: "*" (o "edit" dato che implica le altre)
  • KnownUser->Gallery1: "comment"
  • User->PhotoGallery: "browse"
Al che "Ciccio", associato al gruppo KnownUser, può vedere tutte le gallerie, ma può commentare solo Gallery1 e non può editare. "MasterOfPuppets" associato al gruppo Admin può fare tutto, mentre "QuiQuoQua", owner della galleria, può fare tutto.. ma solo sulla (sua) galleria.

Soluzione? Ovviamente costruibile a run-time.. cioè creando la struttura di risorse e utilizzatori a run-time aggiungendo tuple in una o più tabelle, creando le tuple di utenti e gruppi e creando le tuple per i permessi.

Vi prego... FLAMMATEMI questo post, così magari ci capisco un po' di più!!! ;)