La seguente guida descrive sinteticamente l'architettura del sistema di sicurezza di SOMA, da ora in poi indicato con l'acronimo S.S.S. (Soma Security System), e fornisce una guida alla configurazione di esso.
SOMA (Secure Open Mobile Agents) è l'infrastruttura per Agenti Mobili sviluppata dall'università di Bologna; per avere maggiori informazioni su questo progetto si rimanda a http://www.lia.deis.unibo.it/Research/SOMA/ .
Implementare un meccanismo di sicurezza per un sistema ad Agenti Mobili pone problemi di diversa natura sintetizzabili nei seguenti punti:
è necessario proteggere l'agente da ambienti di esecuzione potenzialmente ostili
è necessario proteggere l'ambiente di esecuzione da agenti potenzialmente ostili
l'interazione con il sistema deve essere regolato
Vista l'intrinseca complessità del problema è scaturito un sistema molto complesso, la cui gestione presuppone la conoscenza dell'architettura e di un insieme di strumenti (server ldap, PKI, ..); da questo la necessità della presente guida la cui lettura è fortemente consigliata.
role based policies |
Il Soma Security System permette di imporre una generica
politica di sicurezza attraverso un paradigma basato sui ruoli.
Questo significa che l'insieme dei permessi non viene legato ad un
particolare utente, ma viene legato ad un ruolo; gli
utenti sono poi legati ad uno o più ruoli e le
azioni da esso compiute vengono gestite nel dominio di sicurezza
del ruolo dall'utente ricoperto. |
JAVA |
L'intero sistema SOMA è sviluppato in JAVA! Questo ha
permesso di utilizzare i sofisticati e robusti meccanismi di
sicurezza che JAVA offre. |
PKI Entrust |
L'autenticazione degli utenti avviente attraverso l'uso di certificati digitali il cui ciclo di vita è gestito dalla PKI Entrust. I certificati vengono utilizzati anche per altri scopi come indicato dai punti successivi. |
L'ambiente di esecuzione è protetto |
Gli agenti possono interagire con il sistema attraverso un insieme di API progettato per garantire che un agente ostile non possa danneggiare il sistema. |
Gli agenti sono protetti |
L'integrità degli agenti è assicurato attraverso l'uso di certificati digitali. |
E' assicurata la non ripudiabilità delle azioni |
Gli agenti sono firmati digitalmente dall'utente che li ha lanciati. E' così sempre possibile risalire al responsabile di una determinata azione. |
Interazione con SOMA |
Il sistema di sicurezza impone agli agenti una politicha di sicurezza in funzione del ruolo di chi li ha lanciati; ma non si limita a questo. Un generico utente interagisce con SOMA potendo utilizzare, in generale, solo un sottoinsieme dei comandi possibili. L'insieme dei comandi ammessi per un ruolo viene specificato in modo coerente al modo in cui vengono accordati tutti gli altri permessi. |
Alte performances |
Il S.S.S. è molto efficiente! Per assicurare la scalabilità si fa largo ricorso, come in tutto il sistema SOMA, alla definizione di località. |
La seguente figura mostra un security domain e le entità che lo definiscono.
La figura mostra il caso in cui un security domain contiene tre SOMA domains e alcuni places. Sono anche indicati il server ldap e la PKI. Il server ldap è forse il sottosistema più importante dal punto di vista dell'amministratore. Esso infatti è responsabile di mantenere le seguenti informazioni:
utenti registrati nel security domain
bindings utente-ruoli
i ruoli e le gerarchie dei ruoli
politiche
In più il server ldap definisce il security domain; infatti ogni istanza di SOMA viene lanciata indicando la URL del server ldap il quale è in corrispondenza 1:1 con i security domains; così affinchè un SOMA domain appartenga ad un security domain è necessario e sufficiente che l'infrastruttura SOMA che lo definisce faccia riferimento al server ldap corrispondente.
Nel S.S.S. la politica di sicurezza è qualcosa di più di un elenco di permessi associati ad utenti. E' necessario definire una struttura dati che definisca l'insieme delle informazioni necessarie al sistema. Le seguente figura mostra schematicamente come è strutturata l'informazione:
La figura mostra lo schema del Directory Information Tree. I quadrati rappresentano classi di oggetti mentre i cerchi rappresentano un esempio di possibili istanze. In particolare le istanze delle classi roles e users sono singleton, nel senso che esiste in ogni directory una sola istanza di esse.
Come è possibile osservare, esiste un dominio fittizio
denominato "default". Per comprendere il motivo di ciò,
è necessario chiarire come viene gestita l'interazione con il
sistema. Tipicamente una sessione di SOMA si presenta all'utente con
diverse finestre. Tra queste ci sono quelle legate ai domini e
ai places, ma ci sono anche alcune finestre che non sono
legate ad una particolare località; per esempio la finestra di
configurazione avanzata.
Durante l'interazione con finestre
collegate ad una particolare località L, i comandi impartiti
dall'utente vengono, prima di essere messi in esecuzione,
controllati, nel senso che viene consultata la politica attiva nella
località L per assicurarsi che il ruolo attivo ha il
permesso di compiere l'azione corrispondente. Ovviamente nel caso in
cui il controllo non va a buon esito il comando non viene messo in
esecuzione.
Durante l'interazione con finestre non collegate ad
una particolare località tutto avviene come prima, con l'unica
differenza che la politica che viene consultata è quella
collegata al dominio fittizio "default".
Ogni oggetto è caratterizzato da
attributi che sono elencati nella seguente tabella:
ROLE |
role |
identificatore del ruolo |
description |
descrizione del ruolo |
|
java_class |
classe java che definisce il ruolo |
|
DC |
certificato digitale di ruolo |
|
ROLES |
serial_number |
è il numero seriale della politica. E' utilizzato dal meccanismo di cache e deve essere cambiato ogni volta che viene modificata la politica per forzare un aggiornamento |
id |
è l'identificatore del singleton |
|
USER |
cn |
common name dell'utente |
sn |
nome completo dell'utente (opzionale) |
|
entrust_dn |
è il DN incapsulato nel certificato digitale dell'utente |
|
role |
ruoli che l'utente può ricoprire |
|
|
indirizzo di posta elettronica dell'utente (opzionale) |
|
USERS |
id |
è l'identificatore del singleton |
DOMAIN |
domain |
è il nome del dominio |
description |
descrizione del dominio (opzionale) |
|
policy |
politica valida in tutti i place del dominio (dati codificati in base64) |
|
PLACE |
place |
è il nome del place |
description |
descrizione del place (opzionale) |
|
policy |
politica valida in questo place (dati codificati in base64) |
|
Nella sezione configurare il server ldap vengono mostrati i passi necessari per mantenere questa struttura in un server ldap e un esempio completo.
Come è possibile osservare gli utenti e i ruoli sono
definiti al livello del security domain.
Le politiche
vengono definite a livello di SOMA domain e SOMA places.
Osservazione: l'oggetto role ha un attributo binario di nome DC, il cui valore unico rappresenta il certificato digitale di ruolo. Per estrarre il certificato digitale da un profilo Entrust è stato sviluppato il programma
SOMA.security.ldapauth.bindRoleDC
che accetta i seguenti argomenti: URL server ldap, file profilo, password profilo, nome ruolo. Per esempio:
java SOMA.security.ldapauth.bindRoleDC ldap://127.0.0.1 /profili/andrea secret student
lega all'oggetto role di nome student residente nel server ldap dell'host locale, il certificato digitale incapsulato nel profilo Entrust /profili/andrea che è protetto dalla password secret.
Definire
la gerarchia dei ruoli
Gli oggetti ROLES hanno un attributo binario denominato
java_class. Per definire le gerarchie si è scelto di
utilizzare il linguaggio java come un linguaggio di specifica
utilizzando la relazione is-A esprimibile attraverso il costrutto
class.....extends....
In questo modo si sono ottenute
forti semplificazioni nello sviluppo dei controlli di autorizzazione
e si è ottenuta una buona efficienza.
Per comprendere come
si possa definire una gerarchia prendiamo in considerazione un
esempio completo. Supponiamo di dover modellare la seguente
gerarchia:
administator
guest
Il seguente codice java permette di specificare la gerarchia voluta:
administrator.java |
guest.java |
import SOMA.security.ldapauth.RolePrincipal; public class administrator
extends RolePrincipal |
import SOMA.security.ldapauth.RolePrincipal; public class guest extends
administrator |
compilando i files administrator.java e guest.java si ottengono i
bytecodes administrator.class e guest.class.
Questi bytecodes
saranno gli attributi java_class degli oggetti ROLE
identificati dai seguenti dn nel servizio di directory:
role=administator, id=roles, o=SOMA
role=guest, id=roles,
o=SOMA
In questo paragrafo si fa riferimento alla configurazione del server ldap openldap distribuito liberamente sotto GPL, nel sistema Linux. E' possibile ottenere una copia del software e maggiori informazioni presso http://www.openldap.org .
Il pacchetto openldap mette a disposizione il server ldap insieme ad una serie di tool che permettono di amministrare la directory.
Le entries nella directory vengono specificate nel formato ldif (LDAP Data Interchange Format). Un esempio di tale formato è il seguente:
dn: cn=Rebecca, id=users, o=SOMA
entrust_dn:
C:IT, O:IngBo, SerialNumber 123456789 CN:Rebecca
cn:
Rebecca
role: administrator
role:
guest
objectClass: SOMAuser
che specifica la entry relativa ad uno user specificando
che esso potrà ricoprire nel sistema i ruoli administarator e
guest.
Per maggiori informazioni sul formato LDIF invocare:
man 5 ldif
E' quindi necessario definire un file (chiamato, per esempio,
"/etc/openldap/dit") che, in formato ldif, specifichi
completamente le entries della directory.
Per inciso, è
possibile definire un attributo binario operando una codifica in
base64 dei dati, cosa che può essere facilmente ottenuta
eseguendo il comando ldif. Per esempio, i seguenti comandi sono
relativi alla generazione dell'attributo java_class del ruolo
administrator, e alla generazione dell'attributo policy del place
Roma
ldif -b java_class < administator.class
ldif -b
policy < Italia-Roma.policy
A questo punto è necessario definire il file di
configurazione del server (chiamato, per esempio,
"/etc/openldap/slapd.conf").
Per maggiori informazioni
su questo passo invocare:
man slapd.conf
Una volta definiti i file che abbiamo chiamato /etc/openldap/dit e /etc/openldap/slapd.conf, possiamo generare il data base relativo alla nostra directory invocando il comando:
ldif2ldbc -f /etc/openldap/slapd.conf -i /etc/openldap/dit
Fatto questo è possibile lanciare il server:
slapd -f /etc/openldap
Il processo di configurazione qui descritto prevede di generare off-line la directory e poi lanciare il servizio. E' anche possibile gestire la directory on-line attraverso alcuni programmi che presentano anche una intuitiva interfaccia grafica; si cita a questo rigurado il programma kldap disponibile su piattaforma Linux con desktop KDE.
Un esempio
completo di configurazione
In questo paragrafo vengono presentati tutti i file di configurazione necessari a lanciare il S.S.S. su un sistema Linux.
file di configurazione del server ldap: myslapd.conf
files di definizione delle politiche nei vari places:
Italia.policy
Italia-Roma.policy
Italia-Bologna.policy
Francia.policy
Francia-Parigi.policy
default.policy
file di definizione della directory in formato ldif: dit
OSSERVAZIONE: ovviamente le politiche sono mantenute dal server ldap come attributi degli oggetti place e domain.
per lanciare il S.S.S.
IMPORTANTE: affinchè la macchina virtuale java utilizzi il policy provider del S.S.S. è necessario editare il file java.security tipicamente posizionato in <JDK_DIR>/jre/lib/security/java.security, aggiungendo il seguente comando: auth.policy.provider=SOMA.security.ldapauth.ldapPolicy. E' importante notare che questo policy provider, se non è specificata la system property securityDomain, si comporta come il provider di default (PolicyFile) e quindi le altre applicazioni non risentiranno del cambiamento
specificare i ruoli e le gerarchie dei ruoli attraverso l'uso di java (come spiegato nel paragrafo ruoli ); compilare le definizioni
specificare le politiche utilizzando il linguaggio di specifica utilizzato da JAAS (per maggiori informazioni fare riferimento agli esempi e al seguente link: http://java.sun.com/security/jaas/doc/api.html#Policy
definire la struttura della directory come spiegato nel paragrafo politiche definendo il file "dit"
generare il db relativo alla directory con il comando : ldif2ldbm -f myslapd.config -i dit
lanciare il servizio di directory invocando il comando: slapd -f myslapd.config
lanciare SOMA indicando le seguenti opzioni all'interprete java:
-Djava.security.manager |
impone all'interprete di usare il security manager |
-Djava.security.policy=soma.policy |
politica di sicurezza del meccanismo di sicurezza standard di java. Il S.S.S. utilizza il meccanismo di sicurezza JAAS e non quello standard ma è comunque necessario specificare una politica |
-Djava.security.auth.login= |
file di configurazione di jaas |
-DsecurityServer=ldap://127.0.0.1 |
questa opzione indica il security domain al quale agganciare questa istanza di SOMA. Vedi |
-cp roles/:. |
è necessario indicare nel classpath la directory roles |