Issuu on Google+

UniversitĂ  degli studi di Catania FacoltĂ  di Scienze Matematiche, Fisiche e Naturali Corso di laurea in Informatica Applicata

Sicurezza dei sistemi informatici 1 Prof. Giuseppe Scollo

Modelli di condivisione e di autorizzazione nella piattaforma Liferay Portal

Giovanni Marotta matr. A40/000073

1


Premessa Come in qualsiasi manuale, articolo, relazione in Italiano che tratta temi informatici è sempre problematica la trattazione dei termini tecnici, attanagliati dal problema se tradurli, con il rischio di banalizzarne suoni e significati, oppure farcire il testo di “inglesismi” che di contro strizzano troppo l’occhio al “freak tecnologico” e lasciano esclusi i “comuni mortali”. Dopo sofferta riflessione ho deciso di tradurre solo pochi termini, quelli più ovvi o comunque consolidati nella letteratura scientifica in lingua italiana, lasciando inalterato la terminologia “angloforme”, sperando nel perdono dei “comuni mortali”. Genere e tipo degli articoli determinativi e indeterminativi sono scelti in dipendenza dall’equivalente termine italiano e dall’assonanza della pronuncia del termine inglese.

1. Introduzione Liferay Portal è un’implementazione open-source di una piattaforma che permette la realizzazione di Enterprise Portals a cui possono essere aggiunte funzionalità tipiche di un CMS (Content Management System). In particolare ci soffermeremo sugli aspetti di organizzazione dei soggetti e delle risorse, nonché sui meccanismi di attribuzione dei permessi per l’accesso alle risorse da parte dei soggetti. Allo stato, il prodotto è disponibile nella versione 5.2.3, e durante la sua evoluzione è passato da una politica di protezione delle risorse di tipo elementare basata sull’uso di password ad una basata sull’assegnazione dei permessi di accesso alle risorse soltanto tramite ruoli. Prendendo a spunto le caratteristiche e le differenze tra alcune versioni, avremo la possibilità di fare un breve excursus su alcune modalità di realizzazione di politiche di condivisione di risorse e di autorizzazione al loro accesso in un ambiente di tipo collaborative work. Liferay è, dal punto di vista tecnologico, una piattaforma che offre tutti i servizi di un portal manager secondo il paradigma del portlet container. Nella prossima sezione saranno dunque presentati i concetti di base sui portali basati sulle portlet.

2


2. Portali e portlet Sovente non viene fatta distinzione tra un sito Web ed un portale Web ed i due nomi vengono usati indifferentemente per riferire l'uno o l'altro. Se cerchiamo però di capire la differenza tra i due, possiamo a grosse linee affermare che un portale è una specializzazione di un sito Web che costituisce un punto di partenza, una porta di ingresso, ad un gruppo consistente di risorse di Internet o di una Intranet. Un portale fornisce un’ampia gamma di prestazioni, servizi, contenuti e collaborazioni commerciali o culturali, inoltre consente di avere una vista personalizzata per ogni utente che lo visita in base a delle scelte (sia che sia lo stesso utente a scegliere, sia che sia un sistema "intelligente" a farlo al suo posto). Per rendere più facile e appetibile l’esperienza dell’utente nella navigazione dei siti, in particolari di quelli commerciali, negli ultimi anni c'è sempre più la tendenza a rendere i portali personalizzabili; le pagine Web, infatti tendono a ricalcare l’aspetto visivo e di usabilità tipici di applicazioni desktop, con la possibilità di spostare le finestre dove risiedono le informazioni, aggiungerne di nuove, ridurle a icona. In ambiente Java, ognuno di questi elementi che danno vita a finestre è noto come portlet. Una portlet è una classe Java che si configura come modulo Web riusabile all'interno di un portale. Ciascuna portlet è destinata ad una semplice applicazione, ad esempio servizi di news, previsioni meteo, o funzionalità legate a forum o email. In quanto finestre, le portlet possono essere chiuse o ridotte o spostate. L'utente che accede al portale può così personalizzare la sua pagina personale, adattando i contenuti della stessa alle proprie esigenze. 2.1.

Portlet e servlet

Dal punto di vista architetturale, le portlet sono un tipo speciale di servlet progettate per essere inserite facilmente in un portal server ed essere eseguite. Le servlet sono oggetti che operano all'interno di un Application Server (per esempio, Tomcat) e potenziano le sue funzionalità. L'uso più frequente delle servlet è generare pagine Web in forma dinamica a seconda dei parametri della richiesta spedita dal browser. Una servlet può avere molteplici funzionalità e può essere associata ad una o più risorse Web. Un esempio potrebbe essere un meccanismo per il riconoscimento dell'utente. Quando si digita un URL del tipo miosito/login.login viene invocata una servlet che verifica la correttezza dei dati inseriti e indirizza ad una pagina di conferma o di errore a seconda del risultato. La differenza principale che sussiste fra una servlet e una portlet è legata al contesto di esecuzione: le servlet lavorano secondo un modello uno a uno con il client (una request viene gestita da una sola servlet), e quindi rappresentano l'unico punto di ingresso allo strato server da parte del client. Per le portlet, a fronte di una richiesta, si possono eseguire contemporaneamente più portlet ed avere una sola pagina di risposta. Le servlet possono essere sviluppate senza tener particolarmente conto di cosa accade nel resto della pagina che viene inviata in risposta alla request: tale pagina può essere prodotta da una sola servlet, oppure più servlet possono essere responsabili della preparazione di varie parti della pagina finale, ma in definitiva è come se ognuna lavorasse per conto proprio. 3


Questo modello, pur essendo relativamente semplice e rudimentale, ha un innegabile svantaggio: se si devono comporre contenuti diversi, si richiede una molteplice esecuzione di thread indipendenti anche se l'output finale è sempre unico (la pagina appunto). Ad esempio nella home page di un ipotetico portale web, la servlet che calcola un calendario, quella delle rolling-news, e la cmsservlet dovranno essere eseguite in parallelo per comporre la pagina complessiva. Questo porta a un maggior carico di lavoro per il server, con un degrado delle prestazioni: probabilmente, se cambia una news, il calendario degli eventi o il contenuto di un box di testo non devono essere aggiornati (quindi non si rende necessario un nuovo accesso al DB per caricare i dati del calendar o del box di testo). In teoria la pagina potrebbe essere aggiornata solamente con la esecuzione della servlet delle news, mentre il resto della pagina potrebbe essere riprodotta con dati mantenuti in cache o con HTML "pre-prodotto". L'obiettivo delle portlet quindi è proprio quello di risolvere questo aspetto: dare la possibilità di creare un ecosistema di componenti web i quali possano cooperare nella realizzazione di contenuti web in maniera ottimizzata. La Figura 1. ben schematizza l'idea di un portale costruito attraverso l’uso di portlet. L'utente finale costruisce una pagina per aggregazione dei singoli elementi, avendo come risultato finale una pagina Web configurabile ed adattabile alle volontà dell'utente.

