Come organizzare l’archivio sinekarta?

Una delle funzionalità più interessanti di sinekarta è poco documentata e “nascosta” nelle pieghe più profonde del software. Quale migliore occasione di un articolo tecnico estivo per approfondire l’argomento?

Sinekarta viene distribuito con una configurazione di default che comprende poche tipologie di documenti. La configurazione è modificabile utilizzando la funzione specifica associata all’archivio sinekarta. Questo significa che il Responsabile della Conservazione Sostitutiva (RCS) è in grado, autonomamente, di aggiungere, cancellare o modificare a piacere questa configurazione.

Ma quali sono le informazioni associate ad una tipologia di documento?

La pagina HTML che permette di gestire il tipo documento presenta le seguenti informazioni :

• Tipo documento : questa è una semplice descrizione della tipologia di documento
• Trascodifica esterna : questo campo è molto importante anche se ancora non è utilizzato. Permetterà (in un prossimo futuro) di creare il file delle impronte per l’agenzia delle entrate.
• PDFA già firmato : indica a sinekarta che il documenti di questo tipo inseriti in archivio devono essere già firmati, vanno gestiti di conseguenza.
• Documento originale unico : indica a sinekarta che il documento necessita della firma di un Pubblico Ufficiale
• Necessario OCR : indica a sinekarta che il documento necessita di un OCR per indicizzare il testo delle immagini in esso contenute
• Lingua di default per OCR : questa è la lingua proposta di default durante l’acquisizione del documento
• Regola per spostamento documenti : regola da utilizzare per determinare la directory in cui spostare il documento archiviato
• Regola per creazione marca temporale : regola da utilizzare per determinare la directory in cui creare il documento di marca temporale

I primi campi sono decisamente semplici, non necessitano di particolari spiegazioni. Gli ultimi due campi, invece, sono il punto focale di questo articolo.

Iniziamo col dire che entrambi esprimono una regola per determinare il nome di una directory (alfresco space) che verrà creata/ricercata all’interno dell’archivio sinekarta.

Il risultato dell’interpretazione della regola deve SEMPRE essere un path in formato lucene. Tutte le configurazioni sono impostate con regole di tipo “sdf:” dove sdf è l’acronimo di Simple Date Format. Il testo indicato dopo il prefisso “sdf:” viene interpretato usando le regole descritte in questa pagina : http://download.oracle.com/javase/1.4.2/docs/api/java/text/SimpleDateFormat.html

Il testo contenuto dopo sdf: esprimerà quindi il nome di una directory (in formato lucene) che verrà cercata/creata dentro l’archivio sinekarta. Questa regola ad esempio : sdf:’/cm:Anno ‘yyyy’/cm:Certificati malattia’ permetterà di cercare/creare dentro l’archivio sinekarta la seguente directory : “/Anno 2011/Certificati malattia”.

Durante l’analisi delle funzionalità di sinekarta abbiamo però definito che questa modalità non era sufficiente. Non forniva all’RCS un dinamismo abbastanza “forte” da gestire qualsiasi situazione.

Per questo motivo esiste anche la possibilità di creare regole con prefisso “js:”, dove js è l’acronimo di JavaScript. Il JavaScript è una delle funzionalità più potenti di Afresco. Tramite questo linguaggio (che viene interpretato, non compilato) è possibile definire diversi comportamenti del sistema. Non mi voglio dilungare tropppo sulle capacità di questo strumento, in rete è possibile trovare diversi esempi; concentriamoci sulle regole di sinekarta.

In caso si decida di utilizzare le regole di tipo javascript (js:) si dovrà indicare il path lucene (all’interno della company home) che identifica un file di tipo javascript.

Indicando, ad esempio, questa regola : js:/app:dictionary/app:scripts/cm:sampleRegolaPercorsoContrattiSinekarta.js , sinekarta utilizzerà il file sampleRegolaPercorsoContrattiSinekarta.js per calcolare il nome della directory (in formato lucene) che verrà cercata/creata dentro l’archivio sinekarta. Piccola nota tecnica, il percorso “/app:dictionary/app:scripts” corrisponde allo space “/Dizionario dei dati/Script”; i file javascript DEVONO essere caricati nel repository Alfresco.

