Funzionalità Avanzate

La gestione dei pattern di sicurezza messaggio possono essere personalizzati su diversi aspetti:

• Attivazione di pattern di sicurezza messaggio differenti per la singola operazione: è possibile modificare i pattern di sicurezza messaggio applicati puntualmente solamente su una operazione.

• Attivazione della sicurezza messaggio su richiesta/risposta: è possibile attivare la sicurezza messaggio puntualmente solamente sulla richiesta o sulla risposta di una operazione. Per API REST è possibile anche definire dei criteri di applicabilità della sicurezza messaggio in base a Content-Type o codici di risposta HTTP.

• Header HTTP del token JWT: può essere selezionato l’header http utilizzato per veicolare il token JWT su API REST.

• Generazione del Token “JWT-Signature” per payload http vuoti: può essere attivata la generazione di un token “JWT-Signature” anche per richieste e/o risposte prive di payload, utilizzando come valore del Digest un body vuoto («»).

• Personalizzazione del Token “JWT-Signature”: può essere attivato un token “JWT-Signature” personalizzato per API REST.

• Payload Claims del token JWT: possono essere configurati ulteriori claims da aggiungere nel payload del JWT su API REST.

• Header SOAP aggiunti nella WSSecurity Signature: possono essere configurati ulteriori header soap da aggiungere agli elementi inclusi nella firma su API SOAP.

• Eliminazione token/header contenente la sicurezza messaggio: è possibile configurare GovWay al fine di non eliminare il token di sicurezza dai messaggi dopo averli validati.

• Keystore di firma in una fruizione di API: è possibile attivare differenti scenari di fruizione rispetto a quello di default che prevede l’associazione del keystore di firma sull’applicativo mittente.

• Finalità (purposeId) utilizzata per una fruizione di API: l’identificativo univoco della finalità, ottenuto dalla PDND, per cui si intende fruire di un servizio è configurabile in diverse modalità a seconda dello scenario che si desidera supportare.

• Intermediario: è possibile indicare un soggetto come intermediario. Questo consente di autorizzare una richiesta proveniente da un soggetto identificato sul canale (l’intermediario), che risulta differente dal soggetto a cui appartiene l’applicativo identificato tramite token di sicurezza.

• Recupero informazioni client tramite API PDND fallito: è possibile modificare il comportamento di default per far fallire la transazione in caso il recupero delle informazioni sul client o sull’organizzazione tramite API PDND fallisca.

• Politiche di Rate Limiting basate su informazioni prelevate via API PDND: le politiche di rate limiting consentono di conteggiare le richieste o filtrare anche rispetto alle informazioni prelevate dalla PDND.

• Configurazione avanzata dell’integrazione verso le API PDND: fornisce aspetti avanzati di configurazione dell’integrazione con la PDND.