Figura 1. Struttura di un portale costruito con portlet

2.2.

Architettura software dei portlet container

A differenza delle servlet, che possono rappresentare pagine Web complete, le portlet rappresentano singoli componenti, aggregati dal portale che svolge la funzione di container. Ne consegue che il portlet container del portale ha un ruolo più determinante del servlet container, poiché attraverso di esso le portlet comunicano tra loro, accedono a contenuti remoti e a dati persistenti. 4


Le portlet, inoltre, non possono essere raggiunte da un URL specifico, in quanto è il portale intero ad avere associato l'indirizzo.che viene sviluppato indipendentemente dagli altri, non possono dunque inviare redirect o errori, inoltrare richieste o scrivere markup al flusso in uscita. In pratica si tratta di una singola applicazione che ha bisogno del container per poter essere eseguita e sviluppare qualche requisito di logica. Le varie portlet devono essere inserite all'interno di portlet applications, che sono applicazioni standard J2EE basate sulla specifica JSR168 e che utilizzano un file di configurazione portlet.xml per specificare il contenuto della applicazione e il particolare funzionamento delle singole portlet. Le varie portlet applications sono poi collocate all'interno di un contesto di esecuzione che è rappresentato dal portlet container: quest’oggetto, sulla base delle configurazioni delle applicazioni e delle azioni dell'utente (link, form, javascript, ecc), esegue le operazioni di orchestrazione e di coordinamento della applicazione. In particolare il portal server esegue il dispatch delle request a tutte le portlet contenute in una singola pagina e quindi svolge il lavoro di orchestrazione e coordinamento delle request e delle response.

Figura 2 – Architettura di un portal server.

Ogni pagina sarà dunque una composizione di singoli componenti, ognuno sviluppato indipendentemente dall'altro. Ovviamente ci sono delle funzionalità generali (come per esempio l'autenticazione) che verranno fornite dal container, che gestisce il ciclo di vita del singolo componente in base a come la portlet è stata sviluppata. Il ciclo di vita di una portlet viene illustrato in Figura 3.

5


Figura 3. Ciclo di vita di una portlet Prima di analizzare il flusso generale, discutiamo l'ultima colonna, dove abbiamo i metodi principali di una portlet. Fondamentalmente ve ne sono due, init() e destroy() che vengono richiamati all'inizio e alla fine (sempre dal portlet container) in maniera analoga a quanto accade con le servlet in base ai principi di ottimizzazione decisi dal container. Il flusso di esecuzione è abbastanza semplice da capire. L'idea è quella di avere diverse action che avviano un metodo (Process Action) in cui viene definita la logica di controllo. Attraverso essa possiamo reindirizzare il processo di Render, che è il passo che segue. Il processo di Render produce la vista finale della portlet (seguendo il flusso di logica di controllo nella Process Action). Ogni singola portlet è vista come una singola mini applicazione che verrà inserita nel contesto di pagina, quindi, il ciclo di vita si riferisce ad essa in quanto singola unità. Il prodotto dell'interazione con l'utente (attraverso i metodi Process Action e Render) produrrà, non una nuova pagina HTML, ma uno spezzone di codice HTML che verrà decorato dal portlet container e inserito nel contesto di pagina. Il caso in questione illustra il flusso di una singola portlet ma, in realtà, dovrebbe essere replicato per quante portlet sono presenti nella pagina di rendering finale. Lo standard citato precedentemente si riferisce alla specifica Portlet 1 (JSR168); da qualche tempo è disponibile la specifica Portlet 2 (JSR286).

6


3. Modelli gerarchici e politiche di condivisione e autorizzazione Liferay Portal è una piattaforma open-source di tipo portlet container per la realizzazioni di portali aziendali che integrano caratteristiche di collaborative work. E’ un’implementazione scritta principalmente in linguaggio JAVA (back-end) e JSP (front-end) e presenta grande facilità di customizzazione dell’ambiente mediante l’integrazione di out-of-the-box tools, inclusi Liferay CMS e Liferay Collaboration che offrono funzionalità di web publishing, content management, collaboration and social networking. Per ciò che riguarda gli aspetti rilevanti al nostro lavoro, l’attuale versione del prodotto presenta le seguenti caratteristiche salienti: •

Aggregazione di utenze in maniera sia gerarchica che trasversale rispetto all’organizzazione, permettendo in tal modo buona flessibilità nella gestione dei soggetti e delle risorse di vari tipi di organizzazione secondo varie dimensioni: per gerarchia, sedi geografiche, gruppi di interesse comune, o per un mix delle precedenti configurazione di permessi basate sui “Ruoli”: tramite l’adozione di questo modello è possibile controllare i permessi in maniera molto granulare e secondo criteri di ereditarietà gerarchica degli stessi accesso unico al sistema tramite SSO (Single Sign-On) realizzazione di autenticazioni e federazioni di identità con le utenze di navigazione, di backoffice e delle applicazioni integrate, presenti su directory accessibili tramite LDAP, con meccanismi standard quali CAS Server, OpenID, OpenSSO.

• •

Va tuttavia precisato che il prodotto ha attraversato varie e importanti modifiche nella modellazione delle politiche di creazione dei raggruppamenti e dell’attribuzione dei permessi di accesso alle risorse. Nel seguito analizzeremo le caratteristiche di quattro versioni della piattaforma, allo scopo di analizzare le differenze concettuali nella progettazione dei vari modelli e in alcune implicazioni operative. Prendendo a riferimento una particolare versione, nella sezione 4 saranno presentati degli esempi applicativi. 3.1.

Liferay Portal v4.0

E’ da questa versione in poi che il meccanismo di attribuzione e controllo dei permessi viene reso granulare, flessibile ed ereditario. Tuttavia il focus è ancora sulla attribuzione dei permessi di accesso alle risorse direttamente a soggetti o raggruppamenti di soggetti, secondo criteri tipici delle Access Control List (ACL). Il concetto di ruolo, pur essendo presente, non è esclusivo per l’assegnazione dei permessi, ma additivo. Anche la creazione di raggruppamenti e delle loro relazioni gerarchiche e/o trasversali differisce da quella attuale. 3.1.1.

Definizione delle entità

