Come gestire i reclami dipendenti dai dati?

Question

Come gestire i reclami dipendenti dai dati?

#1 da (2 voti)
#2 da (0 voti)

0

Questa domanda riguarda l'autorizzazione basata sulle attestazioni e Windows Identity Foundation (purtroppo mi manca il privilegio di creare un tag per questo).

Considera il seguente caso d'uso semplice:

Ho un utente di classe e un progetto di classe,
(per semplicità) ogni progetto ha esattamente un utente assegnato,
Il criterio di controllo accessi è

A user can only read data of projects he is assigned to.

Sto provando a modellarlo usando WIF e autorizzazione basata sulle attestazioni.

Quindi ho il seguente metodo per il quale voglio controllare l'accesso:

public Project ReadProject(int id)

Per fare questo, dovrei chiamare il ClaimsAuthorizationManager con un AuthorizationContext contenente il principal (= utente) e reclami per le risorse a cui desidera accedere e le azioni che desidera eseguire su queste risorse.

Ciò su cui non sono chiaro: Nel caso di utilizzo di cui sopra, il permesso si basa sul fatto project.AssignedUserID == user.ID . Come sarebbero i Claims?

Questo requisito è un reclamo per l'utente / committente, come "L'utente ha accesso al progetto ID X", che devo impostare prima di chiamare il ClaimsAuthorizationManager? In caso affermativo, a quale punto assegnerei tale reclamo all'utente? E questo non rovinerebbe l'intero punto di avere un posto centralizzato per dichiarare e controllare le politiche?
È piuttosto qualcosa che ClaimsAuthorizationManager controllerebbe cercando il database? In tal caso, come potrei tradurre il fatto a quale progetto desidera accedere in un reclamo?

La maggior parte degli esempi che trovo per CBA si basano su attributi dell'utente (ad esempio da quale paese proviene), quindi non ho idea di come eseguire i controlli sulla relazione User-Data.

.net permissions authorization access-control

posta magnattic 08.05.2014 - 16:49

fonte

2 risposte

Leggi altre domande sui tag .net permissions authorization access-control

Quali siti forniscono le ultime informazioni sulle minacce alla sicurezza, in particolare malware zero-day [chiuso] Strumenti di analisi dinamica in Windows

score 2 · Answer 1

Bene, ci sono un paio di opzioni qui. Il primo è di invertirlo in modo tale che il tuo utente abbia una raccolta di attestazioni che definiscono a quali progetti hanno accesso:

Reclami:

Progetto: 123
Progetto: 124
Progetto: 125
Progetto: 129

Potrebbe non essere gestibile a seconda della frequenza con cui i progetti vengono creati e del numero di progetti per utente, in quanto dovresti aggiornare le rivendicazioni ogni volta che qualcosa cambia.

Si potrebbe eseguire un controllo del database in CAM ma questo diventa rumoroso rapidamente e può potenzialmente rallentare considerevolmente il sistema poiché la CAM è progettata per essere chiamata spesso. Se possibile, dovrebbe prendere le sue decisioni solo in base alle affermazioni presenti nel preside.

In alternativa puoi passare una risorsa composita come "project: {id}: {assignedUserId}" e la tua CAM potrebbe analizzarla, quindi se la risorsa inizia con "project" puoi analizzare l'ID del progetto e l'ID utente assegnato e fare un controllo per vedere se le affermazioni dei principal contengono qualcosa come "UserId: 123". L'ID del progetto non sarebbe necessariamente necessario in questo caso, ma se stai attaccando la registrazione nel CAM potrebbe essere utile includere anche l'ID del progetto.

score 0 · Answer 2

È necessario il controllo degli accessi basato sugli attributi. Il controllo degli accessi basato sulle attestazioni è potente ma non abbastanza flessibile qui in particolare, perché devi pensare a tutte le possibili richieste in anticipo.

Il controllo degli accessi basato sugli attributi (come definito qui da NIST ) presuppone che tutto possa essere descritto in termini di attributi: utenti, risorse, contesto e azione.

Tenendo questo a mente, prendi il tuo requisito di autorizzazione originale

A user can only read data of projects he is assigned to.

Il prossimo passo è identificare gli attributi:

action == leggi
resourceType == data
Dataproject
userAssignedProject

Puoi quindi riscrivere il tuo requisito di autorizzazione in termini di questi attributi.

A user can do the action == read on resource of resourceType == data if and only if dataProject is in the list of userAssignedProject.

La prossima domanda è: come implementa questo? Utilizza XACML, il linguaggio di markup del controllo accessi eXtensible , lo standard de facto per l'autorizzazione che è stato sviluppato negli ultimi 12 anni all'indirizzo OASIS .

XACML ti dà:

un'architettura
un linguaggio della politica
uno schema di richiesta / risposta.

ConXACMLpuoiesternarecompletamentelatuaautorizzazioneinmodotalecheiltuocodicesiconcentriesclusivamentesullalogicadibusinessepoirichiamiallivellodiautorizzazione.

Unodeiprincipalivantaggièchesesimodificailrequisitodiautorizzazioneoriginale,èpossibileaggiornarefacilmentelapoliticadiautorizzazioneenontoccareaffattoilcodice.

Eccocomesipresenteràlatuapoliticanellopseudo-codiceALFA:

/***Controlaccesstodatainprojects*/policyaccessData{targetclauseactionId=="read" and resourceType=="data" 
    apply firstApplicable
    /**
     * Allow if same project
     */
    rule sameProjectAccess{
        permit
        condition stringAtLeastOneMemberOf(dataProject, userAssignedProject)
    }
}

Questo intero spazio è chiamato gestione delle autorizzazioni esterne. Puoi leggere ulteriori informazioni sul sito Web di Gartner.