@@ -155,7 +155,7 @@ Prima di operare da server esso effettua una chiamata al nostro repository GitLa
In qualità di server si avvale di un threadPoolExecutor e per ogni nuova chiamata istanzia un nuovo Thread per servirla.
A seconda dell'URI richiamato viene istanziato un handler diverso, che verifica il token JWT grazie alla classe TokenHandler.
Per verificare che l'utente sia autenticato, viene effettuata una chiamata all'URI della nostra istanza di Keycloak per ottenere la chiave pubblica. Dopo di ciò il body del JWT che era stato precedentemente inviato nel payload della richiesta della Webapp viene firmato con la chiave pubblica e se il risultato è uguale alla firma inviata nel JWT stesso allora l'utente è verificato.
Per verificare che l'utente sia autenticato, viene effettuata una chiamata all'URI della nostra istanza di Keycloak per ottenere la chiave pubblica. Dopo di ciò la firma del JWT che era stato precedentemente inviato nel payload della richiesta della Webapp viene decifrata con la chiave pubblica e viene confrontato il risultato con l'hash(header.body) del JWT. Se il risultato è uguale allora l'utente è verificato. Il metodo che si occupa di ciò è verificaToken che si avvale dell'oggetto di tipo Verifier.
Confermata l'autenticazione dell'utente, è possibile ottenerne il nome utente e distinguere i domini di cui è utente comune o amministratore. A questo punto, a seconda dei servizi richiesti dalla Webapp, si aprono diversi scenari di interazione con il DB ed il CAM (Install, Delete, Start, Stop).
Le chiamate si risolvono una volta che il CAM manda la sua risposta, quindi possiamo considerare la chiamata al CAM incapsulata in termini di tempo all'interno della chiamata da parte della Webapp al DM.
