- restituire un elenco di risorse autorizzate

Question

Qual è il modo consigliato di recuperare un elenco di tutte le risorse a cui un utente ha accesso?

In molti esempi che ho visto, l'autorizzazione viene inserito in un servizio separato - spesso uno che espone un metodo simile a isAuthorized(), che può essere utilizzato per le query individuali ("è l'utente autorizzato ad utilizzare risorse ABC ? ") così come le query di massa (" L'utente è autorizzato a utilizzare uno qualsiasi dei seguenti elenchi di risorse? ").

Mentre il autorizzazione logica esiste nel servizio di autorizzazione, il attuazione dei criteri di autorizzazione è conservato all'interno dell'applicazione stessa (ad esempio, le imprese-logic layer per l'effettiva implementazione accesso alla risorsa, in base al risultato dal servizio di autorizzazione o dal livello di presentazione per mostrare/nascondere le singole opzioni in base al risultato del servizio di autorizzazione, ecc.).

Qual è il modo migliore di farlo se, ad esempio, il mio livello di accesso ai dati ha potenzialmente miliardi di "risorse" che potrebbe restituire? Il mio livello logico di business esegue una query su tutti i dati (passandoli tutti sulla rete), quindi inoltra tale lista gigante al servizio di autorizzazione (di nuovo attraverso la rete), solo per ottenere una lista gigante di "ALLOW/DENY" rimandato alla logica aziendale? Ovviamente non suona abbastanza bene.

Si tratta di un caso in cui non è possibile separare "pulito" l'accesso ai dati, la logica di autorizzazione e la logica aziendale? Dovrei invece chiedere al mio livello di accesso ai dati di restituire solo a me un elenco di tutte le risorse a cui l'utente ha accesso, che potrebbe finire per essere implementato come un semplice join di database, ma richiederebbe quindi una parte della logica per determinare chi ha accesso a quali risorse in quali condizioni (vale a dire, le politiche di autorizzazione) essere incorporate nel codice di accesso ai dati e quindi tali politiche sarebbero diffuse attraverso la mia base di codice (ad esempio, una qualche logica di autorizzazione sarebbe nel mio Data-Access Livello, alcuni sarebbero nel mio livello di autorizzazione, ecc.)?

Forse le prestazioni superano l'architettura "pulita", ma c'è un modo migliore per farlo?

Answer 1

Non ho una risposta definitiva alla tua domanda, ma posso essere in grado di offrire una certa pointers-

• si chiedeva
  

  il mio business logica di query strato di tutto quei dati, quindi inoltra quell'elenco gigante sul servizio di autorizzazione, solo per ottenere un gigantesco elenco di "ALLOW/DENY" rinviato alla business logic?

Beh, questo non mi sembra uno scenario probabile. Riesci a pensare a una situazione in cui vorresti presentare tutti i i record disponibili per un utente? Non è più ragionevole che tu voglia filtrare ulteriormente quei record (cioè per tipo, data, ecc.), E probabilmente vorrai anche metterli in una pagina in modo che l'utente ottenga un set di risultati a misura di morso.

• aggiungere che, per il fatto che molto probabilmente si sarebbe di passaggio solo identificatori record da e verso il servizio, è possibile che questo approccio è fattibile per voi.

• Si noti inoltre che la presenza della propria logica di autorizzazione come "servizio" non significa necessariamente che deve risiedere su una macchina diversa; è possibile implementarlo come modulo logico separato e continuare a farlo funzionare sulla stessa macchina (possibilmente sullo stesso processo dell'applicazione, se lo si desidera), evitando così il problema del traffico di rete.

• l'osservazione che l'implementazione dell'autorizzazione come parte dell'accesso ai dati può essere difficile è corretta. Tuttavia, ci sono alcuni strumenti di infrastruttura che ti aiutano in questo. Ad esempio- oracolo virtual private database, (n)hibernate filters e sono sicuro che ce ne sono altri.

Ancora una volta, queste non sono risposte complete, ma possono indirizzarvi verso una soluzione che funzionerà per voi.
Ti suggerisco google 'framework di autorizzazione + [il tuo linguaggio di programmazione preferito]'; Sono sicuro che qualcuno l'ha già fatto prima :)

Answer 2

Ho un'idea embrionale, non basata su alcuna esperienza pratica ma a prima vista è plausibile.

Perché disponiamo di un servizio di autorizzazione? La mia richiesta è che abbiamo alcune funzionalità di quel servizio perché la nostra fonte di dati non sta facendo un lavoro completo. Se stessimo usando solo un database RDBMS come fonte dei nostri dati, il database potrebbe proteggere le principali categorie di autorizzazione. Possiamo lavorare contro Views e concedere i privilegi per accedere a tali Views e quindi proteggere Tabelle e Colonne come desideriamo. Rimane quindi l'insieme delle regole di questo tipo

Le informazioni sullo stipendio per un impiegato possono essere mostrate a). il dipendente, b). il loro manager e il manager di seconda linea, c). membri del team di retribuzione HR .

