Un CMS orientato alla pubblicazione web organizza tutte le fasi del ciclo vitale di un contenuto, dalla creazione (o dalla sua acquisizione da fonte esterna) alla rimozione, passando attraverso quelle che possono essere successive versioni dello stesso documento che possono a loro volta essere sottoposte alla approvazione di un supervisore che deve potervi apportare modifiche o aggiungere commenti e notazioni. Uno degli standard che più si sta diffondendo nei CMS in questo senso è WebDAV (Web Distribuited Autoring and Versioning), un set di protocolli HTTP che permette agli utenti di editare e gestire files su server web remoti. Qualsiasi client WedDAV può essere utilizzato per la connessione al server CMS e eseguire i metodi previsti, per il ruolo in base al quale si autentica, con il protocollo WebDAV che fornisce poi attraverso l'interfaccia utente del CMS le possibilità di lavorare sui relativi files.
Ma vediamo nello specifico quali sono i modi con cui un CMS può reperire i contenuti di cui terrà traccia:

CREAZIONE: un contenuto viene creato da zero e caricato nel database del CMS, il sistema si occupa anche della creazione e dello stoccaggio dei relativi metadati, in maniera automatica oppure personalizzabile.
ACQUISIZIONE: un contenuto viene rintracciato da fonti esterne al sistema di gestione, quali possono essere database o filesystem remoti ed acquisito come contenuto pronto per essere presentato.
CONVERSIONE: un contenuto acquisito o creato viene modificato nella sua struttura (ad esempio convertito in XML) per poter essere utilizzato dal sistema.
AGGREGAZIONE: un contenuto già in memoria viene suddiviso o aggregato ad altri contenuti per essere più facilmente gestibile con il sistema di metadati in uso.

Il CMS quindi fornisce la possibilità di creare contenuti dal nulla, di cambiarne di esistenti, di modificarne la visualizzazione, di disporli automaticamente nella corretta strutturazione logica attraverso l'utilizzo di template (it. mascherina). Deve inotre dare l'accesso alle persone indicate per lavorare sui vari file nelle maniere indicate, impedendo a chi non ne ha il diritto di intervenire dove intervenire non deve. Questi obiettivi vengono raggiunti attraverso l'implementazione di alcuni concetti chiave: il flusso di lavoro, ovvero come è strutturalmente organizzato il processo di gestione dei contenuti e il loro stato all'interno del sistema; e l'amministrazione della sicurezza che assicura la protezione delle informazioni e l'agibilità degli spazi digitali a chi se ne vede assegnato il diritto.
Vediamo ora più in dettaglio cosa sono queste due aree gestionali del CMS e come funzionano assieme ad alcuni esempi pratici tratti da  CMS attualmente sul mercato.

Il flusso di lavoro è una catena di azioni o di eventi di cui si ha bisogno per raggiungere un obbiettivo. Il flusso di lavoro spesso esprime il processo attraverso il quale si concretizza la realizzazione di un determinato business.

Ogni business ha le sue regole e un esempio di queste potrebbe includere:

• Prima che un documento di un dipendente sia diffuso esso deve essere visto ed approvato da un revisore.

• In una fabbrica di macchine utensili, per ogni macchina da assemblare l’ordine deve essere notificato e ogni cambiamento nello stato dell’assemblamento deve passare dalle strutture della fabbrica.

• Prima che una pagina Web sia pubblicata essa deve essere approvata dagli uomini del marketing, approvata dal web master ed eventualmente tradotta da un traduttore.

Il flusso di lavora organizza logicamente la catena di produzione e definisce il modello da seguire per la realizzazione di un prodotto o la fornitura di un servizio. Dal momento che esiste un’organizzazione logica dei compiti e dei passi necessari è più facile programmare dei cambiamenti o creare nuove strutture concettuali per rafforzare l’ efficacia del processo stesso.

Per cominciare introdurremo due termini: stato e transizione.

Uno stato è un’ informazione su una unità di contenuto in un dato momento. Esempi di stato sono: bozza, da visionare, non visibile e pubblicato. Ogni flusso di lavoro ha almeno uno stato iniziale dal quale tutti i contenuti partono, essi passeranno poi attraverso un certo numero di stati differenti nei quali saranno modificati fino allo stato finale. Nel caso dei CMS gli stati che possono essere considerati finali sono più d’uno a secondo della natura e della finalità dei documenti.

