Indietro

ⓘ User-Managed Access




User-Managed Access
                                     

ⓘ User-Managed Access

User-Managed Access è 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 lautorizzazione della condivisione dei dati ed altri accessi alla risorsa protetta tra servizi online per conto del proprietario o con lautorizzazione 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.

                                     

1. Storia e contesto

Kantara Initiatives 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 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 dellutente che autorizza.

UMA, inoltre, non usa ne dipende dalla specifica eXtensible Access Control Markup Language XACML come mezzo di codifica delle politiche di autorizzazione dellutente 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 allAuthorization 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.

                                     

2. Stato della standardizzazione

Il gruppo UMA svolge il suo lavoro nellambito di Kantara Initiative e ha contribuito anche una serie di specifiche Internet-Draft ad Internet Engineering Task Force IETF come uneventuale 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.

                                     

3. 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.

                                     

4. Contronto con OAuth 2.0

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 unapplicazione cliente, viene reindirizzato su un" Authorization Server” AS per accedere e dare il consenso allemissione di un" token di accesso” con il quale il client può ottenere laccesso al Resource Server RS per conto di RO in futuro, presumibilmente in modo limitato in base allambito" scoped”. RS e AS, con ogni probabilità, operano allinterno dello stesso dominio di sicurezza, e qualsiasi comunicazione tra loro è non standardizzata dalla specifica principale OAuth.

UMA aggiunge tre concetti principali 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é lAPI è essa stessa resa sicura con OAuth, consente di stabilire la relazione di fiducia formale tra ogni coppia. Questo consente anche allAS di presentare al RO con uninterfaccia utente centralizzata. In secondo luogo, UMA definisce una nozione formale dellentità" Requesting Party” RqP che è autonoma da un RO, consentendo una condivisione da un soggetto ad unaltra 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 sullAS, 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.



                                     

5. Use Case Applicabili

LArchitettura di UMA può servire ad una varietà di casi duso sia rivolto verso consumatori che casi aziendali. Il gruppo UMA raccoglie studi di caso nel relativo wiki.

Un insieme di esempi di casi duso è nellambito assistenza sanitaria e sulla salute dei consumatori. Nellorganizzazione 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 lautorizzazione di accesso ai dati sanitari basato su RESTful API per la condivisione", basato, tra altri standard, su UMA.

Un altro insieme di casi duso, 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.