In questa sezione vengono presentate tutte le entità coinvolte nel modello di sicurezza, alcune delle quali sono state introdotte a partire da questa versione.

7


Risorse E’ un termine generico per qualsiasi oggetto del portale (portlets, classi Java, files). Le risorse possono avere uno dei tre tipi di ambito di visibilità (scope) : Enterprise, Community, Individual. Il diagramma sottostante mostra le relazioni tra i tre tipi.

Essenzialmente, una Enterprise è il gruppo ombrello per tutti gli oggetti del portale. Le proprietà delle risorse con questo tipo di scope si applicano a tutti gli oggetti dello stesso tipo lungo tutto il portale, ovvero attraverso tutte le Communities. Una Enterprise può contenere qualsiasi numero di Communities. Ogni Community può contenere qualsiasi numero di oggetti. Le proprietà delle risorse con questo tipo di scope si applicano a tutti gli oggetti dello stesso tipo definite nella stessa Community. Le proprietà delle risorse con scope Individual si applicano ad un solo oggetto. Permessi Un permesso viene canonicamente definito come un’operazione che agisce su una risorsa. La tabella sottostante mostra alcuni permessi di esempio correlati a risorse di tipo “Message Board Topics”.

Come si può notare da questo esempio lo scope della risorsa determina indirettamente lo scope dell’operazione che uno User effettua su quella risorsa.

8


I permessi con scope di tipo Enterprise e Community, cioè su risorse con quello scope, possono essere assegnati soltanto alle entità che rappresentano soggetti - Users, Communities, Organizations, Locations - solo tramite Ruoli (vedi oltre per maggiori dettagli). Permessi con scope Individual possono essere invece direttamente assegnati ad uno User, una Community, una Organization, una Location. Vige il principio di trasmissione dei permessi per affiliazione ad un gruppo. Infatti, ogni permesso assegnato o direttamente o tramite Ruoli ad una Community, Organization o Location viene acquisito dagli Users che diventano membri dell’entità. In generale i permessi sono additivi in modalità disgiuntiva, ma il controllo avviene sempre nell’ordine: • • •

Individual Community Enterprise

Nella direzione additiva questa regola non crea problemi nella comprensione della logica di business da parte dell’amministratore, ma quando i permessi vengono rimossi ad un utente rimane sempre il rischio che li erediti dagli scope più alti, ingenerando confusione e comportamenti indesiderati nel sistema di controllo dei permessi. Ruoli Un Ruolo è una collezione di permessi sulle risorse, cioè definisce le operazioni possibili sugli oggetti. Supponiamo di definire un Ruolo che abbia i permessi di visualizzare, modificare e cancellare una certa risorsa che ha scope di tipo Enterprise. Se ad un utente viene assegnato quel Ruolo, egli conseguentemente acquisisce i permessi di quel Ruolo. I Ruoli possono essere assegnati ad uno User, una Community, una Organization od una Location. Come abbiamo già detto, i permessi con scope di tipo Enterprise e Community possono essere assegnati a Users, Communities, Organizations, Locations solo tramite Ruoli. Se viene assegnato un Ruolo ad una Community, Organization od una Location, tutti gli Users che diventano membri di queste entità ereditano il Ruolo. Come si può notare in questa stesura del modello, i Ruoli acquisiscono gli scope tramite le risorse cui si applicano e non tramite quello delle entità a cui vengono assegnati, rischiando di generare confusione, conflitti o comportamenti indesiderati se non controllati con altri meccanismi. Users Uno User è un soggetto che esegue azioni sugli oggetti del portale dipendentemente dai permessi e dai ruoli che gli sono stati assegnati. Uno User può ricevere permessi nella maniera seguente: 9


• • • • • • • •

permesso direttamente assegnato ad esso permesso assegnato ad una Community a cui lo User appartiene permesso assegnato ad una Organization a cui lo User appartiene permesso assegnato ad una Location a cui lo User appartiene permesso appartiene ad un Ruolo che viene assegnato direttamente allo User permesso appartiene ad un Ruolo che viene assegnato ad una Community a cui lo User appartiene permesso appartiene ad un Ruolo che viene assegnato ad una Organization a cui lo User appartiene permesso appartiene ad un Ruolo che viene assegnato ad una Location a cui lo User appartiene Organizations and Locations

Queste due entità servono a modellare l’organizzazione di una compagnia. In tale prospettiva, una Organization rappresenta la parent corporation, mentre una Location rappresenta una child corporation all’interno dell’organizzazione, spesso distinta per ambito geografico. Organizations possono avere un qualsiasi numero di Locations correlate. In questa versione vige la limitazione che uno User può appartenere ad una sola Organization e ad una sola Location. In aggiunta, non è ancora possibile creare una gerarchia a livelli multipli di Organizations. A Organizations e Locations possono essere assegnati sia Ruoli (per i permessi di tipo Enterprise e Community) che permessi di tipo Individual. Le Locations ereditano i permessi associati ai Ruoli delle Organizations cui appartengono. Communities Le Communities sono raggruppamenti di Users con interessi comuni, ma non defiscono raggruppamenti gerarchici. Per ciò che riguarda i permessi, le Communities non sono correlate ad alcuna Organization o Location e ad esse possono essere assegnati sia Ruoli che permessi di tipo Individual. Uno User può appartenere, contrariamente al caso di Organizations e Locations, a più Communities. User Groups User Groups sono raggruppamenti di Users che, diversamente da Organizations, Locations e Communities, non hanno risorse specifiche associate ad essi. Sono stati istituiti solo per scopi amministrativi, allo scopo di poter assegnare permessi e Ruoli a gruppi di utenti piuttosto che al singolo User. User Groups possono essere assegnati a una Community. Uno User può appartenere, come per il caso delle Communities, a più User Groups. Agli User Groups possono essere assegnati sia Ruoli che permessi di tipo Individual. Uno User può appartenere ad un numero qualsiasi di User Groups e di ognuno riceve Ruoli e permessi. 10


3.1.2.

Assegnazione dei permessi alle risorse