Per ogni unità di informazione che passa da uno stato ad un altro c’è bisogno di una transizione. Una transizione collega uno stato di partenza con uno di arrivo. Ogni transizione può comportare un gran numero di cambiamenti ma comunque essa muove un documento da uno stato ad un altro. Di solito una transizione avviene in seguito a una azione dall’esterno, ad esempio un click di un utente autorizzato.

Per visualizzare meglio il concetto riproporremo qui di seguito l’ esempio che Andy McKay usa nella sua “The definitive guide to Plone”¹ come introduzione all’argomento: il bollettino di pagamento delle carte di credito. (Andy McKay, The definitive Guide Plone, Berkeley, Apresse, 2004, cap. VIII, pp. 2-4.)

1. La banca prepara il bollettino e lo invia al mio domicilio.

2. Ritiro il bollettino e lo pongo sulla mia scrivania. Può succedere abbia dei dubbi su alcune delle voci di spesa e così faccio delle richieste di chiarimento alla banca.

3. Presento alla banca i miei dubbi che a volte possono rendere necessario l’invio di un nuovo bollettino o che vengono risolti in altra maniera.

4. Alla fine del mese saldo il debito da me contratto in precedenza.

Gli stati di questa situazione sono così riassumibili:

• Bozza: il bollettino è stato preparato e mi è stato inviato.

• Revisione: ho ricevuto il bollettino e lo sto esaminando.

• Pagato: il bollettino è stato saldato ed archiviato.

Individuati gli stati occupiamoci ora delle transizioni del caso:

• Spedizione: la banca mi invia il bollettino.

• Pagamento: il bollettino viene pagato.

• Chiarimento: nel bollettino c’è qualcosa di poco chiaro e per questo viene rinviato alla banca per chiarimenti

Il flusso di lavoro di questo processo è quindi visualizzabile attraverso il seguente diagramma:

Una volta esplicitato il processo per il pagamento dei bollettini in un flusso di lavoro, il passo successivo è l’ organizzazione dei ruoli per la sicurezza dei pagamenti. Per adesso questo flusso di lavoro contiene la struttura logica per una applicazione che si occupa del pagamento dei bollettini.
In qualsiasi sistema complesso ci sono utenti, ruoli e gruppi. Questo metodo organizzativo consente ai CMS di gestire in maniera flessibile la sicurezza anche in presenza di comunità di utenti molto numerose e diversificate al loro interno.
Quando un contenuto viene trasformato dal flusso di lavoro da uno stato a quello successivo possono variare anche le impostazioni della sicurezza e le regole di accesso.


Tornando all’ esempio dei bollettini bancari vediamo di ricavarne le possibili regole riguardo alla sicurezza del processo:

Figura 3.2. Le transizioni e le entità che possono attivarle

Da questa prospettiva sono chiare le transizioni e chi può renderle effettive. Non è però chiaro che tipo di accesso ognuna di queste entità effettuerà per compiere le azioni necessarie ad ogni transizione. Per esempio quand’ è che la banca emette il bollettino e quando può essere visionato?
Se solo io ho la possibilità di fare addebiti con la mia carta di credito, la banca senz’ altro può in ogni momento controllarne l’entità e eventualmente fornirmi chiarimenti a riguardo.
Vediamo quindi la tabella in figura 3.3 aggiornata sul tipo di accesso che le entità in questione hanno sul mio bollettino:

Stato	Debitore	Proprietario
Bozza		Spedire, vedere, emettere
Revisione	Pagare, chiedere pagamenti, vedere	vedere
Pagato	vedere	vedere

Figura 3.3. Entità e possibilità di accesso.

Com’ è evidente io non posso emettere il bollettino, solo la banca può. In questa situazione è la banca che è la proprietaria del bollettino. Questa è la dimostrazione pratica del concetto di proprietà digitale di un contenuto: sono il proprietario di una informazione quando le impostazioni della sicurezza mi danno la possibilità di crearla.

Se combiniamo transizioni e azioni con le entità e i ruoli la tabella avrà l’ aspetto seguente:

schema4

Anche se questo esempio è piuttosto forzato illustra un’ applicazione di base del flusso di lavoro.