credo che tali regole di autorizzazione hanno la semantica di business, e sono meglio implementati da un servizio di autorizzazione e l'espressione di tale servizio è in termini di oggetti di business:

can This employee see That employee's salary? 

non è espresso in termini di tabelle, righe e colonne, ma con una granularità più grossolana e commerciale. L'implementazione di questo richiede la creazione di un modello di dati che esprima le regole di autorizzazione, e in senso stretto questa è la logica di business, abbiamo semplicemente scelto di rifattore al servizio di autorizzazione per incapsulare l'implementazione.

Contrasto con l'autorizzazione Entity a grana fine, espressa in termini di viste, tabelle e colonne. La mia richiesta è che questo appartenga correttamente all'origine dati e se la nostra fonte di dati non può o non la implementa, allora dobbiamo implementarla nel nostro livello di accesso ai dati. I DAO "sanno" quali viste/tabelle usano e presumibilmente conoscono anche l'id per conto del quale viene eseguita la richiesta e quindi decidono se l'accesso è consentito.

Parlare liberamente: DAO ha l'SQL, quindi conosce le entità, quindi può decidere. (Sì, potrebbe non esserci SQL per alcuni back-end, ma DAO è l'oggetto che comprende ciò che viene richiamato.) Potrebbe essere arricchito con un metodo per elencare quali dei suoi metodi di accesso sono consentiti per un determinato utente.

CustomerDAO.whatIsAuthorised("joeCoder") => READ, QUERY 

CustomerDAO.whatIsAuthorised("phb") => READ, QUERY, UPDATE 

Answer 3

L'autenticazione è meglio essere esternalizzata. L'autorizzazione è spesso troppo dipendente dall'applicazione per esternalizzare. Potrebbe funzionare per piccoli sistemi. Ma per i sistemi di grandi dimensioni incontrerai problemi di ridimensionamento come ti aspetti.

Un'altra cosa sta restituendo enormi set di dati. Mi sembra che questa sia una posizione migliore nella segnalazione. Quindi separare i moduli del primo processo dai moduli di reporting, che hanno requisiti diversi perché in un processo di business sono necessari dati focalizzati e nella segnalazione di dati di massa e astrazione.

L'autorizzazione NON è un livello. È un aspetto Un'applicazione potrebbe non funzionare senza un livello se non lo si sostituisce almeno con un falso appropriato. Ma se rimuovi gli aspetti non dovresti avere problemi ad eseguire l'applicazione. Forse il tuo programma non registrerà nulla o sarai in grado di vedere più dati di quelli che puoi vedere ma funzionerà comunque.

Quindi l'autorizzazione deve essere esternalizzata dal dominio dell'applicazione? No. Dovrebbe essere separato dalla logica aziendale? Sì. Il meccanismo corretto: Aspetti (AspettoJ, Modello Proxy, Modello Modello-Class). Questo è il mio suggerimento generale.

Il mio suggerimento speciale per "i dati enorme" nei processi di business è: cercare di partizionare il vostro modello di dominio correttamente per avere pochi dati mirati (Salvo "usabilità" o "user experience"). Quindi torna al mio suggerimento generale.

Se si ha a che fare con enormi quantità di dati nei processi aziendali: utilizzare l'ultimo punto di "Make It Work Make It Right Make It Fast". Pensateci come un'ottimizzazione per richieste di dati speciali, che sono o dovrebbero essere lente. In questo caso usa speciali query SQL, pre-caricamento, memorizzazione nella cache, ecc. Il DAO-Layer può essere la posizione corretta, un aspetto di caching o un aspetto di ottimizzazione per il DAO-Layer che sovrascrive le implementazioni "funzionanti lente" con implementazioni alternative che sono veloce.

I suggerimenti che ho fatto si riferiscono ai normali casi di utilizzo aziendale. Non sto parlando di big data o report. Come ho già detto, questi settori hanno requisiti diversi.