Come abbiamo già avuto modo di rilevare, questa versione basa il modello di autorizzazione in prima battuta sull’assegnazione di permessi alle risorse e successivamente all’assegnazione dei permessi e di ruoli ai soggetti. Vediamo di illustrare come uno sviluppatore definisce definisce tutte le risorse e i loro permessi. Prima di tutto ribadiamo che il termine “Risorsa” è un termine generico per ogni oggetto contenuto nel portale. Esempi sono: portlets (es. Message Boards, Calendar), classi Java (es. Message Board Topics, Calendar Events) e files (es. documenti, immagini). Prendiamo ad esempio la risorsa custom portlet. Per ogni custom portlet, il portale ha bisogno di sapere se vi sono risorse che necessitano permessi e se vi sono permessi di tipo custom da assegnare, ovvero usano models che definiscono permessi di tipo custom. Queste informazioni sono incapsulate all’interno di un file XML, che non è necessario solo nel caso in cui le portlets usano i permessi di default view e configuration. Prendiamo ad esempio un file XML che definisce le azioni su risorse chiamate blogs portlets. <?xml version="1.0"?> <resource-action-mapping> <portlet-resource> <portlet-name>33</portlet-name> <supports> <action-key>ADD_ENTRY</action-key> <action-key>CONFIGURATION</action-key> <action-key>VIEW</action-key> </supports> <community-defaults> <action-key>VIEW</action-key> </community-defaults> <guest-defaults> <action-key>VIEW</action-key> </guest-defaults> <guest-unsupported> <action-key>ADD_ENTRY</action-key> </guest-unsupported> </portlet-resource> <model-resource> <model-name>com.liferay.portlet.blogs.model.BlogsCategory</model-name> <portlet-ref> <portlet-name>33</portlet-name> </portlet-ref> <supports> <action-key>DELETE</action-key> <action-key>PERMISSIONS</action-key> <action-key>UPDATE</action-key> <action-key>VIEW</action-key> </supports> <community-defaults> <action-key>VIEW</action-key> </community-defaults> <guest-defaults> <action-key>VIEW</action-key> </guest-defaults> <guest-unsupported> <action-key>UPDATE</action-key>

11


</guest-unsupported> </model-resource> <model-resource> <model-name>com.liferay.portlet.blogs.model.BlogsEntry</model-name> <portlet-ref> <portlet-name>33</portlet-name> </portlet-ref> <supports> <action-key>ADD_COMMENT</action-key> <action-key>DELETE</action-key> <action-key>PERMISSIONS</action-key> <action-key>UPDATE</action-key> <action-key>VIEW</action-key> </supports> <community-defaults> <action-key>VIEW</action-key> </community-defaults> <guest-defaults> <action-key>VIEW</action-key> </guest-defaults> <guest-unsupported> <action-key>UPDATE</action-key> </guest-unsupported> </model-resource> </resource-action-mapping>

La prima cosa definita è la portlet stessa (tag <portlet-resource>) e quindi le azioni che la portlet supporta (tag <supports> ). Le azioni che vanno inserite sono quelle eseguite sulla portlet che richedono un controllo d’accesso (ADD_ENTRY, CONFIGURATION, VIEW) inserite nel tag <actionkey>.

Dopo aver definito le azioni che richiedono un controllo, si passa a definire alcuni dei permessi. Il tag <community-defaults> definisce le azioni permesse agli Users che appartengono alla Community dove la portlet risiede. Stessa cosa per eventuali Guests. Il tag <guest-unsupported> contiene azioni che non possono in ogni caso essere permesse, quindi un meccanismo che possa permettere una definizione di diritti negativi. Dopo aver definito la portlet come risorsa, si passa a definire quei models per le portlets che richiedono controlli di accesso. All’interno del tag <model-resource> definiamo il nome del model (nome della classe Java che lo rappresenta). Quindi si passa a definire il nome (o in nomi, caso raro) delle portlet a cui il model si applica. Il resto è simile a quanto visto per le portlet. Come si può vedere dal listato, uno User deve avere permessi, rispetto ad una blog entry, per potervi aggiungere commenti, cancellarla, cambiarne i permessi, modificarla o semplicemente visualizzarla.

12


3.2.

Liferay Portal v4.3

Organizations e Locations, così come introdotte nella versione 4.0 permettevano una struttura a due livelli, che però non era in grado di soddisfare i requisiti gerarchici della maggior parte delle organizzazioni complesse. E proprio dietro ai requisiti di una particolare esigenza della COPCA, un’agenzia governativa Catalana, che si è giunti alla proposta che ha permesso di raggiungere il livello di flessibilità multi-livello che caratterizza le versioni dalla 4.3.1 in poi. Permane però il vincolo secondo il quale uno User possa appartenere al massimo ad una sola Organization e ad una sola Location. Riformuliamo per prima cosa le definizioni di Organizations e Locations fin qui apprese. Organizations Rappresentano la struttura logica della compagnia o istituzione, modellata su una struttura gerarchica multi-livello. Lo User può essere assegnato al massimo ad una Organization della quale eredita i permessi e le associazioni. Lo User eredita permessi e associazioni dei parents dell’organizzazione di appartenenza che sono state contrassegnate come recursable. Il nome Organization è stato scelto perché può essere applicato con successo ai casi di dipartimenti, gruppi, divisioni, partner, fornitori, ecc. Locations Rappresentano le locazioni fisiche dove la compagnia o l’istituzione può avere delle sedi. Ogni Location appartiene ad una Organization. Lo User può essere assegnato al massimo ad una più Location che deve appartenere alla Organization alla quale lo User appartiene, ovvero ad uno dei recursable parents di quella organizzazione. In molte situazioni l’uso delle sole Organizations sarà sufficiente a modellare la struttura della compagnia o istituzione. L’aggiunta delle Locations potrà essere richiesta nelle strutture molto complesse, così come vedremo negli esempi. Ogni Organization e ogni Location può avere adesso il proprio insieme di pagine pubbliche e private, così come accade per le Communities. Users che appartengono ad una Organization o Location potranno navigare non solo tra le pagine ad essa associate ma anche a quelle delle Parent Organizations.

13


3.3.

Liferay Portal v4.4

In questa versione viene estesa la possibilità, per ogni User, di appartenere a più Organizations e di assumere, all’interno di ogni Organization, un Organization Role diverso per ognuna, se desiderato. 3.3.1.

Memorizzazione dei permessi nel Database

Prendendo a riferimento questa versione della piattaforma, rivolgiamo uno sguardo più approfondito allo schema del database interno.

Figura 4. Database del portale Analizzando lo schema, si evince che il possesso di un particolare permesso su una risorsa da parte di uno User dipende dal Ruolo che lo User ha, oppure dall’appartenenza ad una Community (groups nelle tabelle) e Organization (tabelle verdi). Se questi ruoli o entità di appartenenza contengono lo specifico permissionId nella tabella dei permessi (in blu), allora l’utente ha l’accesso alla risorsa. Inoltre si nota che l’attributo scope permane, in questa versione, all’interno della tabella resource_, ciò a conferma di quanto detto in precedenza. Infine, a titolo di esempio, in Figura 5 si mostra la struttura della tabella permission_.

