Charimenti interoperabilità e linee guida sicurezza

[asorcinelli]

Salve,
avrei bisogno di chiarimenti in merito alla gestione della sicurezza nello scambio di messaggi SOAP.
La parte relativa a TLS, versione minima, etc è chiara.
Se ho capito bene per lo scambio dei messaggi SOAP è necessario attenersi al profilo [INTEGRITY_SOAP_01] che prevede, tra le altre cose, l'inclusione/riferimento
del certificato X.509 e la firma del payload. E' corretto?

Il certificato da utilizzare dovrà essere qualificato in modo da includere gli OID (2.5.4.97 e l'OID 2.5.4.11) definiti nelle linee guida. A questo scopo è possibile
utilizzare il medesimo sigillo informatico utilizzato per la firma della segnatura?

Chi riceve il messaggio SOAP dovrà identificare il "mittente" tramite il certificato e tramite la verifica sull'IPA. E' corretto? Nel caso in cui cui la verifica
non sia possibile per mancanza di tali informazioni nel certificato, il messaggio deve ritenersi non valido?
Se invece tali informazioni ci sono, ma per problemi tecnici non sia possibile verificare lato IPA, il messaggio è sempre da scartare?

[vintra73]

In merito ai quesiti posti di seguito le risposte agli stessi:

1. Utilizzo del profilo [INTEGRITY_SOAP_01]:SI
2. Utilizzo certificato qualificato con inclusione degli OID 2.5.4.97 e 2.5.4.11: SI
3. Utilizzo del medesimo certificato: dipende dal key usage del certificato
4. Verifica a carico del ricevente: è necessario il riscontro della correttezza dei codici IPA presenti degli OID 2.5.4.97 e 2.5.4.11 con i valori presenti in IPA
5. Mancanza di popolamento degli OID 2.5.4.97 e 2.5.4.11: la comunicazione non può ritenersi valida
6. Impossibilità riscontro IPA: il messaggio è messo in waiting in attesa di ripristino connessione con IPA

[asorcinelli]

Grazie mille delle risposte.
Avrei un altro dubbio: nel metodo MessaggioInoltro del ws "ProtocolloDestinatario" è previsto il parametro Anomalia che va popolato nel caso ci fossero anomalie del messaggio ricevuto. Le possibili anomalie previste sono due:

• 001_ValidazioneFirma
• 002_AnomaliaImpronte

Fino a qui tutto bene. Però un messaggio potrebbe avere altre anomalie, come un campo obbligatorio non specificato o non valido.
In queste situazioni credo che l'ideale sarebbe stato restituire sempre l'anomalia, con un messaggio specifico e con un valore dell'enum che facesse capire il tipo di errore come nei due casi precedenti.
E' prevista una qualche modifica in questo senso?

[vintra73]

Buongiorno,
in merito segnalo che è previsto l'enum 000_Irricevibilita che prevede l'esplicitazione della motivazione che ha determinato l'irricevibilità, i restanti errori enumerati sono statti previsti per permettere di gestire le fattispecie individuate allo stato.

Nei successivi aggiornamenti dell'allegato in oggetto è possibile prevedere un raffinamento dell'elenco degli errori specializzati capitalizzando l'esperienza maturata dall'utilizzo dei servizi.

[asorcinelli]

Quel valore lo trovo solo per l'enum "AnomalieAnnullamentoEnum" e non per "AnomalieInoltroEnum".
Se è previsto anche per quello nessun problema, ma nel WSDL pubblicato mi sembra assente.

[vintra73]

Nell'analisi realizzata, considerato l'utilizzo di un MEP asincrono e che il riscontro di non applicazione dei datatype esula dagli errori applicativi, si è ritenuto opportuno per il msg ResponseMessaggioInoltroType di non prevedere 000_Irricevibilita

Si precisa che gli enum degli errori previsti sono solo relativi agli errori applicativi gestibili nella comunicazione mittente/destinatario, il ben formato dei msg è gestito a livello di protocollo SOAP e quindi della corretta applicazione del WSDL presente nell'allegato in oggetto

[asorcinelli]

Si è sicuramente vero: se un messaggio non è ben formato, non "passa" neanche e quindi quei casi sono gestiti a livello di SOAP.
Però poi ci possono essere errori dovuti ai dati inviati: il messaggio è corretto, ma i dati inviati no.
La validazione della firma e la verifica degli hash sono solo due casi. Ci potrebbero essere altre situazioni e altri dati non validi. Capisco che questi controlli "applicativi" non possono essere definiti e specificati tutti, ma se effettivamente fosse stato presente quel "000_Irricevibilita", si sarebbe potuto usare quel valore per comunicare al mittente anche queste problematiche.

[jackom83]

Salve, come già indicato da @vintra73 il pattern di interazione per lo scambio di un messaggio (MessaggioInoltro) e l'eventuale conferma(ConfermaMessaggioInoltro) è di tipo asincrono. Le anomalie (es. AnomalieInoltroType) che possono essere ritornate al mittente sono legate alla verifiche automatiche che possono essere realizzate prima di rispondere in maniera sincrona con una response soap (es. ResponseMessageInoltro) ad una specificia request soap (es. RequestMessageInoltro).

Inoltre queste (es. 001_ValidazioneFirma e 002_AnomaliaImpronte) riguardano il controllo di aspetti di sicurezza relativi alla segnatura, non aspetti di validazione inerenti il contenuto del messaggio.

[asorcinelli]

Mi è chiara l'impostazione che è stata data e mi è chiaro che le anomalie sono state pensate per essere legate a verifiche automatiche che possono essere effettuate subito, prima di rispondere in modo sincrono al mittente.
Però, dato che la conferma è opzionale, credevo che si potesse estendere questo "set" di verifiche automatiche. Oltre alla firma e alle impronte il sistema potrebbe verificare la presenza di campi obbligatori, la validità dei codici IPA etc. Insomma potrebbero esserci altri controlli automatici su altre condizioni per cui il messaggio dovrebbe essere per forza considerato non valido.
Tutto qu.