Comunicazione tra fruitore ed erogatore che assicuri a livello di messaggio:
- accesso del soggetto fruitore, quale organizzazione o unità organizzativa fruitore, o entrambe le parti…
…continua a leggere su docs.italia.it
Buongiorno, vorrei proporre una riflessione relativa al fatto che mi pare che, per come sono definiti i profili [ID_AUTH_REST_01] Direct Trust con certificato X.509 su REST e [ID_AUTH_REST_02] Direct Trust con certificato X.509 su REST con unicità del token/messaggio, verrebbe esclusa la possibilità di usare oltre a quanto specificato nelle LG sul MODI, lo standard OAUTH 2 per ‘securizzare’ le API.
Infatti, per il token da inserire nell’HTTP header “Authorization” bisognerebbe valutare l’eventuale problema causato dall’omonima con il token usato (peraltro con scopi simili ma non coincidenti) nella specifica dello standard OAUTH 2.0. Per una descrizione dell’uso del token in OAUTH 2.o si veda ade esempio alla pagina: https://tools.ietf.org/html/rfc6750#section-2.1
Per chiarire il problema, si pensi a quanto avviene nelle piattaforme di security, ed in particolare quelle usate per ‘proteggere’ le API: quando una API è esposta in modo tale da implementare gli schemi di security di OAUTH 2.0, le piattaforme di security assegnano al token Authorization un significato in linea con lo standard e lo trattano come tale. L’uso di quel nome specifico, ma con significato diverso, impatta sul meccanismo predefinito dall’eventuale piattaforma di security che, se configurata per proteggere un’API con AUTH 2.0 e ricevendo nella chiamata un header con il nome indicato, applicherebbe le azioni previste dallo standard, che però non coincidono con quelle applicate nel caso delle LG AGID, rilevando un problema di security anche quando inesistente. La conseguenza è che, quando vengono applicate le indicazioni di MODI, non può essere applicato il comportamento di default che le piattaforme di security applicherebbero in linea con lo standard OAUTH 2.0.
Inoltre, dal punto di vista dei contenuti del token, si ha un ulteriore differenza di impostazione tra MODI e OAUTH 2.0. Infatti, nel caso di MODI il token trasporta informazioni che l’espositore dovrà verificare, mentre nel caso di OAUTH 2.0 il contenuto del token è opaco all’espositore, in quanto la responsabilità della sua eventuale gestione è demandata ad uno specifico componente architetturale, l’Authorization Server.
In sintesi, per rispettare le direttive definite da AgID, è necessario rinunciare all’utilizzo di OAUTH 2.0 per ‘securizzare’ le API e alle funzionalità predefinite delle piattaforme di security che lo supporterebbero, anche se, a parte il problema di omonimia dell’header descritto, si potrebbe avere, in linea teorica e se non sfuggono questioni specifiche, la convivenza di MODI e OAUTH 2.0.
Bisognerebbe perciò perlomeno chiarire che la scelta di escludere OAUTH 2.0 come meccanismo ulteriore rispetto a quelli indicati nelle LG su MODI è stata ponderata e quali sono i motivi, visto che, a prima vista, non sono evidenti problemi certi derivanti dall’uso contemporaneo dei meccanismi di security previsti dalle LG su MODI e di quelli previsti in OAUTH 2.0.
Si consideri infine che per rendere possibile tale contemporaneità sarebbe sufficiente rinominare nelle LG su MODI il nome dell’header http, chiamandolo ad esempio ‘Agid-JWT-Authorization’ in assonanza a quanto fatto per il token ‘Agid-JWT-Signature’ usato per la verifica dell’integrità dei messaggi.
Cordiali saluti,
Corrado Tamietti
2 Mi Piace
Ciao Corrado,
Da quello che leggo sulle LG, l’introduzione di “x5c” negli (jose) headers è conforme a quanto riportato in https://tools.ietf.org/html/rfc7515.
Sicuramente mi sfugge qualcosa e ulteriori interazioni con te mi aiuteranno a capire meglio la problematica che stai esponendo. Dalla mia esperienza OAuth2 è un autentico framework, le soluzioni adottate possono essere arricchite di tante “estensioni” così come proposte dagli molteplici rfc che riguardano OAuth2 e Jose. Piuttosto le attuali LG mi sembrano abbastanza standard e “asciutte”.
Non saprei se introdurre un HTTP Header personalizzato possa essere una soluzione percorribile. Sono certo che mi sfugge qualcosa, parliamone.
Buongiorno Giuseppe,
grazie 1000 per l’attenzione.
In effetti dagli elementi della tua risposta mi sembra che un ulteriore chiarimento possa essere utile.
Tralascio la questione dell’opacità, che è in realtà poco rilevante.
Il problema dell’impossibilità di far convivere pattern MODI e OAUTH deriva dalla omonimia del token che entrambe gli approcci usano ma con ‘significati’ diversi.
Schematizzando, se potremo confrontarci, cercherei di affrontare questi punti:
- l’esclusione di OAUTH è stata una scelta ponderata? in questo caso sarebbe bene che fossero resi espliciti i motivi.
- Il token denominato ‘Authorization’ che è stato proposto di usare come http header, anche se segue lo standard JWT, è di fatto composto in modo tale da rappresentare un elemento specifico dell’ambito MODI. Tornando al caso delle piattaforme di interoperabilità, ad esempio gli API Manager, queste piattaforme non sanno ‘nativamente’ come trattare e verificare quel token e devono essere perciò ‘configurate’ per trattarlo in modo specifico. Se non mi sfugge nulla, da questo punto di vista, usare il nome ipotizzato o un altro nome non fa differenza, perchè le implementazioni che trattano il token devono essere comunque specifiche.
Ciò non vale se aggiungiamo al layer MODI quello OAUTH, come alcune PA, o altri soggetti, potrebbero scegliere di fare (a meno di indicazioni contrarie). In questo secondo caso le piattaforme, che normalmente supportano nativamente OAUTH 2, quando sono configurate per farlo, si attendono per il token ‘Authorization’ significato e contenuti specifici descritti in quello standard. Considerando uno dei punti che indichi, una soluzione che si potrebbe valutare è usare i meccanismi di estensione di OAUTH 2 per verificare se si può in quel caso definire un token adatto sia per MODI che per OAUTH, ma a prima vista mi pare difficile.
Alternativamente, tornando alla mia proposta, se vogliamo fare convivere i due casi descritti, se non mi sfugge nulla, rinominare il token specifico MODI, come peraltro è stato già fatto nell’altro caso che citavo, quello del token di verifica dell’integrità del messaggio, è un’opzione che potrebbe essere valutata.
Per ogni altro chiarimento sarà un piacere confrontarmi con te; la mia mail è corrado.tamietti “chiocciola” csi.it
Contattami liberamente in qualsiasi momento.
A presto e buona giornata,
Corrado Tamietti
Anch’io faccio notare la mia perplessità sull’esclusione dello standard OAUTH.
Oltre alla considerazione di Corrado, che ritengo molto interessante, propongo anche una modalità ibrida di utilizzo, anche per diminuire traffico di rete (che comprenderebbe ad ogni chiamata il passaggio di un eventuale certificato) e il carico computazionale per la verifica del certificato. In dettaglio: una chiamata all’endpoint di un identity provider per il rilascio dell’access token tramite le indicazioni ID_AUTH_REST_XX (eventualmente modificato con un header custom come indicato da Corrado), e successivamente, nelle chiamate successive alle API, l’utilizzo dell’access token rilasciato.
1 Mi Piace
Buongiorno a tutti,
vorrei aggiornare gli interessati sul tema, a seguito del confronto con i riferimenti del Team Digitale e di AGID. Il confronto è stato utile ed ha portato a chiarire alcuni punti, che sintetizzo di seguito (ometto per brevità altri dettagli):
Motivazioni della richiesta: l’applicazione di OAUTH2, che propongo di usare come layer di security ulteriore ed in nessun modo sostitutivo rispetto a MODI, consentirebbe di sfruttare le feature di queto standard, particolarmente efficaci nella definizione di schemi di authorization anche sofisticati. Le principali caratteristiche di OAUTH2 che offrono questa possibilità sono (l’elenco che segue non è completo): possibilità di avere un livello di granularità fine della autorizzazione, che può arrivare fino alla singola applicazione fruitrice (invece del soggetto fruitore o sua unità organizzativa), uso degli scope (ad esempio per distinguere diritti di accesso in lettura e scrittura o a diverse categorie di dati) e uso dei claims (attraverso i quali il token OAUTH2 può trasportare informazioni sul fruitore utili per applicare logiche di autorizzazione specifiche che dipendono dalle sue caratteristiche). Questi sono temi non compresi-in e non in contrasto-con quelli di MODI.
Impossibilità della compresenza MODI – OAUTH2: per come sono definiti i profili [ID_AUTH_REST_01] Direct Trust con certificato X.509 su REST e [ID_AUTH_REST_02] Direct Trust con certificato X.509 su REST con unicità del token/messaggio, viene esclusa la possibilità di usare, oltre a quanto specificato nelle Linee Guida sul MODI, lo standard OAUTH2 per la security delle API. Questa impossibilità di compresenza dipende dal fatto che, per come è definito il token che le linee guida MODI prescrivono di porre nell’header http ‘Authorization’, viene di fatto usato lo stesso authentication scheme ‘Bearer’, definito nell’ambito OAUTH2 ( https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml ), provocando un conflitto di standard all’atto non superabile. Anche gli altri schemi di applicazione che OAUTH2 non sono compatibili con quanto indicato da MODI. Ad esempio, i token JWT self contained OAUTH2 (che sono un’alternativa che è stata considerata nella discussione) contengono informazioni simili al token MODI ma, richiedendo quest’ultimo (almeno nella versione corrente) la firma del ‘soggetto fruitore’, questa scelta comporta una incompatibilità con l’approccio OAUTH2. La possibilità del token JWT OAUTH2 self contained rimane una interessante possibilità, al momento però non applicabile, che potrà essere considerate solo nelle eventuali evoluzioni di MODI nelle quali venga ammesso un approccio compatibile con quello OAUTH2.
Analisi (relativa) dei rischi: una obiezione all’uso di un token OAUTH2 che potrebbe, ma solo ad una prima vista, suscitare preoccupazione, è la seguente. Se non si sceglie accuratamente il formato del token OAUTH, un agente malintenzionato potrebbe intercettarlo ed utilizzarlo per scopi fraudolenti. Questa preoccupazione può essere facilmente superata con una analisi relativa dei rischi indotti dalla variazione che ho proposto: poiché lo schema suggerito comporta che OAUTH2 sia usato come layer di sicurezza ulteriore ed in nessun modo sostitutivo delle indicazioni MODI, la variazione non può comportare rischi non presenti quando si applichino le sole indicazioni MODI, in quanto comporta una restrizione e non un rilassamento dei vincoli di sicurezza imposti da MODI (con la convivenza MODI + OAUTH2, un eventuale agente fraudolento dovrebbe superare i controlli previsti da entrambi gli standard invece che i soli controlli previsti da MODI). Inoltre, questo vale indipendentemente dal formato del token.
Conclusioni e conferma della richiesta: in base a quanto ho riportato, considerando che l’impatto che ne deriverebbe è molto limitato e che offrirebbe solo una possibilità in più rispetto a quanto stabilito dall’attuale versione delle linee guida MODI, senza variare quanto già era previsto per chi preferisse continuare a farlo, ribadisco la richiesta di indicare nelle linee guida MODI che per il token MODI può essere usato, oltre ad ‘Authorization’, un nome alternativo (non sostitutivo), ad esempio ‘Agid-JWT-Authorization’, che permetta di superare i conflitti relativi al nome e all’authorization scheme definiti in OAUTH 2.0 e, in questo modo, la possibilità (non l’obbligatorietà) di compresenza dei due standard nei casi in cui le parti interoperanti concordino questa scelta.
Corrado Tamietti - CSI Piemonte