14


Figura 5. Struttura di una tabella Nella tabella in esame, una risorsa BlogsEntry di resourceId=8 può avere una riga nella tabella permission_ per l’azione VIEW ed un’altra per l’azione UPDATE.

15


3.4.

Liferay Portal v5.2

La major version 5 si caratterizza, per ciò che riguarda gli aspetti inerenti il nostro lavoro, per aver introdotto il concetto di assegnazione dei permessi soltanto attraverso i Ruoli e non direttamente agli utenti e ai suoi raggruppamenti. Trattandosi della versione più recente del prodotto (release 5.2.3) all’atto della redazione del lavoro, vale la pena soffermarsi sugli aspetti architetturali del portale, sulle relazioni tra le varie entità e sulla politica dei permessi. 3.4.1.

Architettura delle entità del Portale

Di seguito vengono illustrati i concetti di base che vengono usati per organizzare le entità del Portale.

Figura 6. Entità del Portale • • • •

Al Portale hanno accesso gli Users Gli Users possono essere raggruppati in User Groups Gli Users possono appartenere ad Organizations. Le Organizations possono essere raggruppate in gerarchie, quali ad es. Home Office -> Regional Office -> Satellite Office Users, User Groups e Organizations possono appartenere a Communities

Il modo più semplice per pensare il tutto è che ci sono degli Users e vari modi per raggrupparli. Come prima, alcuni raggruppamenti sono seguono gerarchici (Organizations), altri no (Communities). Altri raggruppamenti possono essere effettuati amministrativamente attraverso la creazione di Ruoli, entità trasversali agli altri raggruppamenti, che servono per collezionare permessi sulle risorse del portale da assegnare a Users, User Groups, Organizations e Communities. Ad esempio, il ruolo “Message Board Administrator” può essere creato per quegli Users, provenienti da diverse Organizations e Communities, che hanno i permessi per amministrare qualsiasi Message Board nel portale.

16


In Figura 6 ciascuna freccia può essere letta come “può essere un membro di”. Ciò vuol dire che Organizations possono essere membri di Communities, Communities possono essere membri di Ruoli, Users possono essere membri di qualsiasi cosa, ecc. I permessi vengono attribuiti soltanto alle entità Ruoli. In precedenza, era possibile che i permessi venissero assegnati anche a Users, Organizations, Locations e Communities. Users Come si può notare, gli Users possono essere raggruppati in vari modi. Essi possono essere membri di organizzazioni gerarchiche, possono essere raggruppati in User Groups arbitrari e possono essere membri di Communities. Ed essi possono assumere Ruoli che descrivono le loro funzioni nel sistema, e questi Ruoli possono essere estesi a tutto il Portale (Ruoli), limitati alle Organizations (Organization Roles) e alle Communities (Community Roles). User Groups Gli User Groups sono semplici ed arbitrari raggruppamenti di Users, creati da amministratori. Essi possono essere membri di Ruoli e di Communities, ma non di Organizations. Nonostante non possano avere pagine associate come le Organizations e le Communities, possiedono tuttavia Page Templates da utilizzare per personalizzare le proprie pagine come Users. Ruoli I Ruoli sono raggruppamenti amministrativi a cui possono essere garantiti vari permessi che determinano le azioni che i soggetti associati a tale ruolo possono compiere all’interno delle risorse del Portale. Vi sono tre tipi di Ruoli: • • •

Portal Roles Organization Roles Community Roles

I Ruoli vengono utilizzati per definire permessi lungo il loro scope: trasversalmente al Portale, trasversalmente ad una Organization, trasversalmente ad una Community. Si faccia il caso di un Ruolo che garantisca accesso ad una categoria chiamata Message Board. Un Portal Role garantirebbe questo tipo di accesso lungo tutto il portale; un Organization Role lo garantirebbe solo dentro la Organization entro cui è definito e cosi per un Community Role. Come si può notare, nella versione 5 della piattaforma, lo scope viene direttamente assegnato ai Ruoli e non più alle risorse, come accadeva invece nelle precedenti versioni. Poiché le entità Ruoli sono strettamente usate per implementare la sicurezza del portale, esse non possiedono pagine come Organizations e Communities. Possono essere membri di Ruoli sia Users che User Groups, Communities e Organizations.

17


Organizations Sono raggruppamenti gerarchici di Users. Assieme alle Communities sono le uniche risorse del Portale che possono avere pagine associate. Le Organizations sono particolarmente utili per definire la posizione gerarchica di uno User all’interno dell’organigramma aziendale. Inoltre è possibile, in questa versione, inserire lo stesso User all’interno di più Organizations. Le Locations, adesso, vengono classificate come un tipo speciale di Organization, all’interno del quale uno User può essere inserito in maniera specifica per ciò che riguarda la sua locazione. Le Organizations possono far parte di Communities e possono naturalmente essere associate a specifici Ruoli. Communities Le Communities sono raggruppamenti di Users con interessi comuni, ma non defiscono raggruppamenti gerarchici. Sono designate ad accogliere aggregazioni di Users trasversali ai livelli gerarchici dell’organigramma o addirittura separati da essi. Una Community condivide un insieme di pagine pubbliche e private. Le pagine di default del Portale sono all’interno della Guest Community. Vi sono tre tipi di Communities: Open: permettono allo Users di unirsi e lasciare la Community liberamente Restricted: richiedono che lo User venga aggiunto alla Community da un amministratore della stessa dietro richiesta Hidden: come la Restricted ma non viene mostrata nella Community Portlet o nel Control Panel.

• • •

3.5.

Assegnazione di permessi alle entità del Portale

Come precedentemente affermato, i permessi vengono attribuiti solo attraverso i Ruoli. E’ evidente che Users, User Groups, Organizations e Communities debbano essere associati a Ruoli per definire la politica di accesso alle risorse del Portale. Per ognuna di queste entità esistono Ruoli di default con diritti pre-impostati, ma modificabili, che hanno validità all’interno delle entità di riferimento (Portal Roles, Organization Roles, Community Roles). Users Quando si crea un nuovo User, esso potrà essere associato ad uno o più Portal Roles tra quelli esistenti affinché possa usufruire dei diritti amministrativi desiderati. Naturalmente, se lo User verrà affiliato a qualche Organization e/o Community, egli erediterà i Ruoli associati a questi raggruppamenti (vedi oltre per l’associazione di Organizations a Organization Roles e Communities a Community Roles). Va inoltre specificato che in fase di configurazione, si può stabilire quali Ruoli hanno possibilità di modificare lo User creato. 18