Tornando ai CMS è importante che un amministratore possa assegnare ruoli diversi a utenti diversi, distribuendo a seconda delle necessità i diritti di accesso in modo da regolare la pubblicazione dei contenuti e la loro modifica.

A grandi linee questi ruoli possono essere raggruppati nella maniera seguente:

i CMS è importante che un amministratore possa assegnare ruoli diversi a utenti diversi, distribuendo a seconda delle necessità i diritti di accesso in modo da regolare la pubblicazione dei contenuti e la loro modifica.

A grandi linee questi ruoli possono essere raggruppati nella maniera seguente:

• Utente anonimo. Non viene assegnato dall’ amministratore, è chiunque navighi nel sito e può soltanto vedere i contenuti espressamente pubblicati e visibili.

• Utente autenticato. Viene riconosciuto dal sistema attraverso un nome utente e una password.

• Editor. È un utente autenticato che ha la possibilità di creare contenuti o contribuire alla elaborazione di quelli esistenti in specifiche aree del sito alle quali ha accesso, ma non ha la possibilità di pubblicare direttamente i documenti editati che deve invece sottoporre al revisore.

• Revisore. È un utente a cui i contenuti vanno inviati affinché vengano rivisti ed approvati per la pubblicazione oppure rimandati al mittente per eventuali modifiche. Tipicamente questo gruppo di utenti comprende i responsabili dei vari dipartimenti.

• Pubblisher. Chi è responsabile della pubblicazione definiva e che rende attivo questo stato.

• Amministratore. Questo utente è responsabile del sistema. È l’ amministratore che assegna ruoli e permessi ed ha accesso a qualsiasi documento. Possono esserci diversi livelli anche per gli amministratori che possono avere delle restrizioni a seconda delle sezioni del sito.

Introduciamo quindi dopo le entità attive all’ interno di un CMS un modello di macchina a stati che si occupa della gestione dei contenuti e che prende in esame flusso di lavoro potenziale tra l’ editor di un documento, il revisore e gli stati di visibile, privato, da rivedere e pubblico.

La figura 3.5 mostra i principali stati e le principali transizioni necessarie per la gestione delle informazioni attraverso un CMS. La linea punteggiata rappresenta una sorta di divisione che sono le impostazioni della sicurezza, alla destra della linea il revisore interagisce con i contenuti. Ogni contenuto può e deve avere soltanto un proprietario ovvero l’ utente che ne è l’autore.

Ora possiamo, proprio come per i bollettini bancari, associare le entità con le azioni e con i permessi in modo da esplicitare i ruoli all’interno del flusso di lavoro.

schema6

Quando un contenuto è stato pubblicato solo il Pubblisher ha la possibilità di ritirarlo e di modificarne il contenuto, il revisore si occupa invece di visionare le bozze che i proprietari propongono per la pubblicazione che se approvate vengono a loro volta passate al Pubblisher che ne rende operativa la pubblicazione.

Come abbiamo visto un flusso di lavoro di un CMS si occupa quindi di gestire in maniera standardizzata ed automatica i contenuti che una organizzazione produce al suo interno come quelli che possono giungerle dall’ esterno, la condizione sufficiente e necessaria è che l’ amministratore assegni ai vari utenti un ruolo nel sistema.

Una entità che non è stata presa per ora in esame è quella di membro di un gruppo. Per il lavoro collaborativo è necessario che i membri di un dipartimento possano intervenire su documenti che pur non essendo strettamente di contenuti digitali sono evidenti e sono stati trattati in precedenza. privati, ovvero accessibili al solo proprietario, non possono nemmeno essere visibili a tutti, la risposta che i CMS danno a questa necessità è la creazione dei gruppi. L’ amministratore può dare la possibilità di creare documenti in uno stato intermedio tra visibile e privato e cioè visibile soltanto ai membri di uno stesso gruppo.

