Guida Utente della PddConsole


1. Introduzione
1.1. Le entità di configurazione dei servizi
2. Configurazione di una Fruizione di servizio
2.1. Il processo base di configurazione
2.2. Esempio di una fruizione di servizio con protocollo trasparente
2.3. Le fasi della richiesta di fruizione
2.3.1. Authentication
2.3.2. Identification
2.3.3. Authorization
2.3.4. Validation
2.3.5. WS-Security
2.3.6. Tracing
2.3.7. Addressing
3. Configurazione di una Erogazione di servizio
3.1. Il processo base di configurazione
3.2. Esempio di una erogazione di servizio con protocollo trasparente
3.3. Le fasi della richiesta di erogazione
3.3.1. Authentication
3.3.2. Identification
3.3.3. Authorization
3.3.4. Validation
3.3.5. WS-Security
3.3.6. Tracing
3.3.7. Routing
4. Funzionalità specifiche per SPCoop
4.1. Profili Asincroni
4.1.1. Profilo di Collaborazione Asincrono Simmetrico
4.1.2. Profilo di Collaborazione Asincrono Asimmetrico
4.2. Importazione ed Esportazione degli Accordi di Servizio
4.3. Interfacce WSDL (concettuale, logico ed implementativo)
4.4. Profili di gestione della busta eGov
4.5. Profilo di gestione e-Gov 1.1
5. Funzionalità avanzate
5.1. Il protocollo di Cooperazione
5.2. Registrazione delle Porte di Dominio
5.3. Importazione ed Esportazione delle entità del Registro
5.4. Personalizzazione degli aspetti di fruizioni ed erogazioni
5.5. Modalità di identificazione della richiesta di fruizione
5.6. Autorizzazione
5.6.1. Autorizzazione con i Ruoli
5.6.2. Autorizzazione XACMLPolicy
5.6.3. Autorizzazione dei Soggetto Esterni (PA) con anti-spoofing
5.6.4. Autenticazione e Autorizzazione Principal (Security Constraint)
5.7. Header di Integrazione
5.7.1. Header di Integrazione su Trasporto
5.7.2. Header di Integrazione via URL
5.7.3. Header di Integrazione via SOAP
5.7.4. Header di Integrazione via WS-Addressing
5.7.5. Renaming delle proprietà dell’Header di Integrazione
5.8. Personalizzazione dell’Header di Integrazione
5.9. Connettori
5.9.1. Autenticazione Http
5.9.2. Autenticazione Https
5.9.3. Proxy
5.9.4. Configurazione Http Avanzata
5.9.5. Debug
5.9.6. Connettore JMS
5.9.7. Connettore File
5.10. Modalità di consegna dei contenuti agli applicativi
5.11. Correlazione Applicativa
5.12. WS-Security
5.12.1. Prerequisiti per WS-Security
5.12.2. Parametri WS-Security
5.13. Gestione protocollo MTOM
5.14. Riscrittura delle URL
5.15. Modalità alternativa al WSDL per la definizione dei messaggi negli Accordi Parte Comune
5.16. Configurazione Generale
5.16.1. Registro
5.16.2. Tabella di Routing
5.16.3. Configurazione Utente
5.16.4. Gestione utenti e permessi
6. Reportistica e risoluzione dei problemi
6.1. Diagnostica
6.2. Tracciamento
6.3. Auditing
6.3.1. Auditing Setup
6.3.2. Auditing Query
6.4. Coda Messaggi
A. Informazioni per l’esecuzione degli esempi contenuti nel presente manuale

1. Introduzione

Questo manuale documenta le funzionalità e modalità d’uso della PddConsole, il cruscotto grafico per la gestione della Porta di Dominio OpenSPCoop2. Tale applicazione permette agli operatori di gestire il funzionamento della Porta di Dominio, come ad esempio:

  • Consultare e aggiornare le configurazioni dei servizi presenti nel Registro

  • Effettuare ricerche e consultare le tracce e i messaggi diagnostici.

  • Gestire parametri e funzionalità di amministrazione della PddConsole e della Porta di Dominio.

Nel prosieguo si assume che la PddConsole sia già correttamente installata e raggiungibile via browser dai Gestori del Sistema. L’indirizzo di default della PddConsole è http://ip:porta/pddConsole, che dovrà ovviamente essere contestualizzato con ip e porta del proprio ambiente di installazione. Per informazioni sulle modalità di installazione si rimanda alla relativa manualistica distribuita con il prodotto.

[Nota] Nota

Si tenga presente che l’accesso alle diverse funzionalità della PddConsole è sempre mediato da un sistema di autorizzazione che verifica che l’utente sia in possesso dei dovuti permessi. Le istruzioni operative sulla gestione degli utenti e la configurazione dei permessi sono descritte in Sezione 5.16.4, «Gestione utenti e permessi».

1.1. Le entità di configurazione dei servizi