Organizations A partire dalla versione 4.4, le Organizations servono a replicare la gerarchia di un’organizzazione fino ad un numero teoricamente illimitato di livelli. Ogni raggruppamento di Users che svolgono le stesse funzioni o sono locati nella stessa sede possono essere aggregati in Organizations gerarchicamente legate tra di loro in una struttura di tipo (Parent-Children Organizations). Le Locations continuano a non modellare strutture gerarchiche. Tramite l’appartenenza ad una Organization è così possibile assegnare agli Users che vi appartengono i diritti amministrativi desiderati assegnando loro specifici Organization Roles (uno o più), che come è stato già detto, hanno validità solo all’interno della Organization. Gli Organization Roles di default sono tre: Organization Administrator, Organization Member e Organization Owner. User Groups User Groups non possono avere Ruoli, ma possono essere aggiunti a (Portal) Ruoli. Si evince che il loro utilizzo riguarda la possibilità di modellare una politica di permessi più sofisticata, realizzata mediante l’integrazione con quella delle Organizations e delle Communities. Communities Amministrativamente si fa distinzione tra utenti che possono agire attivamente nella modifica della struttura del portale in questione (anche se solo al livello di pagine personali) e quelli che invece usufruiscono solo ed esclusivamente dei contenuti finali. La distinzione avviene a livello di Ruolo ed è tra i seguenti profili: • • • •

Power User: utente che possiede i privilegi per poter customizzare una sua pagina personale, attribuitavi alla creazione dell’utenza. User: utente che non possiede spazio personale, appartenente alla Community, nella quale può solo usufruire dei servizi messi a disposizione, con privilegi definiti dall’amministratore del sistema. Administrator: super utente che può definire community, creare pagine e può definire permessi per le applicazioni esposte negli spazi pubblici e privati. Guest: utente ospite del portale. Può solo navigare i contenuti pubblici messi a disposizione. Ruoli

Rispetto ad uno specifico Ruolo, possono essere definiti sia quali permessi possono essere concessi a quel Ruolo sia quali Users, User Groups o Ruoli hanno il permesso di crearlo, modificarlo o cancellarlo. Soltanto per i Portal Roles è possibile definire due tipi di permessi: Portal Permissions e Portlet Permissions, mentre per gli Organization Roles e i Community Roles è possibile solo assegnare Portlet Permissions. I Portal Permissions coprono operazioni con estensione su tutto il Portale, ad es. all’interno di un Ruolo che ha la possibilità di creare nuove Communities; di contro i Portlet Permissions permettono di garantire operazioni all’interno soltanto delle portlet applications di pertinenza della Organization o Community all’interno delle quali tali portlet sono definiti.

19


Tornando all’esempio della creazione di un “Message Board Admin” Ruolo, è possibile selezionare lo scope dei permessi assegnati al ruolo. Se si sceglie quello di tipo Enterprise, allora le operazioni associate ai permessi possono essere effettuate su tutte le risorse Message Board del portale, altrimenti possono essere effettuate, se si sceglie ad es. lo scope Community, solo sulle Message Boards delle Communities selezionate. 3.6.

Modelli di autorizzazione

Riassumendo, le caratteristiche principali della versione più recente della piattaforma, possiamo affermare che, in aggiunta ai meccanismi gerarchici introdotti nelle ultime versioni che meglio ricalcano le reali organizzazioni aziendali e alla possibilità che uno User possa appartenere a più Organizations, i due punti che hanno determinato un cambiamento nel modo di attuare i meccanismi di autorizzazione e controllo sulle risorse sono: • •

la concessione di permessi e la determinazione dell’ambito di validità dei permessi è passato dalle risorse ai ruoli la concessione dei permessi è soltanto possibile attraverso i ruoli; cioè non è più possibile assegnare i permessi direttamente a Users, User Groups, Organizations e Communities.

L’introduzione di questi cambiamenti permette di ottenere politiche di autorizzazione di accesso alle risorse molto granulari e flessibili, ma allo stesso tempo più intuitive e di conseguenza meglio controllabili in fase di definizione. Purtroppo, data la scarsità di documentazione e di supporto ufficiale (limite questo comune a tutti i prodotti open-source) non è ancora possibile verificare la validità di tutte le nuove caratteristiche singolarmente ed in combinazione tra di loro. Ad esempio, non è stato possibile reperire lo schema del nuovo database di sistema, tramite il quale sarebbe stato più semplice trarre delle considerazioni generali sul sistema di autorizzazione e controllo implementato. Anche la comunità degli sviluppatori e degli installatori è principalmente concentrata sugli aspetti relativi all’upgrading di versioni del prodotto, di bugs e di system integration e non vi sono ancora contributi determinanti alla validazione degli aspetti di sicurezza dell’architettura. In linea di principio, la flessibilità e la finezza di granularità nell’assegnazione dei permessi non dovrebbe essere cambiata rispetto alle versioni precedenti ma, come abbiamo già evidenziato, resa più intuitiva e validabile. In considerazione di questi aspetti, gli esempi presentati nella successiva sezione prendono a riferimento la major version 4, per la quale esiste ricchezza di letteratura, esempi pratici e contributi vari da parte della comunità degli sviluppatori.

20


4. Esempi di configurazione In questa sezione vengono mostrati alcuni esempi su come modellare organizzazioni di complessità via via crescente utilizzando le nozioni di Organization e Location, facendo riferimento alla versione 4.3, cioè quella che ha introdotto la possibilità di modellare multi-livello. Verrà inizialmente presentato un organigramma che fa uso solo di Organizations e successivamente lo stesso farà uso di Locations. Per finire, sarà presentata una struttura più complessa, molto più aderente ad una tipica complessità aziendale. 4.1.

Organizzazione gerarchica semplice

Partiamo con un esempio semplificato di organizzazione aziendale (Figura 7). Volendo riflettere la struttura della compagnia in Liferay, possiamo creare una gerarchia di Organizations su cui vengono mappate le aree dell’organigramma. Ad ogni Organization vengono associati i rispettivi Users.

Figura 7. Gerarchia di Organizations •

Company ABC o Board: Bob  Sales: Anna  Engineering  Frontend: John  Backend: Barbara  Support 21


4.2.

Ereditarietà dei permessi

