User-Managed Access

Da Wikipedia, l'enciclopedia libera.

User-Managed Access (UMA) è un protocollo per la gestione degli accessi web basato su OAuth. Il protocollo è definito nella specifica (draft) versione 1.0. Una specifica corrispondente definisce gli obblighi dei soggetti legalmente responsabili che sono coinvolti nell’interazioni conformi ad UMA. L’impegno di incubare lo sviluppo di UMA come standard web si svolge nell'organizzazione Kantara Initiative.

UMA esplora diverse ipotesi. Uno è che il consenso run-time è uno strumento debole e scomodo per esercitare il controllo dell'utente per la condivisione di informazioni sensibili. Un altro è che la gestione delle connessioni per la condivisione dei dati tra un server singolo e una singola applicazione client alla volta non scala, in generale, per l’uso di Internet . Un altro è che la legittimazione individuale e la valorizzazione della privacy richiedono un controllo e una visibilità sulla condivisione dei dati con una varietà di soggetti, non solo con le applicazioni che l'individuo stesso utilizza.

Di conseguenza, il design di UMA si concentra sulla definizione di come un utente web fa uso di un'applicazione web chiamata Authorization Server (AS) per coordinare la protezione e la condivisione di risorse web che sono sotto il controllo dell’utente stesso. Le risorse web potrebbe risiedere in qualsiasi numero di server, che UMA chiama Resource Server (RS). Soggetti richiedenti, che possono includere il proprietario originale delle risorse (Resource Owner) così come altre persone o organizzazioni, possono accedere alle risorse protette tramite applicazioni client, purché tali parti rispettano le politiche autorizzative del proprietario della risorsa che risiedono presso l’AS.

Storia e contesto[modifica | modifica sorgente]

Il  Gruppo di lavoro UMA[1] di Kantara Initiative ha tenuto la sua prima riunione[2] il 6 agosto 2009. I principi di progettazione di UMA e design tecnico sono stati fondati sul precedente lavoro da parte di dipendenti di Sun Microsystems, iniziato nel marzo 2008, su un protocollo chiamato ProtectServe . A sua volta, ProtectServe è stato influenzato dagli obiettivi del movimento Vendor Relationship Management (VRM) e dalla sua ramificazione chiamato feed-based VRM .

Le prime versioni di ProtectServe e UMA sfruttavano il protocollo OAuth 1.0. Dato che OAuth ha subito cambiamenti significativi attraverso la pubblicazione delle specifiche Web Resource Authorization Protocol (WRAP) e, successivamente, la bozze di OAuth 2.0 , la specifica UMA ha tenuto il passo, ed ora utilizza la famiglia delle specifiche OAuth 2.0 per i vari flussi chiave del protocollo.

UMA non usa e ne dipende da OpenID 2.0 come mezzo di identificazione utente. Tuttavia, usa opzionalmente il protocollo OpenID Connect basato su OAuth, come strumento di raccolta di attestazioni di identità di un soggetto richiedente, al fine di tentare di soddisfare i criteri di accesso dell'utente che autorizza.

UMA, inoltre, non usa ne dipende dalla specifica eXtensible Access Control Markup Language (XACML) come mezzo di codifica delle politiche di autorizzazione dell’utente o per richiedere decisioni su politiche autorizzative . UMA non definsce il formato politiche di autorizzazione, dato che la valutazione delle politiche/criteri viene effettuata internamente all’Authorization Server, dal punto di vista UMA . Tuttavia, i flussi del protocollo i flussi UMA, per richiedere il permesso di accesso hanno alcune caratteristiche in comune con il protocollo XACML.

Stato della standardizzazione[modifica | modifica sorgente]

Lo statuto di UMA WG si rivolge ad Internet Engineering Task Force (IETF) come eventuale sede per lavori di standardizzazione di UMA. A tal fine, il gruppo di lavoro ha contribuito con diversi singoli Internet-Drafts all'IETF per presa in esame. Uno di questi, una specifica per Oauth Dynamic Client Registration[3], è stato accettato come un elemento di lavoro per il Web Authorization (OAuth) Working Group.

Stato implementazioni ed adozione[modifica | modifica sorgente]

Il nucleo del protocollo UMA ha diverse implementazioni. Gluu ha implementato UMA nel loro stack di prodotti di gestione identità ed accessi, utilizzando il protocollo UMA per proteggere e gestire l'accesso alle API[4]. Cloud Identity Limited ha una implementazione UMA completa per proteggere e gestire l'accesso alle informazioni personali come pure alle web API. Un certo numero di altri attori hanno segnalato l'interesse per implementare UMA e stanno partecipando ai test di interoperabilità.

Note[modifica | modifica sorgente]

  1. ^ http://kantarainitiative.org/confluence/display/uma/Home UMA Work Group Wiki
  2. ^ http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes?src=contextnavchildmode UMA workgroup meeting minutes
  3. ^ http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg Internet Draft: OAuth 2.0 Dynamic Client Registration Core Protocol
  4. ^ http://www.gluu.org/open-source/open-source-vs-on-demand/ Gluu OSS implementation of UMA

Collegamenti esterni[modifica | modifica sorgente]