2009-11-24 9 views
21

Ho letto il servizio di controllo degli accessi di Azure e l'autorizzazione basata sulle attestazioni in generale per un po 'di tempo e, per qualsiasi motivo, non vedo ancora le motivazioni per passare dall'autorizzazione basata su ruoli/permessi a una richiesta- modello basato. I modelli mi sembrano simili (e probabilmente lo sono), tranne per il fatto che l'elenco di ciò che il client può o non può fare viene da una terza parte ed è racchiuso in una sorta di token, anziché da una sorta di database che il server deve interrogare. Qual è il vantaggio di coinvolgere una terza parte (l'emittente di token)?Qual è lo scopo dell'autorizzazione basata sulle attestazioni?

Capisco perfettamente i vantaggi dell'autenticazione dell'outsourcing a terzi. Consente alle app di non dover creare continuamente nuovi utenti, preoccuparsi di archiviare le password, ecc. Quando possono semplicemente inviarle ad altri servizi che dispongono già dell'infrastruttura. È essenzialmente il principio DRY per l'autenticazione.

Tuttavia, a mio parere, la stessa logica non funziona per l'autorizzazione. Ogni app ha le proprie risorse che deve proteggere e quindi le proprie regole per autorizzare gli utenti a eseguire determinate azioni. L'infrastruttura sembra abbastanza semplice da consentire a ciascuna app di crearla da sola (una tabella che associa gli utenti ai ruoli e possibilmente un altro mapping ai permessi) e, anche se si desidera esternalizzarla, sembra che il modello basato sulle attestazioni stia qualcosa di più complicato di così

L'unica spiegazione parziale che ho visto proviene da Building a Claims-Based Security Model in WCF, e dà due vantaggi principali per basata sulle attestazioni autenticazione: una maggiore flessibilità, e qualcuno a "garantire" che le informazioni in un'affermazione è corretta. Quando avresti bisogno di uno di questi?

L'autorizzazione basata sui reclami sembra stia guadagnando popolarità, quindi presumo che ci debba essere una buona motivazione per questo; Non ho ancora capito cosa sia ancora. Qualcuno può fornire un esempio concreto di una situazione in cui l'autenticazione basata sulle attestazioni funziona meglio di quella basata sui ruoli e perché funziona meglio in quel caso?

(EDIT: ho perso un terzo vantaggio elencato in questo articolo:. Supporto single sign-on/federazione, ma non l'autenticazione accordo con che da sola senza ottenere l'autorizzazione coinvolto?)

+2

+1. Mi piace la tua onestà. – Stimul8d

risposta

9

Credo che il principale la promessa di un beneficio dal sistema di sicurezza federato/basato sulle attestazioni sarebbe una delle poche aree che devi affrontare con sistemi diversi.

Immagina un sito in cui gli utenti locali eseguono l'autenticazione con le credenziali di Windows, un gruppo di utenti Internet che utilizzano nome utente/password, altri che utilizzano certificati e forse un altro gruppo di utenti con autenticazione biometrica.

Nel sistema di oggi, è necessario impostare e gestire tutti i diversi tipi di schemi di autenticazione e i diversi modi di fare le cose. Questo può diventare piuttosto complicato.

La promessa di una soluzione di sicurezza federata potrebbe essere quella di gestire tutte quelle faccende per te - le STS (Security Server token) sarebbe di gestire tutti i diversi tipi di sistemi di autenticazione per te, e presentare a voi un uniforme e fidato insieme dei crediti su un chiamante - non importa da dove e in quale percorso sta arrivando al tuo sito.

Ovviamente, solo esaminare e reagire a una singola serie di affermazioni anziché dover comprendere quattro, cinque, dieci diversi e diversi sistemi di autenticazione sembra una promessa davvero convincente per me!

+0

Giusto, ma per me, tutto sembra un'autenticazione piuttosto che un'autorizzazione. Immagino di star immaginando che l'utente ti dia qualche token con il suo ID autenticato, e il server cerchi le autorizzazioni basate su quell'ID. Il token potrebbe contenere altre affermazioni, ma non capisco perché lo farebbe. Sto guardando questo principalmente dalla prospettiva di ACS di Azure, che in realtà non sembra darti questi benefici, dal momento che accetta solo un paio di tipi di autenticazione. Ho sbagliato a visualizzare ACS come un puro fornitore di autorizzazioni (nessuna autenticazione) e non vedo molto valore in questo? –

+2

Sì, è vero, ma dal momento che ti viene presentata una serie uniforme di attestazioni dopo l'autenticazione, puoi anche semplificare l'autorizzazione. Non hai bisogno di gestire i diversi tipi di "identità" che ti vengono presentate: ricevi solo una serie di attestazioni e, in base a ciò, autorizzi (o neghi) un determinato chiamante a fare qualcosa di straordinario. –

+0

Non ho investito Abbastanza tempo in Azure ACS per rispondere a queste domande dettagliate, mi spiace, –

0

Il controllo degli accessi basato sulle attestazioni aiuta anche a creare controllo degli accessi basato sugli attributi e controllo degli accessi basato su criteri. Se standardizzate su una serie di attestazioni concordate che possono essere assegnate agli utenti in base ai loro altri attributi (ad esempio, un manager degli Stati Uniti può presentare una richiesta U_M, un gestore europeo può presentare una richiesta E_M). In un ambiente basato sugli attributi e basato su criteri, è possibile ottenere autorizzazioni a grana fine (note anche come autorizzazioni a grana fine) utilizzando XACML. In questo caso, è possibile avere un'autorizzazione che dipende da chi è l'utente (rivendicazioni) ma anche cosa vogliono fare (informazioni sulle risorse) e in quali circostanze (contesto).

CBAC con XACML vi permetterà di esprimere regole come:

manager in grado di modificare le note essi stessi creati o le note che i loro rapporti diretti creati.

1

Lo scopo delle domande di autorizzazione basato è quello di consentire il controllo di accesso a grana fine sulla base di espressioni booleane che valutano le caratteristiche del soggetto che accede e la risorsa. Ciò riduce o elimina la necessità di fornire gruppi. Come con l'identità federata, le attestazioni forniscono anche un veicolo per un provider di identità per gestire i propri utenti, consentendo a un fornitore di risorse di consentire agli utenti l'accesso alle risorse.

Nota: reclami possono essere utilizzati all'interno di una singola impresa e offrono i seguenti vantaggi:

1) consente l'accesso e revoche non richiedono provisioning o de-provisioning