Vediamo adesso, una volta strutturata l’organizzazione, come assegnare i permessi agli Users in base alle Organizations cui appartengono. Assegnando un permesso o Ruolo ad un Organization, tutti i membri di quella Organization acquisiscono quel permesso o Ruolo. L’ereditarietà dei permessi lavora in maniera gerarchica. Se, ad esempio, alla Organization Engineering viene associato un Ruolo ad-hoc denominato ‘Engineer’, allora tale Ruolo verrà ereditato anche dagli Users John e Barbara che appartengono a Organizations di livello sottostante a quello dove il Ruolo è stato associato. La possibilità di definire permessi ricorsivi (recursability) da una Organization alle sue Children Organizations è spesso ciò che serve, ma non sempre. Dovendo scegliere se si vogliano o non si vogliano trasmettere i permessi ai membri delle Children Organizations, si agisce su un attributo, unico per ogni Organization, denominato 'Recursable permissions' che permette di implementare tale decisione. L’esempio mostra l’attivazione di una politica in cui la Organization Board non voglia trasmettere i propri permessi alle proprie Sub-Organizations. •

4.3.

Company ABC (Recursable permissions: Yes) o Board (Recursable permissions: NO)  Sales (Recursable permissions: Yes)  Engineering (Recursable permissions: Yes)  Frontend (Recursable permissions: Yes)  Backend (Recursable permissions: Yes)  Support (Recursable permissions: Yes) Locations all’interno di una gerarchia di Organizations

Immaginando che al passare del tempo la compagnia cresce nel numero delle sedi ma non nella struttura. Accanto alla sedi di Parigi vengono aperte le sedi di New York e Dalian, in Cina. Adesso vi sono dipendenti del dipartimento “Sales” che lavorano a Parigi ma anche a New York, così come vi sono dipendenti del dipartimento “Engineering” che lavorano sia a Parigi che a Dalian. Inoltre, si vuole che i dipendenti abbiano dei permessi speciali basati sulla sede di lavoro, in aggiunta a quelli derivanti dalla Organization di appartenenza. Per raggiungere gli obiettivi presentati nello scenario possiamo creare le seguenti Locations all’interno delle pre-esistenti Organizations. •

Company ABC o Location: Paris o Board  Sales  Location: New York  Engineering  Location: Dalian  Frontend  Backend  Support 22