La Porta di Dominio è dotata di un repository delle configurazioni che viene indicato come “Registro”. In esso devono essere inserite le entità di configurazione dei diversi servizi affinché la Porta di Dominio supporti i flussi dei messaggi applicando i comportamenti richiesti in ciascuno caso specifico.

Le principali entità di configurazione del Registro sono:

  • Porta di Dominio

    Entità anagrafica delle porte di dominio riferite nei flussi di comunicazione. Si distingue la porta di dominio di tipo “operativo”, rappresentata dall’istanza interna, da quelle di tipo “esterno”.

  • Protocollo

    Rappresenta il protocollo adottato dai servizi per lo scambio dei messaggi. La Porta di Dominio supporta nativamente alcuni protocolli ed esiste la possibilità di implementarne di nuovi tramite gli strumenti di sviluppo. Maggiori dettagli in Sezione 5.1, «Il protocollo di Cooperazione».

  • Soggetto

    Entità che rappresente la singola organizzazione o ente amministrativo, afferente ad una delle Porte di Dominio. Il soggetto presente nel registro può fruire e/o erogare i servizi descritti negli Accordi presenti nel registro.

  • Accordo Parte Comune

    Descrizione formale dei flussi di comunicazione previsti da un dato servizio, erogato o fruito. La descrizione formale comprende necessariamente i port-type e le operation presenti. Possono inoltre essere presenti i descrittori xml, WSDL e XSD, indispensabili nel caso in cui si voglia utilizzare la funzionalità di validazione dei messaggi in transito sulla Porta di Dominio.

  • Accordo Parte Specifica

    Istanza effettiva di servizio utilizzata, in erogazione o fruizione, da un servizio applicativo appartenente ad un soggetto interno al dominio. L’accordo parte specifica riferisce un accordo parte comune, dal quale eredita l’interfaccia, e contiene i dettagli di puntamento ad una specifica erogazione. Possono essere configurati più accordi specifici relativi al medesimo accordo parte comune.

  • Erogazione

    Dati di configurazione di una erogazione relativa ad un soggetto interno al dominio. L’erogazione riporta quindi l’accordo parte specifica che regolamenta le comunicazioni e l’identificazione del soggetto fruitore. La configurazione di una erogazione instaura un canale di comunicazione specifico tra il soggetto fruitore esterno e il servizio applicativo erogatore interno.

  • Fruizione

    Dati di configurazione di una fruizione relativa ad un soggetto interno al dominio. La fruizione riporta quindi l’accordo parte specifica che regolamenta le comunicazioni, che comprende i dati di puntamento al servizio erogatore, e l’identificazione del servizio applicativo fruitore che è autorizzato all’invocazione. La configurazione di una fruizione instaura un canale di comunicazione specifico tra il servizio applicativo fruitore interno e il soggetto erogatore esterno.

Ciascun accordo di servizio parte comune si compone di un certo numero di servizi e, per ciascun servizio, di un certo numero di operazioni invocabili dai client. Questa entità di configurazione è identica sia nel caso della fruizione che in quello dell’erogazione.

L’accordo di servizio parte specifica invece ha una differente connotazione nel registro a seconda che si tratti un’erogazione o di una fruizione. Il flusso di elaborazione di una richiesta prevede, sia per le erogazioni che per le fruizioni, le fasi evidenziate in Figura 1, «Fasi dell’elaborazione di una richiesta». Tali fasi, tutte opzionali in base a quanto previsto nella configurazione, sono:

  • Autenthication

    L’agente che ha inviato la richiesta viene autenticato verificando le sue credenziali.

  • Identification

    Dalle credenziali fornite in fase di autenticazione si risale all’identità dell’agente mittente. Vengono inoltre identificati i dati necessari per il soddisfacimento della richiesta come il servizio e l’operazione richiesta.

  • Authorization

    Una volta identificati i dati della richiesta si verifica la presenza delle necessarie autorizzazioni da parte dell’agente mittente relativamente alla richiesta effettuata.

  • Validation

    Viene effettuata la validazione dei messaggi in transito basandosi sugli schemi presenti nella descrizione dell’accordo di servizio parte comune.

  • WS-Security

    Viene processata la codifica WS-Security, con eventuale gestione di cifratura e firma, che porta all’imbustamento/sbustamento del messaggio di richiesta ricevuto.

  • Tracing

    Vengono memorizzate sul registro le informazioni di tracciamento relative alla richiesta in fase di elaborazione.

  • Routing/Addressing

    Al termine del processamento la richiesta viene smistata al destinatario responsabile del successivo passo di esecuzione.

Le attività svolte dalla Porta di Dominio, e le relative configurazioni da produrre sul Registro, per ciascuna delle fasi sopra elencate differiscono a seconda che si tratti di una richiesta di fruizione o di erogazione. In seguito verranno descritte in dettaglio tali differenze nei due casi specifici.

Fasi dell'elaborazione di una richiesta

Figura 1. Fasi dell’elaborazione di una richiesta