User-Managed Access

User-Managed Access (UMA) è un protocollo standard di gestione degli accessi basato su OAuth. La versione 1.0 dello standard è stato approvato dal Kantara Initiative il 23 marzo 2015.

Come descritto dalla statuto del gruppo che ha sviluppato UMA, lo scopo delle specifiche del protocollo è quello di "consentire ad un proprietario di risorsa di controllare l'autorizzazione della condivisione dei dati ed altri accessi alla risorsa protetta tra servizi online per conto del proprietario o con l'autorizzazione del proprietario, da una parte richiedente autonoma". Questo scopo ha implicazioni sulla privacy e sul consenso per applicazioni web e Internet of Things (IoT), come esplorato dalla raccolta di casi di studio, contribuito dei partecipanti al gruppo standard.

Storia e contesto

Kantara Initiative's UMA Work Group ha tenuto la sua prima riunione 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

Il gruppo UMA svolge il suo lavoro nell'ambito di Kantara Initiative e ha contribuito anche una serie di specifiche Internet-Draft ad Internet Engineering Task Force (IETF) come un'eventuale sede per lavori di standardizzazione di UMA. A tal fine, il gruppo di lavoro ha contribuito a diversi Internet Draft individuali a IETF per considerazioni. Una di queste, una specifica per “OAuth dynamic client registration”, è servita come input per il meccanismo più generalizzato, infine sviluppato per OAuth.

Stato implementazioni ed adozione

Il nucleo principale del protocollo UMA ha diverse implementazioni, tra cui diverse implementazioni open source. Sorgenti di attive e disponibili implementazioni open-source includono, in ordine alfabetico, ForgeRock, Gluu, MITREid Connect, and Roland Hedberg. Un gruppo di lavoro a Kantara Initiative sta lavorando allo sviluppo di "software libero ed open source (FOSS), in diversi linguaggi di programmazione, che consente agli sviluppatori di incorporare API di protezione e autorizzazione UMA in applicazioni, servizi e dispositivi"

Prodotti abilitati UMA sono disponibili da Gluu and Jericho Systems e imminente da ForgeRock.

Contronto con OAuth 2.0

Questo diagramma fornisce una visione d'insieme di alto livello delle entità e delle relazioni coinvolte nelle specifiche UMA.

Il diagramma (Vedi a destra) evidenzia i principali ampliamenti che UMA fa a OAuth 2.0. In un tipico flusso di OAuth, un (umano) Resource Owner (RO) che opera su un'applicazione cliente, viene reindirizzato su un “Authorization Server” (AS) per accedere e dare il consenso all'emissione di un “token di accesso” con il quale il client può ottenere l'accesso al Resource Server (RS) per conto di RO in futuro, presumibilmente in modo limitato in base all'ambito (“scoped”). RS e AS, con ogni probabilità, operano all'interno dello stesso dominio di sicurezza, e qualsiasi comunicazione tra loro è non standardizzata dalla specifica principale OAuth.

UMA aggiunge tre concetti principali e le strutture ed i flussi corrispondenti. In primo luogo, esso definisce un API standardizzata a livello di AS, chiamata “Protection API”, con cui il Resource Server è in grado di interagire; Ciò consente a più RS di comunicare con un AS e viceversa e poiché l'API è essa stessa resa sicura con OAuth, consente di stabilire la relazione di fiducia formale tra ogni coppia. Questo consente anche all'AS di presentare al RO con un'interfaccia utente centralizzata. In secondo luogo, UMA definisce una nozione formale dell'entità “Requesting Party” (RqP) che è autonoma da un RO, consentendo una condivisione da un soggetto ad un'altra entità e la delega della autorizzazione di accesso. Un RO non deve dare il consenso al rilascio del token in fase di esecuzione ma può impostare dei criteri sull'AS, permettendo ad un RqP di tentare di accedere in modo asincrono. In terzo luogo, UMA consente di gestire il processo autorizzativo e quindi emissione di token associato a dati di autorizzazione basato su un processo di elevazione del livello di fiducia del RqP, ad esempio attraverso la raccolta di attestazioni di identità o altri crediti direttamente dal RqP.

Use Case Applicabili

L'Architettura di UMA può servire ad una varietà di casi d'uso sia rivolto verso consumatori che casi aziendali. Il gruppo UMA raccoglie studi di caso nel relativo wiki.

Un insieme di esempi di casi d'uso è nell'ambito assistenza sanitaria e sulla salute dei consumatori. Nell'organizzazione di OpenID Foundation, un gruppo di lavoro chiamato “Health Relationship Trust (HEART) sta lavorando per "armonizzare e sviluppare un insieme di specifiche di sicurezza e privacy che permettono ad un individuo di controllare l'autorizzazione di accesso ai dati sanitari basato su RESTful API per la condivisione", basato, tra altri standard, su UMA.

Un altro insieme di casi d'uso, che originalmente hanno influenzato lo sviluppo di UMA, è nella area dei “personal data stores”, basato sul paradigma “Vendor relationship Management". In questa concezione, un individuo può scegliere un operatore di un servizio di autorizzazione che accetta connessioni da una varietà di host di risorse digitali rivolto a consumatori, al fine di offrire un cruscotto con le funzionalità di gestione di condivisione delle risorse.

Collegamenti esterni

• UMA FAQ, su kantarainitiative.org. URL consultato il 5 maggio 2019 (archiviato dall'url originale il 29 settembre 2020).
• User-Managed Access (UMA) Profile of OAuth 2.0 Recommendation, su docs.kantarainitiative.org.
• OAuth 2.0 Resource Set Registration Recommendation, su docs.kantarainitiative.org.
• Venn of access control, su blogs.forrester.com. URL consultato l'11 ottobre 2012 (archiviato dall'url originale il 14 luglio 2012).
• UMA Implementations, su kantarainitiative.org. URL consultato il 5 maggio 2019 (archiviato dall'url originale il 6 marzo 2019).