Dal punto di vista implementativo, openDCN è costituito da moduli dotati di un insieme di azioni tramite le quali gli altri moduli o l’utente esterno interagiscono con essi.
L’esecuzione di ciascuna azione è però condizionata dal possesso da parte del richiedente del permesso per eseguirla.
Risulta quindi in pratica impossibile utilizzare un modulo senza prima averne definito i permessi di accesso, dato che il comportamento automatico di ogni modulo è quello di non eseguire l’azione specificata.
Si ottiene così flessibilità e al tempo stesso sicurezza nel funzionamento del sistema.
Lo schema secondo il quale vengono definiti i permessi è:
<soggetto> <azione> <oggetto> <peso>
dove tipicamente:
<soggetto> è un utente o un gruppo <azione> è l’azione che il soggetto richiede al modulo di svolgere <oggetto> è l’elemento sul quale il modulo agisce (ad esempio un contenuto da visualizzare) <peso> determina una priorità in caso i permessi siano in contrasto come, ad esempio, la presenza di un permesso di scrittura ad un utente e la negazione dello stesso al gruppo a cui appartiene.
L’insieme dei permessi, attribuiti direttamente (nel caso di un utente o un gruppo) o indirettamente (nel caso di un utente che appartenga ad uno o più gruppi), determina il Ruolo che quel soggetto ricopre rispetto a quell’oggetto.
Nel caso in cui il soggetto sia un utente, il Ruolo rispetto ad un oggetto può essere determinato indirettamente dall’appartenenza ad uno o più gruppi con permessi sul medesimo oggetto.
In questo caso infatti l’utente risulta essere in possesso dell’unione di tutti i permessi: quelli attribuitigli direttamente e quelli derivanti dai gruppi. In caso di contraddizioni il permesso risultante viene determinato in base al peso.
Non esistono quindi Ruoli predefiniti nel sistema ed è possibile creare dinamicamente i Ruoli che meglio rispondono alle esigenze di gestione semplicemente modificando l’insieme di permessi attribuiti ad un soggetto.
Al tempo stesso, per agevolare la gestione e la configurazione del sistema anche ad un Amministratore inesperto, il sistema “nasce” dotato di alcuni Ruoli preconfigurati che corrispondono ad un utilizzo “sensato” e accorto del sistema. Si tratta però esclusivamente di una configurazione iniziale che può essere modificata con lo stesso meccanismo con cui si gestiscono i nuovi Ruoli.
Esempio di ruolo/permessi:
Utente ‘Pippo’, appartiene al gruppo ‘Utenti Generici’:
Pippo ha tutti i permessi che l’amministratore ha definito per il gruppo utenti generici (a cui appartiene), tuttavia l’amministratore può decidere che Pippo ha, all’interno di un modulo (uno o più) dei permessi in più o in meno rispetto al suo gruppo di appartenenza.
Ecco quindi che Pippo può, ad esempio, all’interno di un modulo, visualizzare o modificare contenuti che gli altri Utenti Generici non possono fare o, viceversa, gli viene negata questa possibilità rispetto ai suoi compagni del gruppo cui appartiene.
In generale, per ogni modulo (agenda, blockset, content etc…) lo schema della gestione dei permessi comprende il soggetto (utente), il ruolo, il peso e le varie azioni che lo stesso utente può compiere.
A seconda del modulo ci sono varie azioni (view, edit, delete, download etc…).
È sempre possibile creare nuovi permessi e nuovi ruoli all’interno dei moduli.