2) Così i cambiamenti sono istantanei

3) i proprietari delle risorse può definire la portata e requisiti per l'accesso, piuttosto che avere amministratori di creare gruppi di gestire un gruppo - questo sposta le decisioni di controllo di accesso nelle mani delle persone più adatti a prendere tali decisioni (il proprietario dei dati)

4) Questo si traduce in un minor numero di gruppi che sia necessaria e meno membro nei gruppi

5) Ci possono essere problemi creando un unico gruppo per accogliere una grande comunità di avere accesso (per esempio, tutti i dipendenti a tempo pieno in grado di leggere un politica del personale) - reclami evita questo problema

6) Audit è più informativo - la ragione per una borsa di studio o negare ha avuto luogo ben visibile

7) richieste di supporto attributi dinamici, come l'autenticazione a 2 fattori, il tempo di giorno, o restrizioni di rete

Ci sono molti più motivi, ma quelli vengono in mente. Ci sarà presto un video su www.cionsystems.com che mostra questo (disclaimer - Lavoro lì e registra il video - Devo ancora postarlo) Inoltre, per riferimento, le app e le piattaforme basate sulle attestazioni includono SharePoint 2010, Windows 2012 (condivisioni di file), Azure, molti servizi SaaS (Facebook e Salesforce)

Inoltre, con i reclami si può mescolare le informazioni provenienti da più fonti (dire Facebook e l'annuncio locale), ecc - che è sempre più importante

Non certo se le regole lo consentono, ma sentitevi liberi di rispondermi con le vostre domande o commenti. Modificherò felicemente il post per apportare eventuali correzioni o aggiungere informazioni pertinenti.

Le richieste possono provenire da AD, tabelle di database, SAML, OAuth, algoritmi, XACML o qualsiasi altro provider attendibile. Affrontare le richieste richiede un po 'di kit - con app e piattaforme che si evolvono rapidamente in questo spazio.

All the Best,

Paul

sicurezza basata
0

ruolo è un modello di sicurezza limitata autorizzazione è:

Based on role membership only 

reclami sicurezza basata è molto più flessibile ed espressivo autorizzazione può essere:

  • Sulla base di appartenenza ai ruoli

    in base all'età

    in base alla posizione geografica

    Sulla base di un saldo del conto

    Sulla base di una dimensione

    Sulla base di livelli securtiy predefiniti

    In base a qualsiasi combinazione dei precedenti