Come gestire le autorizzazioni per risorsa (a grana fine) in OAuth?

Naviga le tue risposte
3

Sto progettando un'architettura di app utilizzando OAuth 2.0. Ho un server di risorse e server di autorizzazione separati. Quest'ultimo mantiene un database di utenti e gli ambiti a loro disponibili.

Ora, la mia domanda è: Come e dove archiviare / modellare le autorizzazioni a grana fine, per risorsa?

Sto parlando di uno scenario simile a quello che succede in un'app di condivisione file, ad esempio Dropbox, in cui l'utente può scegliere quali file condividere con quali altri utenti . Come modellarlo nel contesto di OAuth?

In particolare, nel mio caso alcuni utenti potrebbero esistere puramente nel database del server di autorizzazione (il server di risorse non ne conosce affatto). Chiamiamoli "utenti di sola lettura"; in AS avrebbero accesso a un ambito di read_files_shared_to_me . E quindi, quell'ambito è la concessione / token che la mia app client mostra al server di risorse quando si richiede una particolare risorsa (file). Ora, come devo sapere quali file sono condivisi con quali utenti, nel framework di OAuth (2.0)?

  • Se è responsabilità del server di risorse , come dovrebbe memorizzare l'elenco di utenti "consentiti", se gli utenti esistono solo in server di autorizzazione ? Se RS utilizza "endpoint di introspezione token" di AS per visualizzare in dettaglio le richieste dell'utente specifico e memorizzare un elenco di "utenti consentiti" per risorsa ("ACL")?
  • Se è responsabilità di Server di autorizzazione , come deve passare le informazioni su "risorse disponibili per questo utente" a RS ? Da ciò che capisco, gli "scope" sono piuttosto generali, corrispondono a "ruoli / gruppi", non a concrete risorse a grana fine, quindi inserire un elenco di ID di risorsa in un campo "ambito" di autorizzazione concessione / token di accesso non sembra OK?

1 Dopo ulteriori ricerche, ho trovato un thread 2011 con domande simili sulla mailing list [oauth-wg] . Alcune risposte suggeriscono di guardare "UMA". Sfortunatamente, i collegamenti sembrano essere sia un po 'marci, sia troppo vaghi. La apparente pagina principale di UMA sembra enorme e ancora poco chiara per me. Inoltre, non è chiaro per me se è ancora pertinente e aggiornato nel 2018. Facendo un giro su UMA non sono riuscito a trovare risultati utili. Se "usa UMA" è ciò che vorresti scrivere come risposta, prova a spiegare un po 'di più su come dovrei applicarlo. Inoltre, conosci i servizi concreti che utilizzano UMA per questo scopo?

    
posta akavel 13.06.2018 - 15:41
fonte

1 risposta

0

Eh, rispondendo alla mia domanda ... Ho seguito un po 'di più su UMA, e sembra essere davvero una sorta di soluzione possibile:

UMA sembra essere un semi-ufficiale (o almeno l'unico in cerca di un ufficiale che potrei trovare ) estensione a OAuth 2.0, aggiungendo supporto per la condivisione di risorse "a grana fine", M: N . In parole semplici, consente uno scenario come:

"Alice shares a folder of cat photos with Bob."

La specifica UMA stessa è, um ... un po 'un secchio di prolisso formalismo come le caratteristiche di questo mondo piace essere; ma se lo schiacci per raggiungere il succo, all'improvviso inizia a mostrarmi come effettivamente abbastanza accessibile, secondo me. Il nucleo che sta alla base del "trucco" che direi è che un'idea:

"It should be AS's responsibility (to guard the access & manage individual permissions), but it would work on opaque resource pointers provided by RS (thus not needing to know about semantics of particular resources)."

Espandendoci un po 'di più sull'idea, uno schizzo di architettura di alto livello di una possibile implementazione potrebbe essere il seguente:

  • Server di autorizzazione deve memorizzare una tabella persistente aggiuntiva, "resource_sets", in cui ogni riga rappresenta "un puntatore opaco a una o più risorse concrete in RS". [Ad esempio, una riga potrebbe rappresentare la cartella di Alice denominata: "Crea divertenti CATS !!! 1! 1" ] Le colonne dovrebbero essere più o meno:
    • id - ID riga univoco in AS
    • owner - Proprietario risorse delle risorse [ad es. "alice" ]
    • rs_id - ID fornito da Server di risorse (il "puntatore opaco")
    • name - nome descrittivo, fornito anche da RS [ad es. "Rly funny CATS!!!1!1" ]
    • max_scopes - fornito anche da RS [ad es. "view" o "view add delete" ]
    • un elenco di coppie (user, scopes) , gestite dinamicamente da Proprietario risorse tramite alcune UI su AS . (Questo potrebbe essere tenuto in una tabella separata se necessario, i dettagli di implementazione.) [Ad es. ("bob", "view") ]
  • AS deve anche esporre un'API REST, tramite la quale Resource Server può creare, modificare ed eliminare voci resource_sets (maggiori dettagli nelle specifiche UMA),
  • e un'interfaccia utente, tramite la quale RO puoi aggiungere / rimuovere utenti e amp; permessi, cioè coppie (user, scopes) , a resource_sets di proprietà (o almeno alcuni endpoint REST, in modo che l'implementatore possa costruire l'interfaccia utente su quelli).
  • Server di risorse deve mantenere una mappatura di: risorsa → rs_id ;
  • quando alcuni Client richiedono una risorsa in RS , RS devono trovare rs_id , e chiedi a AS quali sono permessi ambiti per questo rs_id , attraverso qualche elaborata danza usando Token di accesso ecc.

Per i dettagli completi, vedi ovviamente le specifiche complete:

Profilo UMA (User-Managed Access) di OAuth 2.0 [html]

EDIT: La versione 2.0 delle specifiche UMA in formato HTML sembra essere qui, IIUC:

Concessione di accesso gestito dall'utente (UMA) 2.0 per l'autorizzazione OAuth 2.0 [html]

ma non l'ho ancora esaminato, per confermare se è effettivamente correlato.

    
risposta data 14.06.2018 - 10:51
fonte

Leggi altre domande sui tag

Progettazione di un modo in cui il processo deve comunicare con il kernel Qual è il posto migliore per creare Binding e Queue su comunicazione RPC: Consumer o Producer?