In questa realizzazione è stata posta la Location “Paris” come direct child della Organization “Company ABC”, mentre le Locations “New York” e “Dalian” come children di “Sales” e “Engineering” rispettivamente. Adesso c’è soltanto da assegnare gli Users alle Locations, notando che è possibile assegnarli anche a Locations che sono associate a Organizations di livello gerarchico superiore (è questo il modo in cui posso avere ad esempio dipendenti di “Sales” sia a Parigi che a New York. Per ciascuno degli Users in esempio c’è la possibilità di avere: • • • •

Anna (Sales): New York o Paris John (Frontend, Engineering): Paris o Dalian Barbara (Backend, Engineering): Paris o Dalian Bob (Board): Paris

Una volta configurata la gerarchia, si possono assegnare gli utenti alla Location di appartenenza. Successivamente si possono assegnare i permessi per le risorse del portale alle Locations per controllare ciò che gli Users possono fare. Ciò che è importante è la possibilità di separare i permessi che provengono dall’appartenere ad una Organization da quelli che provengono dall’appartenere ad una Location della stessa Organization piuttosto che a un’altra, con grande facilità di riattribuzione di permessi per movimenti di dipendenti da una sede all’altra dello stesso dipartimento.

23


4.4.

Uno scenario complesso

Questa sezione presenta l’esempio di uno scenario complesso, estratto dal caso reale dell’agenzia non governativa Catalana COPCA che in realtà ha causato l’introduzione della possibilità di creare strutture gerarchiche multi-livello nella piattaforma. La figura 8 descrive i requisiti gerarchici della COPCA. La mappatura in Organizations e Locations e l’assegnazione degli Users ad essi è di facile realizzazione.

Figura 8. Lo scenario della COPCA

24


5. Altri aspetti legati alla Sicurezza Di seguito riportiamo altri caratteristiche della piattaforma riguardanti ulteriori aspetti della Sicurezza. Non verrà fatta una trattazione analitica sul significato di ognuno di loro, ma verrà soltanto data una mappa delle possibilità di utilizzo e/o di integrazione. 5.1.

Politiche di gestione delle password

La piattaforma presenta caratteristiche standard sulla gestione delle password, quali impostazioni sulla numero e tipologia di caratteri da usare, scadenza, ecc. Inoltre è possibile differenziare tali impostazioni per differenti insiemi di utenti. 5.2.

Autenticazione

E’ possibile realizzare autenticazioni e federazioni di identità con le utenze di navigazione, di backoffice e delle applicazioni integrate, presenti su directory accessibili tramite lo standard LDAP (Lightweight Directory Access Protocol), con meccanismi standard quali CAS Server, OpenID, OpenSSO. L’implementazione di meccanismi SSO (Single Sign-On) permette di fornire una singola credenziale di login per accedere in maniera sicura a contenuti ed applicazioni, anche per sistemi diversi che dovessero essere integrati al portale. Vediamo di seguito quali sono i principali meccanismi supportati. Central Authentication Service (CAS) CAS è un soluzione SSO open-source largamente usata creata all’Università di Yale. Il CAS Server richiede un certificato SSL (Secure Socket Layer) opportunamente configurato. Per ambienti pubblici, è necessario acquisire un chiave firmata da un’autorità terza certificata. OpenID Open ID è un nuovo standard SSO implementato da vari produttori. L’idea di fondo è che per tutti i sistemi provenienti da tali produttori, si possa registrare un unico ID con uno solo di tali produttori ed estenderne la validità delle credenziali ai sistemi degli altri. OpenSSO OpenSSO è una soluzione SSO open-source, proveniente da prodotti Sun. L’adozione di SSO permette di integrare la piattaforma in un’infrastruttura che contiene una moltitudine di vari schemi di autenticazione rispetto a differenti archivi di identità.

25


6. Considerazioni finali Attraverso la disamina evolutiva delle caratteristiche di sicurezza della piattaforma presa in esame, abbiamo potuto apprezzare come i requisiti via via crescenti, sia per ciò che riguarda la realizzazione di strutture di gruppi di utente allo stesso tempo gerarchiche e trasversali, sia per ciò che riguarda l’attuazione di un sistema di condivisione e di protezione di risorse, hanno portato ad una graduale riformulazione dei principi implementativi alla base del sistema di autorizzazione della piattaforma. Sia chiaro che lo scopo ultimo è sempre quello di mettere a disposizione un sistema quanto mai granulare ma facile da controllare, cioè si tende ad avere un sistema quanto più possibile simile ad una relazione ternaria tra soggetti, oggetti, operazioni con molteplicità N:M in tutte e tre le associazioni, ma che sia lineare possibile da gestire, leggero da implementare e nello stesso tempo robusto nel controllo dei permessi. Nella realtà, la progettazione di sistemi che siano in grado di fornire ad amministratore ed utenti queste caratteristiche deve fare i conti con i vincoli legati alle tecnologie e ai criteri progettuali utilizzati per implementare tali requisiti . Nella prima versione, ad esempio, in cui è stata messa a disposizione una notevole granulatà nella possibilità di attribuzione dei permessi, le modalità con cui questa poteva essere ottenuta sono concettualmente meno dirette rispetto alle successiva versioni. Difatti, partendo dal principio che erano le risorse del portale gli elementi a cui venivano attribuiti gli scopes, tale assunzione si rifletteva automaticamente sullo scope delle varie operazioni sulle risorse che uno User poteva effettuare. Considerando anche che, i permessi con scope Enterprise e Community, cioè applicabili a oggetti multipli di un stesso tipo di risorsa, erano concedibili solo tramite i Ruoli, come ultima indirezione di questo meccanismo si otteneva l’acquisizione degli scope da parte dei Ruoli. In sintesi: risorsa con scope  permesso con scope  Ruolo con scope. Un meccanismo un po’ contorto, ad onor del vero… Soltanto con la major version 5 si è transitato ad un’architettura in cui i permessi alle risorse vengono attribuiti solo attraverso i Ruoli; l’aspetto più rilevante è che ad ogni Ruolo viene direttamente attribuito uno scope, e non tramite il meccanismo di indirezione delle precedenti versioni. In questo modo diventa probabilmente più intuitivo comprendere l’ambito di applicabilità dei permessi sulle risorse, mentre, per ciò che riguarda la granularità dei permessi, non ci sono cambiamenti sostanziali rispetto alla precedente architettura. Conseguentemente lo stesso tipo di oggetto, essendo la risorsa adesso svincolata dal concetto di scope, può essere definito e usato attraverso tutto il portale. Riguardo all'adozione delle astrazione insiemistiche quali classe di oggetti, tipi di diritti di accesso, ruoli, così come specificati in [3], possiamo affermare che la piattaforma Liferay Portal usa dei meccanismi diversi che tengono conto del concetto di scope.

26


Gli oggetti non vengono in prima istanza raggruppati in classi, definite come insiemi di oggetti su cui vengono effettuate le stesse operazioni, ma solo sulle loro proprietà caratteristiche. In precedenti versioni veniva loro assegnato, come già detto, l'attributo scope. Anche il concetto di Ruolo, benché definito come insieme di operazione definibili su una risorsa e non come gruppo di utenti, non presenta la possibilità che gli vengano assegnati i permessi tramite i tipi di diritto di accesso, e quindi non hanno nomi riusabili per oggetti di classi diverse, dal momento che non esistono le classi di oggetti secondo [1]. Viene invece attribuito direttamente, nelle versioni più recenti, il concetto di scope ai Ruoli, che permette di attribuire gli stessi nomi a ruoli definiti in ambiti diversi (portale, organizzazione, comunità). Per ciò che riguarda i concetti di raggruppamenti e di condivisione di spazi, la piattaforma adotta principalmente un modello gerarchico ad albero (Organizations), con la possibilità di inibire l'ereditarietà degli permessi agli affiliati spazi sottostanti. Allo scopo di poter ottenere raggruppamenti e spazi trasversali si utilizzano le Communities che sono organizzate indipendentemente dalle Organizations, ma possono contenerle.

27


7. Bibliografia e riferimenti [1] “G. Scollo” – Modelli di autorizzazione negli ambienti di collaborazione” – 2002 http://www.ippari.unict.it/~scollo/slidy/s1-2009/gss1_l14/it/gss1_l14n.pdf [2] “C. Pfleeger, S. Pfleeger”: Sicurezza in informatica – Pearson 1a ed. italiana – 2004 [3] “D. Gollmann” – Computer Security 2nd Edition - John Wiley & Sons [4] http://it.wikipedia.org/wiki/Portlet [5] http://forum.tgmonline.it/showthread.php?t=112944 [6] “P. Congiustì“: Java Portlet - HTML.it – 17/11/08 http://java.html.it/articoli/leggi/2871/java-portlet/1/ [7] “G. Politi”: Portlet API - MokaByte 117 - Aprile 2007 http://www2.mokabyte.it/cms/article.run?articleId=GX9-6F1-PN4FTM_7f000001_28844331_dc1650b4 [8] http://www.liferay.com/web/guest/products/portal/features [9] http://www.liferay.com/web/guest/community/documentation/5_2 [10] http://docs.liferay.com/portal/5.2/official/liferay-administration-guide.pdf [11] http://docs.liferay.com/portal/4.3/official/liferay-administration-guide-4.3.pdf [12] http://docs.liferay.com/portal/4.0/official/liferay-user-guide-4.0.pdf [13] http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Permissioning+Explained [14] http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Hierarchical Organizations [15] http://www.liferay.com/Web/guest/community/forums [16] http://wiki.liferay.com/index.php/Main_Page [17] http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/Working+with+Organizations+and +Locations [18] “Liferay - Manuale Configurazione AIP” – JobNet S.p.A. [19] “SIDIPA – Manuale utente” – UG Group s.r.l.

28


Indice generale Introduzione..........................................................................................................................................2 Portali e portlet.....................................................................................................................................3 Portlet e servlet............................................................................................................................3 Architettura software dei portlet container.................................................................................4 Modelli gerarchici e politiche di condivisione e autorizzazione..........................................................7 Liferay Portal v4.0......................................................................................................................7 Definizione delle entità......................................................................................................7 Assegnazione dei permessi alle risorse............................................................................11 Liferay Portal v4.3 ...................................................................................................................13 Liferay Portal v4.4....................................................................................................................14 Memorizzazione dei permessi nel Database....................................................................14 Liferay Portal v5.2....................................................................................................................16 Architettura delle entità del Portale.................................................................................16 Assegnazione di permessi alle entità del Portale......................................................................18 Modelli di autorizzazione .........................................................................................................20 Esempi di configurazione...................................................................................................................21 Organizzazione gerarchica semplice.........................................................................................21 Ereditarietà dei permessi...........................................................................................................22 Locations all’interno di una gerarchia di Organizations...........................................................22 Uno scenario complesso ...........................................................................................................24 Altri aspetti legati alla Sicurezza........................................................................................................25 Politiche di gestione delle password.........................................................................................25 Autenticazione..........................................................................................................................25 Considerazioni finali..........................................................................................................................26 Bibliografia e riferimenti....................................................................................................................28

29


Primato