{"id":334,"date":"2021-11-09T15:12:54","date_gmt":"2021-11-09T14:12:54","guid":{"rendered":"http:\/\/159.213.227.18\/wordpress\/?p=334"},"modified":"2021-11-10T10:26:27","modified_gmt":"2021-11-10T09:26:27","slug":"integrazione-di-servizi-al-sistema-di-autorizzazione-regionale","status":"publish","type":"post","link":"http:\/\/159.213.227.18\/wordpress\/it\/integrazione-di-servizi-al-sistema-di-autorizzazione-regionale\/","title":{"rendered":"L&#8217;uso degli &#8216;scope&#8217; dei token ARPA per l&#8217;accesso alle API del CART"},"content":{"rendered":"\n<p>Lo schema seguente mostra il ruolo degli API Gateway del CART nei processi di autenticazione ed autorizzazione all&#8217;accesso alle API da parte delle applicazioni client.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" width=\"548\" height=\"484\" src=\"http:\/\/159.213.227.18\/wordpress\/wp-content\/uploads\/2021\/11\/immagine.png\" alt=\"\" class=\"wp-image-337\"\/><\/figure>\n\n\n\n<p>Gli applicativi fruitori possono utilizzare due diversi paradigni di autenticazione:<\/p>\n\n\n\n<ul><li>uso di credenziali TLS, fornite direttamente dal client tramite protocollo https (MTLS);<\/li><li>token di accesso rilasciati dagli Authorization Server di ARPA.<\/li><\/ul>\n\n\n\n<p>L&#8217;accesso mediante protocollo https prevede che sussista una relazione di trust tra applicativo fruitore ed API Gateway del CART, che viene preventivamente stabilito in fase di richiesta di adesione al servizio tramite lo scambio dei certificati. Il CART \u00e8 cos\u00ec in grado di identificare puntualmente l&#8217;applicativo ed applicare i criteri di autorizzazione previsti per l\u2019accesso alle API sulla base dell\u2019identit\u00e0 del client fruitore.<\/p>\n\n\n\n<p>L\u2019accesso mediante token OAuth2 prevede invece che il client ottenga un &#8216;access token&#8217; dagli Authorization Server di ARPA, da utilizzare come credenziale per l&#8217;accesso alle API del CART.<\/p>\n\n\n\n<p>In questo articolo ci focalizziamo su questa seconda modalit\u00e0 di accesso, per discutere come sia possibile utilizzare alcune informazioni aggiuntive contenute nei token Oauth2 per ottenere modalit\u00e0 evolute di autorizzazione all\u2019accesso alle API, sulla base dei ruoli degli utenti.<\/p>\n\n\n\n<h2>L\u2019uso degli Scope per il controllo degli accessi alle API<\/h2>\n\n\n\n<p>Lo \u2018scope\u2019 \u00e8 uno specifico parametro del token ottenuto da ARPA, il cui valore indica le finalit\u00e0 per cui il token viene rilasciato. Questo parametro viene utilizzato sulla piattaforma CART per permettere di differenziare l\u2019accesso a diverse risorse della stessa API, in funzione dei ruoli degli utenti dell&#8217;Applicazione Client.<\/p>\n\n\n\n<p>Possiamo ad esempio considerare l&#8217;accesso ad una API del fascicolo sanitario, che permetta ai cittadini di accedere esclusivamente in lettura ai propri dati sanitari e ai medici di accedere anche in scrittura. Si tratta ovviamente di una estrema semplificazione, ma utile ad esprimere il concetto.<\/p>\n\n\n\n<p>Come primo step, l&#8217;interfaccia della API dovr\u00e0 essere progettata per distinguere le API a cui possono accedere i cittadini da quelle a cui possono accedere solo i medici. Il progettista pu\u00f2 quindi definire due diversi valori di scopo dei token, ad esempio &#8216;fascicolo-consulta&#8217; e &#8216;fascicolo-modifica&#8217;, e assegnare ad ogni risorsa lo &#8216;scope&#8217; necessario per l&#8217;accesso. Immaginando che l&#8217;interfaccia sia espressa tramite lo standard OpenAPI, questa indicazione pu\u00f2 essere fornita utilizzando la funzionalit\u00e0 dei \u2018security scheme\u2019 di OpenAPI che permette di associare specifici valori dello \u2018scope\u2019 del token alle singole risorse della API.<\/p>\n\n\n\n<p>Successivamente, al momento della richiesta di registrazione dell\u2019API su CART, il richiedente, oltre a fornire l&#8217;interfaccia OpenAPI, dovr\u00e0 indicare, per ogni valore dello scope previsto dalla propria API, il ruolo o la combinazione di ruoli e di attributi utente necessari per il rilascio di quel valore nei token di accesso. Nel nostro esempio potr\u00e0 quindi indicare che il valore &#8216;fascicolo-consulta&#8217; potr\u00e0 essere rilasciato a tutti i cittadini, mentre il valore &#8216;fascicolo-modifica&#8217; dovr\u00e0 essere rilasciato solo a utenti con il ruolo &#8216;medico&#8217;.<\/p>\n\n\n\n<p>L&#8217;applicazione client, al momento della richiesta del token, potr\u00e0 utilizzare le modalit\u00e0 standard previste da OAuth2 per richiedere ad ARPA che lo \u2018scope\u2019 venga popolato con i valori necessari per l\u2019accesso alle API di proprio interesse, nel nostro caso &#8216;fascicolo-consulta&#8217; e &#8216;fascicolo-modifica&#8217;.<\/p>\n\n\n\n<p>ARPA, dopo aver autenticato l\u2019utente, verificher\u00e0 se l\u2019utente abbia o meno i ruoli per ottenere i valori di &#8216;scope&#8217; richiesti, facendo riferimento al mapping tra scope e attributo indicati in fase di richiesta di registrazione dell\u2019API. <\/p>\n\n\n\n<p>L\u2019applicazione client otterr\u00e0 quindi un token con un valore di &#8216;scope&#8217; che sar\u00e0 popolato con l&#8217;elenco &#8220;&#8216;fascicolo-consulta&#8217;, &#8216;fascicolo-modifica&#8217;&#8221; per i medici e con il solo &#8216;fascicolo-consulta&#8217; per il resto degli utenti.<\/p>\n\n\n\n<p>L&#8217;applicazione client potr\u00e0 ora invocare le API del fascicolo esposte dal CART utilizzando il token ottenuto da ARPA. I gateway del CART verificheranno che il token sia valido e che lo \u2018scope\u2019 contenga il valore previsto per l\u2019accesso alla specifica risorsa invocata; solo in questo caso l\u2019accesso alla API sar\u00e0 consentito.<\/p>\n\n\n\n<p>Di fatto, utilizzando lo \u2018scope\u2019 del token, \u00e8 stato possibile realizzare una autorizzazione per ruolo nell\u2019accesso alle risorse di una API.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Lo schema seguente mostra il ruolo degli API Gateway del CART nei processi di autenticazione ed autorizzazione all&#8217;accesso alle API da parte delle applicazioni client. Gli applicativi fruitori possono utilizzare due diversi paradigni di autenticazione: uso di credenziali TLS, fornite direttamente dal client tramite protocollo https (MTLS); token di accesso rilasciati dagli Authorization Server di [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":381,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[22],"tags":[],"_links":{"self":[{"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/posts\/334"}],"collection":[{"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/comments?post=334"}],"version-history":[{"count":13,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/posts\/334\/revisions"}],"predecessor-version":[{"id":373,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/posts\/334\/revisions\/373"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/media\/381"}],"wp:attachment":[{"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/media?parent=334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/categories?post=334"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/tags?post=334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}