| Autore: | Bud P. Bruegger <bud@comune.grosseto.it> |
|---|---|
| Organizzazione: | Comune di Grosseto |
| Copyright: | Comune di Grosseto |
| Data: | 24 Ottobre 2003-10-15 |
| Status: | Prima versione, base di discussione |
| Versione: | 0.1 |
Sommario
Questo documento da un quadro generale della Applicazione Provisioning Utenti Non-Gia-Noti. Il provisioning si preoccupa di raccoglere i dati necessario per render il sistema accessibile ai utenti. Gli utenti non-gia-noti escludano cittadini residenti (noti nella anagrafe) e personale del ente.
Questo documento costituisce la specifica funzionale della applicazione di provisioning di non- residenti.
Per chiarezza descrive anche in dettaglio l'ambito in quale tale applicazione si integra.
L'obiettivo della applicazione di provisioning per utenti non noti e' di ricevere e processare richieste di accesso con la finalita' di popolare il directory server del Comune di Grosseto in modo di fornire agli utenti l'accesso ai servizi richiesti.
Questa sezione descrive in dettaglio l'ambito nel quale l'applicazione richiesta si va ad integrare.
La CIE Italiana rappresenta un primo passo per la implementazione di un controllo di accesso unificato per servizi della pubblica amministrazione. Anche se la CIE e' chiaramente il fulcro del progetto, l'obiettivo piu' ampio puo' essere raggiunto solo se anche altri tipi di credenziali possono essere integrati in tale approccio. In particolare, la Carta Nazionale di Servizi (CNS) e token crittografici adatti per enti pubblici o privati saranno elementi importanti nel controllo di accesso delle pubbliche amministrazioni.
Visto che non e' prevedibile esattamente quali tipi di credenziali devono essere sopportate, l'applicazione deve essere facilmente estendibile con moduli che implementino nuovi tipi di credenziali. Come "proof of concept", le credenziali da implementare come parte del progetto saranno la CIE e la coppia username/password.
La seguente descrizione dell'approccio utilizzato per l'autenticazione, autorizzazione, e provisioning da il contesto necessario per capire meglio la specifica funzionale della applicazione di provisioning per utenti non-gia'-noti.
E' importante notare che una singola persona (fisica o legale) può avere uno o piu' token per identificarsi. Per esempio, un cittadino può avere sia la CIE che la CNS; un ente pubblico puo' avere molteplici tokens per avvalersi dei servizi esposti dal Comune di Grosseto. Ogni token ha un diverso ID; su token crittografici, l'ID e' tipicamente un DN (Distinguished Name), in caso di username/password, l'ID e' lo username. Ogni token ha anche una credenziale. In caso di token crittografici e' formato dalla coppia CIE/PIN che permette di accedere alla chiave privata; nel caso di username/password e' la password.
Uno dei compiti del provisioning e' quello di mappare l'ID del token ad un principal memorizzandolo in una struttura opportuna (DB, LDAP, ecc). Un principal e' un identificativo univoco del proprietario del token. Le scelte possibili per un principal sono codice fiscale o chiave primaria della anagrafe delle persone. Fondamentale l'aspetto che un soggetto ha soltanto un principal, anche se ha molteplici tokens con diverso ID.
Il Provisioning e' il processo che permette di fornire l'accesso ai servizi disponibili. La seguente analisi descrive i cinque passi necessari per effettuare il provisioning:
Questi passi vengono discussi in maggior dettaglio nel seguito.
Esistono molteplici modi per verificare l'identita' del richiedente, tra questi i metodi crittografici cosi' come vengono usati nelle procedure di autenticazione client-cert di SSL, ispezione visuale di un documento di indentita' cartaceo, conferma della e-mail (come per esempio usato da MailMan).
Per gestire i dati relativi al richiedente nel sistema informatico (in particolare l'LDAP), e' necessario assegnare un identificativo univoco al richiedente. Questo identificativo e' chiamato principal e puo' essere usato come DN o chiave primaria. Un richiedente puo' gia' essere noto al sistema.
Come pre-requisito per garantire l'accesso, e' necessario verificarne il diritto da parte del richiedente. Tipicamente, questa decisione si basa su dati forniti con la richiesta di accesso e dati gia' contenuti nel sistema informativo. Dove possibile, la decisione deve essere automatizzata. Dove non e' possibile serve un processo manuale (con interfaccia utente).
Una volta accertato che il richiedente ha diritto al servizio, ci si deve mettere d'accordo su un token di autenticazione da usare per l'accesso. E' possibile che questo token gia' esista (come per esempio la CIE) o debba essere creato ex-novo (come tipicamente un username/password, o la CIE rilasciato dal comune di Grosseto). (Da notare che e' possibile utilizzare un token gia' esistente, ad esempio il token utilizzato per l'indentificazione nel primo passo.)
I dati relativo al token da usare devono essere inseriti nel LDAP server. Alla fine, per permettere l'accesso, e' necessario assegnare i ruoli nel server LDAP.
Nella architettura scelta, la piattaforma client usata da cittadini (o altri utenti) remoti deve essere la minima e la piu' standard possibile. Questo garantira' la massima flessibilità di sistemi operativi e di tipi di tokens supportati.
In conseguenza, l'autenticazione con mezzi standard (come SSL) rileva solamente l'ID del token usato e, normalmente, manca l'informazione sul principal. I dati necessari per poter mappare l'ID del token ad un principal devono essere prodotti dal processo di provisioning e devono essere gestiti nel server LDAP.
Il processo di emissione CIE e' una componente del provisioning in senzo logico ma non fa parte della applicazione.
Il processo di provisioning si applica alla emissione come segue:
L'identita' della persona viene verificato in modo non-elettronico e di consequenza, un security token viene creato, e vengono assegnati alcuni ruoli default per residenti.
Parte di questo processo e' quello di popolare l'LDAP con i dati contenuti sulla CIE incluso:
Per raggiungere questo obiettivo, una utility a linea di comando, usa i metacommandi del ministero per estrarre sia il certificato che i dati personali e li manda ad un indirizzo http per il processamento. Il processamento consiste di cinque passi:
I seguenti attori usano il sistema:
[due servlets: elenco di possibile richieste, singola richesta]
Il richiedente naviga nel portale del comune ed entra in un'area al quale non e' ancora autorizzato. Viene automaticamente rediretto sulla pagina di richiesta del servizio (o l'indice di tutti tipi di richieste o la richiesta necessaria per il servizio richiesto).
In funzione del servizio richiesto, la form html di richiesta presenta diversi campi da riempire. Il richiedente compila il modulo e lo manda al server.
Nel caso in cui il servizio richiede autenticazione forte, il modulo di richiesta e' disponibile solo tramite https (ssl) con client-cert authentication, a questo scopo viene richiesto l'uso della CIE. (Di consequenza, la richiesta che arriva al server contiene sia il certificato X.509 della CIE che i dati del modulo html).
Se la richiesta definisce validazioni dei dati del modulo che possono essere eseguiti immediatamente (vedi use case 4), ci sono due possibili risposte a una sottomissione di un modulo di richiesta:
Nel primo caso, il richiedente viene presentato una pagina web che conferma l'accettazione della richiesta e da un URL 1 sotto quale il stato della richiesta puo essere verificato.
| [1] | Nota che il cliente a questo punto non e' autenticato in modo "normale" dal sistema e che ci sono problemi di privatezza. Un approccio e' di usare un numero random nel URL che lo rende molto improbabile che altri possono vedere lo status della richiesta. Un altro approccio piu' complicato sarebbe di usare un password di accesso. |
[un servlet]
Il richiedente (dopo essere stato autorizzato all'uso di un servizio) visita la sua pagina personale (home page) per cambiare i dati personali quali:
Deve essere possibile configurabile quali dati possono essere cambiati.
[due servlet: pool delle richieste da processare, processamento singola richiesta]
L'approvazione delle richieste puo' essere configurato per essere eseguito in modo automatico o che richiede una decisione di un responsabile (vedi use case 4).
Nel secondo caso, un impiegato del comune autorizzato alla approvazione visita la pagina delle richieste da processare (di un certo tipo). A questo scopo, si autentica con la sua CIE ed il suo ruolo deve corrispondere a quello configurato nel deployment descriptor della richiesta.
L'impiegato sceglie una richiesta e vede una pagina che presenta tutti i dati del modulo e (opzionalmente) il risultato di tutte le verifiche che sono previste nel deployment descriptor della richiesta.
L'impiegato puo prendere una delle seguenti decisioni:
Nell' ultimo caso, la richiesta rientra nell' insieme di richieste non processate. Nel caso di accettazione, il richiedente viene abilitato al servizio. A questo scopo, i dati vengano inseriti nell' LDAP.
In caso di accettazione o respinta, il risultato della richiesta viene comunicato tramite e-mail (questo richiede che l'e-mail sia un campo obbligatorio!!!)
Nota che questo use case corrisponde a un modulo di validazzione descritto in use case 4.
[una libreria estendibile di funzionalita' (vedi Moduli Richiesti), configurazione del applicazione tramite file in XML]
Il sistemista/deployer/developer del Comune decide durante deployment il comportamento complessivo della applicazione di provisioning. In particolare, decide quale tipi di richieste ci sono, come vengano strutturate richieste, e come vengono processati.
A questo scopo servano due componenti:
La seguente descrizione e' un primo tentativo di identificare gli elementi che devono essere configurabili ed i tipi di funzionalita' che devono essere forniti dalla libreria di moduli. Questo paragrafo si occupa soltanto di quali tipi di funzionalita' sono richieste relativamente alla domanda di servizio; la prossima sezione Moduli Richiesti invece descrive i moduli concreti richiesti.
Il file di configurazione contiene una serie di sezioni che descrivano una singola richiesta ogni uno. Per ogni richiesta, la configurazione descrive quattro aspetti:
La descrizione generale include elementi usato per la presentazione complessiva della richiesta. Una lista non necessariamente completa di elementi segue:
Per ogni richiesta si specifica i dati richiesti dal richiedente che corrispondano a campi su un modulo html. Per ogni campo, i seguenti attributi devono essere specificati (lista non necessariamente completa):
I dati derivati sono dati relevanti alla valutazione della richiesta che possono essere derivati da quelli richiesti nel modulo. Tipicamente, si tratta di una derivazione funzionale oppure un lookup in un tipo di base dati esterno. Ogni derivazione ha accesso ai dati del modulo e alcuni CGI- variables specifici (quale il certificato e il DN del sogetto rilevato dal handshake SSL). Ogni derivazione corrisponde a un modulo nella libreria. Esempi di derivazioni sono:
Un passo importante della configurazione e' di specificare come validare i dati immessi. L'esito positivo di un gruppo di validazione e' un prerequisito per possibili azioni. Ogni possibile validazione corrisponde a un modulo e ogni modulo puo accedere a dati richiesti e derivati (parametri). L'esito di una validazione e positiva o negativa.
Ci sono due tipi di validazione:
Il configuration file specifica multiple azioni per ogni richiesta. Una azione corrisponde a un modulo della libreria. Ogni azione dipende dal esito positivo di un sottoinsieme di validazioni definiti per la richiesta. Il seguente sono esempi di azioni:
Per efficienza sara' utile la possibilita' di definire gruppi riusabili di entita', in particolare gruppi di dati. Questo lo rende possibile, per esempio, di aggiungere "datiPersonaliCIE" in un singolo statement in multiple richieste.
[default style sheet]
Il web-designer modifica il style sheet CSS 2 per adattare il look and feel.
Il sistema puo' essere configurato di automaticamente cancellare richieste piu' veccio di una certa eta'. Use Case 7: Quality Control sul Servizio di Processamento di Richieste Il quality control manager di un singolo ufficio o di tutto l'ambito comunale visita la pagina di quality control. I seguenti viste sono disponibili:
Gli Use Cases, e in particolare quello di Configurazione delle Richieste implica la presenza di molte enita' software da referenziare nel file di configurazione (sopra chiamato libreria). I seguenti moduli funzionali sono richiesti: