Erogazione (PDND)¶

Nelle erogazioni, le richieste provengono da amministrazioni esterne al dominio e sono dirette ad applicativi interni. Prima di procedere con l’inoltro della richiesta verso il backend interno, GovWay valida il token di sicurezza ricevuto rispetto al pattern descritto nella sezione ID_AUTH tramite la Piattaforma Digitale Nazionale Dati (PDND).

Per la configurazione di una erogazione con un pattern di sicurezza via PDND è necessario registrare una “Token Policy Validazione” con le seguenti caratteristiche:

• Token:

  • Tipo: JWS

  • Posizione: RFC 6750 - Bearer Token Usage (Authorization Request Header Field)

• Validazione JWT:

  • Formato Token: RFC 9068 - JSON Web Token (OAuth2 Access Token)

  • TrustStore: deve contenere il certificato utilizzato dalla PDND per firmare i token

Con il prodotto viene fornita built-in la token policy “PDND” (Fig. 176) da finalizzare nella sezione “TrustStore” nei seguenti aspetti:

• File: deve essere indicato un path su file system che contiene il certificato di firma della PDND ottenibile tramite la url “…/.well-known/jwks.json” fornita dalla PDND stessa;

• Alias Certificato: deve contenere l’alias (il kid) della chiave pubblica utilizzata dalla PDND per firmare i token rilasciati, corrispondente al valore del claim “kid” presente nel JWKSet configurato al punto precedente.

Fig. 176 Token Policy PDND¶

Una volta effettuata la registrazione della Token Policy, per utilizzarla in un’erogazione è necessaria attivarla come policy di autenticazione token nel controllo degli accessi come descritto nella sezione Autenticazione Token.

Il processo di autenticazione token assicura la validità del token ricevuto.

L’adozione del pattern ID_AUTH_REST_01 rilasciato dalla PDND consente alla ricezione di un messaggio di effettuare i medesimi controlli attuati su un token conforme al pattern descritto nella sezione “[ID_AUTH_SOAP_01 / ID_AUTH_REST_01] Direct Trust con certificato X.509” con la differenza che il token non è più firmato dall’applicativo mittente ma bensì dall’authorization server della PDND e l’identificazione dell’applicativo chiamante non è più attuabile tramite il certificato fornito nell’header del JWT tramite claim “x5c/x5t/x5u” ma bensì tramite l’identificativo presente nel claim “client_id”. Per poter identificare gli applicativi chiamanti la modalità di caricamento del certificato di firma, descritto nelle sezioni “Fruizione” e “Erogazione”, non è più necessaria mentre si dovranno fornire i dati relativi al token OAuth (Fig. 177) o in alternativa aggiungendo tali dati a quelli relativi al certificato (Fig. 178).

Fig. 177 Dati ModI relativi ad un applicativo esterno con configurazione token PDND¶

Fig. 178 Dati ModI relativi ad un applicativo esterno con configurazione sia del certificato di firma che del token PDND¶

Una configurazione simile è attuabile anche sugli applicativi di dominio interno per poterli riconoscere su installazioni Multi-Tenant (“Multi-Tenant”) dove sia il tenant fruitore che quello erogatore viene gestito sullo stesso GovWay (Fig. 179).

Fig. 179 Dati ModI relativi ad un applicativo interno con configurazione token PDND¶

Fig. 180 Dati ModI relativi ad un applicativo interno con configurazione sia del certificato di firma che del token PDND¶

Una volta registrati gli applicativi client è possibile attuare criteri di autorizzazione dei singoli applicativi accedendo alla configurazione della sezione «Controllo Accessi» e attivando la sicurezza messaggio. Sarà possibile specificare un elenco puntuale di applicativi autorizzati (Fig. 181). In alternativa è possibile definire i ruoli che gli applicativi devono possedere.

Fig. 181 Autorizzazione di singoli applicativi token per l’accesso all’erogazione¶

Per verificare l’audience presente nel token ricevuto dalla PDND è invece possibile utilizzare l”Autorizzazione per Token Claims definendo il claim “aud” uguale al valore atteso (Fig. 182).

Fig. 182 Autorizzazione di singoli applicativi token per l’accesso all’erogazione¶