Con sinekarta sono forniti due javascript di esempio, li trovate nella directory “Alfrescosinekartajs” (su file system, non dentro il repository di Alfresco); sono semplici esempi che possono essere utilizzati come base per creare qualsiasi tipo di regola.

La psosibilità di utilizzare javascript per determinare il nome delle directory dell’archivio fornisce all’RCS lo strumento perfetto per configurare l’archivio secondo le esigenze dell’azienda.

Lo strano mondo delle API crittografiche

In questi giorni sto rivedendo la componente di sinekarta che si interfaccia alla smartcard.

L’attuale applet è stata implementata quasi totalmente da Luca che ha fatto un ottimo lavoro. Stiamo studiando però una soluzione che sia ancora più semplice e utilizzabile anche dai device di ultima generazione.

Non nascondo che nell’ultima settimana ho dovuto studiare molto, ho dovuto colmare le molte lacune che avevo sull’argomento.

L’attuale applet di sinekarta è basata su javasign, un prodotto open source molto valido che è però praticamente morto (R.I.P.). Javasign è a sua volta basato, per quanto riguarda l’accesso alle funzionalità della smartcard, sul famoso pkcs11wrapper di IAIK. Quest’ultima componente non è scritta in tecnologia java, questo costringe l’utente a scaricare una DLL prima di utilizzare per la prima volta la firma digitale di sinekarta.

Gia da qualche anno nella Java Virtual Machine è inclusa una serie di API (javax.smartcardio) che permette di accedere direttamente alle funzionalità messe a disposizione dalla smart card.

“Perfetto!” mi sono detto, la nuova applet di sinekarta utilizzerà direttamente queste funzionalità per applicare la firma digitale. Ho scritto qualche manciata di codice java e sono riuscito senza grossi problemi ad accedere ai dati presenti sulla mia smartcard. Che soddisfazione!!!

Subito dopo ho provato ad utilizzare i servizi di sicurezza necessari all’utilizzo del certificato di firma digitale. Qui sono iniziati i problemi seri.

Da qualunque parte affrontassi il problema non riuscivo a torvare la soluzione.

Alla fine ho chiesto un po’ in giro (grazie ad Emanuele ma soprattutto ad Andrea) e sono riuscito a capire il modo giusto di affrontare il problema.

I produttori di smart card “proteggono” la possibilità di accedere direttamente alle funzionalità evolute della carta tramite “chiavi di accesso” che non vengono divulgate.

Non sono divulgate neanche le specifiche di dettaglio del formato dei dati relativi alla firma digitale (Digital Signature).

Non pensiamo subito a chissà quale tentativo di legare il mercato o di limitare la concorrenza; il vero motivo lo descrive questa frase di Andrea : “Il motivo della presenza di questo meccanismo di cifratura è quello che, trattandosi di dispositivi certificati Common Criteria (è un obbligo di legge), si vuole garantire che le librerie utilizzate siano quelle approvate dal costruttore e sottoposte a certificazione.”

Per aggirare questo problema la maggior parte dei software (IAIK compreso) accedono alla smart card passando da un’API standard chiamata PKCS#11.

Quest’API (su ambiente windows una DLL) DEVE essere fornita dal produttore di smart card e nasconde al programmatore questi tecnicismi. Nella Java Virtual Machine è inclusa anche un’API (java.security) specifica per utilizzare le librerie PKCS#11 esterne.

Ricapitoliamo :

1. situazione attuale – l’applet utilizza javasign che necessita di una dll (pkcs11wrapper) che necessita dell’API PKCS#11 della carta
2. situazione ideale – l’applet utilizza direttamente l’API javax.smartcardio (non c’è bisogno di DLL esterne) in modo da essere utilizzabile su qualsiasi device, dovremmo conoscere le “chiavi di accesso” di tutte le smart card
3. probabile implementazione – l’appet utilizza direttamente l’API PKCS#11 della carta

Potrei fare varie speculazioni sulla normativa, su quanto potrebbe essere migliorabile o su quanto sarebbe opportuna questa o quella modifica… inutile polemica. Qualsiasi modifica richiederebbe MOLTO tempo : dovrebbe essere pensata, normata, recepita e divulgata; il progetto deve evolvere più in fretta.

La modifica che apporteremo alla applet di sinekarta sarà quella che ci consentirà un maggiore risultato in breve tempo : PKCS#11 è la nostra scelta!