ID_AUTH_SOAP_02 / ID_AUTH_REST_02
Il pattern ID_AUTH nelle sue varie declinazioni della versione “02” ha lo scopo, oltre a identificare e autorizzare l’accesso del fruitore ad un servizio, anche quello di evitare Replay Attack poichè ogni richiesta non può essere nuovamente processata.
Analizzando il pattern rispetto al tipo di trust:
trust tramite PDND: in attesa di ulteriori indicazioni, il pattern non sembra essere utilizzabile con un trust tramite PDND, poichè richiederebbe una negoziazione di un nuovo token per ogni richiesta per garantirne l’univocità.
trust tra fruitore ed erogatore tramite certificati X509: descritto nella sezione “ID_AUTH_SOAP_02 / ID_AUTH_REST_02 - Direct Trust con certificato X.509 con unicità del messaggio/token” differisce nella sostanza se applicato per API REST, in cui viene prodotto un token JWT con identificativo univoco inserito nel claim “jti”, o per API SOAP, in cui viene definito un header SOAP WSSecurity e un identificativo univoco presente nell’header SOAP WSAddressing:MessageID. In entrambi i casi il certificato del mittente viene inserito all’interno del token di sicurezza e validato dall’erogatore tramite un trustStore contenente i certificati X509 attesi.