Client SOAP ed endpoints SdI

Buongiorno a tutti.

Nella procedura di accreditamento del canale viene richiesto di specificare gli endpoint per trasmissione/ricezione con relativi versioni di test.
La mia domanda è dunque rivolta a tutti coloro che hanno già effettuato tale richiesta e sono quantomeno in fase di testing:

Per endpoint di trasmissione s’intende l’URL al quale dev’essere implementato il server SOAP che riceve le notifiche (come specificato dal file TrasmissioneFatture_v1.1.wsdl)?

Per endpoint di ricezione s’intende l’URL al quale dev’essere implementato il server SOAP che riceve le fatture ed eventuali notifiche di decorrenza termini (come specificato dal file RicezioneFatture_v1.0.wsdl)?

Infine, posto che abbia capito bene, se tali sono gli endpoint, ciò significa che i client SOAP che si occupano di colloquiare con il SdI per l’invio delle fatture e le notifiche di esito (SdIRiceviFile_v1.0.wsdl e SdIRiceviNotifica_v1.0.wsdl in ruolo di client) possono anche risiedere in URL diversi fintanto che nella richiesta includano i certificati giusti?

Grazie mille per l’aiuto.

1 Mi Piace

Esattamente. Ricorda che gli endpoint non sono modificabili in futuro se non con una procedura che prevede un down del tuo canale di anche una settimana, cioè revoca (immediata) + nuovo accredito.

1 Mi Piace

Grazie mille… anche se ormai sono addirittura andato in produzione con il canale. :laughing:

Ciao,
dato che la richiesta per il certificato server richiede esplicitamente che “nel common name deve essere indicato il Codice Fiscale del Sottoscrittore preceduto da ‘SDI-’ (esempio: SDI-01234567891)” questo significa che nell’endpoint deve essere presente SDI-PIVA come nome host? Perché in caso contrario le chiamate https rilevano il problema “Il nome host del certificato di sicurezza del sito Web è diverso dal sito Web che si sta tentando di visitare”; é una cosa che si può trascurare?
Grazie

Sì, si può trascurare, perché il client del SdI non verifica il nome host, solo che il certificato sia quello che ti hanno dato.
Il problema ce l’avresti se sullo stesso host volessi far girare un applicativo web accessibile da browser, ma questo non lo puoi fare comunque perché la CA dell’AdE non è trusted.

Comunque mi pare che per il certificato server si possa mettere nel CN anche il nome del host. Almeno così dice nella pagina che permette di cambiare i certificati una volta accreditati:

Nota per la generazione delle CSR:

  • per la CSR client è richiesto che nel " cn " ( Common Name ) della richiesta sia indicato il Codice Fiscale del Sottoscrittore preceduto da ‘SDI-’ (SDI-SDI-02667080283)
  • per la CSR server si può scegliere se procedere come per la CSR client oppure se inserire all’interno del " cn " l’hostname del server che ospita il servizio.
1 Mi Piace

Grazie Vladan, lo chiedevo perché Microsoft (sto utilizzando IIS) insiste nel dire che il nome host nel certificato deve coincidere con l’endpoint richiamato. Sto chiedendo la loro assistenza perché il mio WCF, quando richiamato sotto mutua autenticazione, risponde correttamente con 200 (AdE considera superato il test quando chiama i miei metodi void) ma non esegue il codice che c’è nei metodi…. cosa che invece accade quando il WCF gira in http senza client certificate authentication

Purtroppo non ti so aiutare con IIS. Noi usiamo un load balancer per gestire l’SSL.
Una cosa che ho notato con WCF è che per i metodi OneWay (void) la risposta viene inviata immediatamente, prima di eseguire il metodo del web service.
Però questo credo sia una cosa che fa WCF e non IIS, mentre l’autenticazione dovrebbe stare a monte, dentro IIS. Ma non sono un esperto in materia.

Grazie Vladan, credo di aver capito qual è il mio problema per quanto riguarda la non esecuzione dei metodi: alla creazione dell’endpoint, il client deve specificare l’URI dell’endpoint completo di svc (p.e. EndpointAddress newEP = new EndpointAddress(“https://miodominio/WcfTestService/WcfTestService.svc”); in questo modo le chiamate dei metodi mappano correttamente le operazioni e, nel caso di metodi void, il server risponde 202. Purtroppo io ho dichiarato ad ADE come endpoint gli URI del tipo “https://miodominio/WcfTestService” e non credo che riuscirò a risolvere il problema con un semplice redirect…

Noi invece avevamo specificato come endpoint dei web service .asmx, per poi scoprire che i web service vecchia maniera (non WCF) non supportano MTOM.
Un redirect HTTP (3xx) non funziona, ma forse si riesce a fare un url rewrite interno. Purtroppo non so come si fa con IIS. Nel nostro caso, facendo passare tutto per un reverse proxy, abbiamo potuto rimappare gli url lì.

Ma sei già in produzione? Perché se sei ancora in fase di test, forse ti conviene annullare la richiesta di accreditamento e farne un’altra con gli endpoint giusti.

Io continuo a ribadire che il fatto che non si possano modificare gli url degli endpoint senza revocare il canale e rifare l’accreditamento (con tanto di test) sia un grosso problema, perché implica un down di un paio di giorni che nessuno che abbia dei clienti che usano il servizio può permettersi.

L’URL rewrite usa redirect, funziona se fai un reverse proxy che è completamente trasparente.

Come ho detto, non conosco IIS, ma in apache si possono fare sia rewrite “esterni” (con redirect), che “interni” (senza redirect).

1 Mi Piace

Grazie per i consigli,
ho deciso di annullare la richiesta e farne una con gli endpoint nuovi, che terminano con il file svc. E’ andato tutto bene, ho superato tutti i test. Sconsiglio il tentativo di redirect HTTP per chi, come me, lavora su IIS