L’ architettura del web non è stata progettata tenendo conto di considerazioni sulla sicurezza, se si esclude il fatto che è una rete decentralizzata a pacchetti progettata per funzionare pur se spezzettata da un attacco nucleare.
Inoltre la prima comunità virtuale è stata formata da ricercatori e studenti, l’ approccio era comunitario e si assumeva che le persone fossero quel che dicevano di essere, nessuno si preoccupava di danni deliberati. Dal momento che oggi la rete è una attività commerciale, ogni sorta di azioni di motivi per commettere azioni prima impensabili è divenuta attuale , ed è necessario mettere in atto serie misure di sicurezza – dagli strati più bassi a quelli più alti dei sistemi – per impedire questo genere di azioni abbiano successo.
Se i documenti di una organizzazione sono gestiti in modo centralizzato e si trovano quindi all’ interno di uno stesso spazio concettuale (il CMS) anche se distribuiti su più server, è necessario che questo spazio si rigidamente compartimentato per assicurare la sicurezza dei dati sensibili e il rispetto della privacy a termini di legge.
Vediamo ora come viene risolto di norma questo problema dai sistemi di gestione dei contenuti.

Ruoli e permessi regolano in pratica la possibilità di accesso dei diversi utenti ai contenuti e alle informazioni presenti nel sito, come accennato nel capitolo sul flusso di lavoro.
Vediamo ora un possibile esempio pratico di implementazione dei ruoli e quali possono essere, al di là della creazione  e pubblicazione dei documenti, le funzionalità critiche di un CMS e come è possibile gestirle

I ruoli ed i permessi sono di solitamente contenuti in una ACL ( Access Control List ). Le ACL sono un modello di gestione della sicurezza che specifica chi può fare cosain un determinato sistema. Se una entità ha il permesso verso un determinato oggetto allora ha anche la possibilità di intervenire e modificare od eseguire tale oggetto.

È poi possibile ulteriormente espandere il modello Access-Control dal lato dei permessi in alcune importanti direzioni:

• Ruoli

• Acquisizioni

• Proprietà

• Ruoli locali

Stabilendo dei permessi per i ruoli e definendo il ruolo di un utente si impostano direttamente i parametri della sicurezza per le diverse famiglie di utenti suddivisi a seconda delle necessità degli amministratori.

Un ruolo va associato ad un utente del sistema. Vediamo ora di esemplificare quali possono essere.

MANAGER: ha la possibilità di effettuare tutte le azioni possibili per defoult., la sua funzione è quella di intervenire e gestire qualunque parte del sito, ha la supervisione sul funzionamento del CMS, può modificarne gli stati.

PROPRIETARIO: è forse il ruolo più importante per la sicurezza dei CMS. È l’ utente che ha creato un oggetto e che può in qualsiasi situazione modificarlo ed eseguirlo.

Dal punto di vista di possibili attacchi o danni al sistema è importante che un utente che accede ad un oggetto che aziona una modifica dello stato corrente possa determinare effettivamente questo cambiamento soltanto se sia l’ utente che il proprietario dell’ oggetto hanno il prerequisito Permesso.

Questa importante impostazione impedisce quelli che vengono chiamati attacchi server-side trojan, possibili quando un utente malicious ha la possibilità di creare sul server del codice eseguibile.

Fondamentalmente questo tipo di attacco presenta il seguente scenario:

1. Un utente malicious crea sul server del codice eseguibile che tenta di di effettuare un’ azione per la quale l’utente non ha i permessi (ad esempio cancellare un folder nella directory di root sul server).

2. L’ utente malicious induce qualcuno che abbia i permessi, ad esempio il proprietario del sito, a visitare la pagina con il codice maligno.

3. Se il codice ha come unica restrizione quella del permesso dell’utente autenticato in quel momento (in questo caso il manager) il codice va in esecuzione e l’attacco ha esito positivo.

È quindi molto importante che per evitare questo e altri tipi di attacco i permessi relativi a codice eseguibile siano gestiti dal sistema e dall’ amministratore in maniera consapevole, un buon compromesso può essere quello di considerare come restricted il codice editato via web e mai concedergli l’accesso al filesystem locale.

D’ altro canto codice creato ad hoc per i più svariati utilizzi deve potervi accedere e in ogni caso una volta pubblicato non ci sono più restrizioni, potenzialmente utenti del CMS potrebbero accedere a tutte le risorse del sistema disponibili con cui il CMS è interfacciato, ma nella maggior parte dei casi questa è più una risorsa che un problema dove i permessi sono impostati correttamente.

L’ UTENTE AUTENTICATO: è qualunque navigatore sia in possesso di una coppia valida username-password. Solitamente per defoult non ha permessi associati al proprio ruolo.

