L’integrazione diretta tra applicazioni è denominata application to application, abbreviato A2A.Con questa modalità si possono integrare sia i Servizi primari del SISS sia servizi aggiuntivi esposti dagli Aderenti fornitori come Web services, cioè in modo tale che i due sistemi applicativi coinvolti (espositore e fruitore) dialoghino fra di loro con interfacce predefinite consentendo un’integrazione funzionale trasparente all’utente.

Le componenti messe a disposizione dal SISS supportano tale dialogo fornendo ed integrando i servizi di sicurezza (es. identificazione, autenticazione, autorizzazione, riservatezza, non ripudio, …) riducendo ai due attori principali del dialogo (applicazione fruitrice ed applicazione esposta) gli impatti derivanti da tali servizi di sicurezza.

L’Applicazione fruitrice per integrarsi deve utilizzare la documentazione messa a disposizione dall’Aderente fornitore e da LI.

Le tipologie di integrazione A2A, per il fornitore di servizi, appartengono a due categorie:

• Integrazione di “servizi normalizzati” dal SISS;
• Esposizione di “servizi esposti direttamente” (anche detti “servizi diretti”, cioè non normalizzati dal SISS).

Nel primo caso (servizi normalizzati) l’Aderente fornitore del servizio non ha la necessità di definire alcuna interfaccia. Il suo compito è quello di effettuare l’integrazione utilizzando le interfacce già definite dal SISS. Gli scenari e le tecnologie di integrazione sono definite nei documenti specifici e non saranno più trattati nel prosieguo della presente trattazione.

Nel secondo caso (servizi diretti), l’Aderente fornitore deve strutturare l’applicazione come un insieme di Web service che espongono dei metodi richiamabili dalle applicazioni fruitrici tramite lo scambio di messaggi nel protocollo SOAP (SOAP è un protocollo leggero per lo scambio di dati in ambienti distribuiti ed è basato su XML. Un messaggio SOAP è infatti costituito da una struttura XML).

Lo scambio di messaggi è mediato dal CGI attraverso le componenti di Porta Delegata (dell’applicazione fruitrice) e di Porta Applicativa A2A (dell’applicazione esposta). Tali componenti provvedono alla realizzazione di servizi di piattaforma, messi a disposizione dal CGI a beneficio degli Aderenti.

A titolo di esempio, si riportano di seguito alcune classi di servizi di piattaforma già messe a disposizione dal CGI:

• Autenticazione dell’operatore;
• Apposizione e verifica della firma;
• Apposizione e verifica della marca temporale;
• Lettura dei dati della smart card;
• Invio sicuro di documenti.

Considerata la disponibilità dei servizi di piattaforma, nel definire le modalità di esposizione dell’applicazione, l’Aderente non deve preoccuparsi degli aspetti non attinenti alla logica applicativa e può concentrarsi sulla definizione delle sole interfacce di business.

Accesso ai servizi A2A in modalità Procedura Automatica

Nell’ambito del SISS i servizi sono per default acceduti in modo nominale, cioè l’operatore che si autentica al SISS richiede i servizi dell’Extranet direttamente dalla postazione da cui ha eseguito il Logon durante il periodo di validità della sua sessione di lavoro. I servizi richiesti dall’operatore sono, in questo modo, direttamente riconducibili all’operatore richiedente che si assume esplicitamente la responsabilità di quanto ottenuto o modificato nell’ambito dei servizi utilizzati, permettendo ai servizi stessi di effettuare logging e controlli di autorizzazione con la granularità necessaria.

La modalità Procedura Automatica consente ad un operatore autorizzato di delegare una procedura automatica (normalmente operante in un server aziendale) ad operare per suo nome e conto.

Tramite tale modalità un operatore può generare e trasferire ad un’applicazione integrata al SISS (propria o della propria Azienda) una quantità di sicurezza (Token) che permetta a tale applicazione di interagire con l’Extranet esattamente come se fosse l’operatore in prima persona, anche quando questo terminerà la propria sessione di lavoro sul proprio PdL SISS. I punti cardine di questa operatività sono i seguenti:

• L’operatore deve essere preventivamente autorizzato ad attivare le procedure automatiche;
• La produzione della quantità di sicurezza (Token) che viene rilasciata dal SISS per essere posta nel contesto dell’applicazione server delegata dall’operatore ha le seguenti proprietà:

• ha lo stesso ruolo e lo stesso contesto funzionale che l’operatore ha acquisito al Logon;
• é distinguibile dalla credenziale che l’utente acquisisce nominalmente e che utilizza quando utilizza i servizi in prima persona tramite il proprio PdL;
• il Token di procedura automatica ha una durata superiore alla sessione di lavoro massima degli utenti nominali, la sua validità può essere limitata a piacere dall’operatore che la sta richiedendo e necessita dell’esplicito consenso dell’operatore affinché venga rilasciato;

• L’operatore ha la possibilità di invalidare un Token di procedura automatica utilizzando i soli servizi del SISS, quindi anche se non riesce a bloccare l’applicazione che l’operatore ha delegato ad utilizzarlo;
• Per ogni processo utilizzabile in modalità procedura automatica è previsto il rilascio di uno specifico Token; il processo di gestione dei singoli Token è totalmente indipendente.

I servizi del SISS sono accessibili anche attraverso un nuovo meccanismo di esposizione denominato “API Manager”. In particolare, nel contesto SISS, l’utilizzo dell’API Manager permette l’implementazione di Web Application presso gli Enti Erogatori che accedono ai web service del SISS senza dover integrare la Porta Delegata della postazione dell’operatore. 

Utilizzo di Web Application

Nel seguito viene fornita una descrizione generale dell’ utilizzo di una web application.
Questa modalità di esposizione è da utilizzarsi quando il servizio dell’Aderente è costituito da una Web Application e gli utenti vi accedono tramite un normale Browser Web.
Le componenti messe a disposizione dal SISS supportano tale dialogo fornendo ed integrando i servizi di sicurezza (es. identificazione, autenticazione, autorizzazione, riservatezza, non ripudio, …) e limitando per i due attori del dialogo (Web browser ed applicazione esposta dall’Aderente) gli impatti derivanti dai servizi di sicurezza e dalle tecniche crittografiche da questi utilizzati.
L’applicazione dell’Aderente è esposta sull’Extranet dal Front end attraverso la mediazione del servizio di Reverse Proxy, che è un componente della Porta Applicativa dell’Aderente espositore il quale gestisce gli accessi alle web application, avvalendosi anche di un agente di sicurezza.
L’operatore, effettuato il Logon Primario, può accedere alle Web Application.
Ad ogni richiesta di accesso dell’operatore ad una Web Application viene effettuata una fase di Logon Secondario.
In questo modo, il SISS mette a disposizione dell’Aderente, espositore della web application, la possibilità di limitare l’accesso ai propri sistemi, bloccando direttamente sul Front end eventuali accessi non autorizzati.
L’architettura di elaborazione prevista da questo modello prevede che la logica applicativa sia centralizzata nei sistemi di elaborazione dell’Aderente fornitore. E’ comunque contemporaneamente supportato anche un modello di elaborazione distribuita, limitatamente alle elaborazioni che non possono essere realizzate centralmente (es. una firma digitale con Smart card).
Qualora vi sia necessità di effettuare elaborazioni locali sul PdL, l’Aderente espositore dovrà inserire nelle pagine della web application del codice Javascript che viene eseguito dal browser dell’utente e che può richiedere servizi alla Porta Delegata del PdL. Si ritiene che tipicamente verranno utilizzati solo i servizi tipici della Porta Delegata (es. la firma elettronica, la lettura dei dati della SmartCard, …), ma è anche possibile, in caso di necessità particolari, realizzare un modello completo di interazione di tipo A2A, già descritto in precedenza, con componenti dell’applicazione esposta appartenenti al sistema informativo dell’Aderente espositore.

Ruoli e responsabilità per l’esposizione di web application

L’Aderente espositore, se ha necessità, può utilizzare la credenziale dell’operatore che il CGI inserisce nell’header della richiesta propagata all’applicazione esposta, ad esempio per ulteriori controlli di sicurezza o per la gestione di un accesso profilato alle pagine dell’applicazione.
In caso di utilizzo di codice Javascript per le elaborazioni effettuate localmente, l’interazione con l’applicazione esposta è in modalità A2A ed avviene tramite la Porta Delegata e la Porta Applicativa.