Erogazione ID_AUTH_REST_01 (PDND)

In un’erogazione di una API 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 associato all’operazione invocata: verifica firma, validazione temporale, filtro duplicati, verifica integrità del messaggio, verifica del token di audit etc.

Nella figura “Fig. 180” viene raffigurato lo scenario di erogazione in cui il trust avviene tramite la PDND.

Di seguito vengono descritti tutti i passi di configurazione specifici per l’implementazione del pattern “ID_AUTH_REST_01” mentre si rimanda alla sezione “Profilo “API Gateway”” per la normale registrazione e configurazione di un’erogazione di API.

API

La registrazione della API deve essere effettuata agendo nella sezione «ModI - Sicurezza Messaggio», come indicato in Fig. 181:

• selezionare il “Pattern” «ID_AUTH_REST_01»;

• selezionare una “Generazione Token” di tipo “Authorization PDND” per far si che il Token “ID_AUTH” sia negoziato con la PDND.

Token Policy di Validazione

Per la configurazione di una erogazione con un pattern di sicurezza via PDND viene fornita built-in la token policy “PDND” di cui deve essere stata effettuata la configurazione come descritto nella sezione “Trust tramite PDND”.

Erogazione

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.

L’associazione avviene direttamente durante la creazione dell’erogazione come mostrato nella figura Fig. 182.

Verifica Audience

Per verificare l’audience presente nel token ricevuto dalla PDND deve essere utilizzata l”Autorizzazione per Token Claims definendo il claim “aud” uguale al valore atteso (Fig. 183).

Identificazione ed Autorizzazione dei fruitori

È possibile registrare gli applicativi dei domini esterni al fine di:

1. identificare puntualmente le componenti esterne coinvolte nella comunicazione abilitando le funzionalità di tracciamento e statistica per tali elementi.

2. abilitare le funzionalità di autorizzazione sugli applicativi identificando puntualmente chi autorizzare dopo il superamento del processo di validazione del token ricevuto (Fig. 188).

Rispetto a quanto descritto nella sezione “ID_AUTH_SOAP_01 / ID_AUTH_REST_01 - Direct Trust con certificato X.509” il token ricevuto 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 ID_AUTH_REST_01 / ID_AUTH_SOAP_01 (X509)” e “Erogazione ID_AUTH_REST_01 / ID_AUTH_SOAP_01 (X509)”, non è più necessaria mentre si dovranno fornire i dati relativi al token OAuth (Fig. 184) o in alternativa aggiungendo tali dati a quelli relativi al certificato (Fig. 185).

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. 186).

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. 188). In alternativa è possibile definire i ruoli che gli applicativi devono possedere.