L’ UTENTE ANONIMO: è qualunque navigatore visiti le pagine pubblicate del sito. Conferire permessi a questa categoria di utenti significa conferirli a tutte le altre categorie (a meno di non negarle espressamente nella Access-Control-List).

Nei CMS i ruoli locali vengono usati per garantire dei permessi a determinati utenti in specifiche sottosezioni del sito.

Uno dei modi standard di utilizzarli è quello di dare il ruolo di proprietario a chi crea un oggetto limitatamente all’ oggetto creato e alla sua posizione corrente al di fuori della quale il roulo proprietario non è più valido.

Come esempio ipotizziamo che nella sezione /Prodotti del sito sia contenuta della documentazione che tutti devono poter vedere ma che pochi possono modificare. In questo caso le impostazioni di defoult dovrebbero già garantire una efficace soluzione: tutti possono accedere alle informazioni pubblicate, solo il proprietario o il manager locale editarle.

Al contrario nella sezione accounting che contiene informazioni più delicate c'è la necessità che gli accessi siano più regolati e che soltanto alcuni operatori del dipartimanto abbiano i permessi necessari a visualizzare e/o modificare la cartella. Questa soluzione può essere semplicemente implementata disattivando l'opzione acquisizione o ereditarietà (a seconda dei CMS) dei permessi relativi al folder /Accounting. In questo modo nella cartella i ruoli validi nel resto del sito non sono più validi e ne vanno creati ad hoc per questa sottosezione.

I singoli utenti del sistema possono essere uniti secondo le necessità in gruppi. Un gruppo serve a creare uno spazio di lavoro condiviso dagli appartenenti ad uno stesso dipartimento ad esempio, viene creato il gruppo MARKETING e tutti gli utenti del sistema che rientrano in tale gruppo avranno il permesso di di aggiungere, editare e rimuovere contenuti nel relativo spazio di lavoro.

Il meccanismo è in pratica lo stesso usato per creare i ruoli locali, solo viene implementato più semplicemente e velocemente dal CMS.

Di seguito mostriamo quale può essere un'interfaccia per la amministrazione dei gruppi basata su tool visuali.

Può anche tornare utile assegnare dei ruoli direttamente ai gruppi. Se questo può sembrare strano basta immaginare il caso in cui ci fosse bisogno di organizzare un gruppo di revisori che si occupino della pubblicazione dei documenti pendenti degli altri dipartimenti. Per fare ciò è sufficiente assegnare direttamente ad un gruppo creato per lo scopo (gruppo Supervisori) il ruolo di REVISORE, d'ora in poi tutti gli attuali e futuri appartenenti a Supervisori avranno la facoltà di editare e pubblicare le bozze proposte dagli altri utenti. Anche in questo caso si fa un uso allargato dei ruoli locali tenendo conto che i meccanismi di sicurezza quando controllano i permessi di un utente vanno prima a vedere i permessi dell'utente e subito dopo quelli del gruppo cui appartiene.

In molte situazioni è necessario interfacciare il CMS con altri software già in uso come server di identificazione e database o assegnare permessi particolari in modo automatico per utenti apparteneti a determinati domini, ecco una breve lista delle soluzioni possibili.

AUTENTICATORI VERSO I DATABASE

Per essere in grado di autenticare gli utenti registrati nel DB e sfuttare le informazioni gia registrate in esso il CMS deve poter interagire con i più di diffusi database:

• MySQL

• PostgreeSQL

• Microsoft SQL Server

• Oracle

• Sybase

• Altri

In Questo modo gli utenti già registrati sul DB avranno acceso al sito e il CMS potrà aggiungere o eliminare utenti, recuperarne i dati personali o quantaltro con una query SQL e visualizzarne il contenuto.

AUTENTICATORI SSL

Utilizzano di norma il client SSLv3 per l'autenticazione

AUTENTICATORI NT

Servono per regolare gli accessi al CMS attraverso le impostazion i valide all'interno di domini Windows/NT.

AUTENTICATORI SMB

Hanno la stessa funzione di quelli NT ma per piattaforme diverse da Windows.

AUTENTICATORI /etc Users

Gestiscono gli accessi da domini Unix-Linux.

AUTENTICATORI LDAP E GESTIONE LDAP DEGLI UTENTI

Consentono al CMS di registrare sul server nuovi utenti e di dare l'accesso a quelli già registrati sul server LDAP in conformità con le regole in esso impostate.