Dove si colloca l'autorizzazione in un'architettura a strati?

Question

Dove si colloca l'autorizzazione in un'architettura a strati?

#1 da (6 voti)
#2 da (6 voti)
#3 da (5 voti)

17

In genere, metto le decisioni di autorizzazione nei miei controller lato server. Questi sono stati endpoint RESTful di recente, ma penso che lo stesso sia per le architetture di tipo MVC. Per amor di discussione, supponiamo che si tratti di un'autorizzazione basata su ruoli. Un metodo protetto verrà annotato o verificherà e restituirà 403 se necessario.

Ora, dato che l'autorizzazione è di fatto una regola aziendale - "solo gli amministratori possono elencare X", ad esempio, penso che dovrebbero essere spinti verso il basso in un livello. Quando un controllore chiede al livello aziendale di eseguire l'operazione, il livello di servizio o aziendale informa il controllore che non è autorizzato.

È un approccio ragionevole? Ci sono degli svantaggi?

Ho il malumore di avere un AuthorisationService che contiene essenzialmente alcune regole codificate procedurali statiche per fare ciò, ma forse ha senso mantenere tutta la logica di accesso in un unico posto. È una preoccupazione trasversale che dovrebbe essere tenuta separata?

Quindi sto chiedendo se qualcuno ha fatto questo e come l'hanno raggiunto in modo pulito o se ci sono buone risorse che potrei leggere. Sto usando Java fwiw ma questa è una domanda agnostica del linguaggio.

Ho controllato le domande correlate qui e sono molto magre sul campo e risposte. Ad esempio: Validazione e autorizzazione in Modelli di dominio e trasporto che attraverso un livello di servizio di MVC

eta: sto leggendo i documenti di sicurezza di primavera che fanno alcuni buoni argomenti per essere una preoccupazione trasversale, ma sono preoccupato che è solo il "modo primaverile" e vorrebbe prospettive più ampie. Lega anche la tua applicazione a un framework specifico.

architecture

posta tom 11.11.2014 - 12:35

fonte

3 risposte

Leggi altre domande sui tag architecture

Quando utilizzare le interfacce (unit test, IoC?) Esempi di test di buona unità per sviluppatori C incorporati [chiuso]

score 6 · Answer 1

Penso che sia assolutamente ragionevole l'approccio all'autorizzazione dell'incisione nel tuo livello di servizio. È necessario proteggere il servizio dall'esecuzione di attività non autorizzate (in particolare le modifiche dei dati). Il tuo livello di servizio potrebbe risiedere in una libreria e essere utilizzato da diversi livelli di presentazione (potresti avere diverse applicazioni dell'interfaccia utente, che utilizzano lo stesso livello di servizio). E non puoi fare affidamento sul fatto che specifici livelli di presentazione eseguono la convalida necessaria. Ciò è particolarmente importante se in seguito deciderai di spostare il tuo livello di servizio nel processo separato (ad esempio seguendo l'approccio SOA).

Ora su come ottenere questo risultato in un "modo pulito". Non mi piace l'idea di littering business logic con controlli di autorizzazione, quindi alcune specifiche implementazioni dell'approccio orientato agli aspetti potrebbero aiutare: potrebbe essere la decorazione di metodi di servizio con attributi speciali o l'utilizzo di proxy dinamici con intercettazioni.

E, soprattutto, devo ammettere che in progetti molto semplici, potresti essere, potresti vivere senza convalide separate, solo per semplificare la tua vita. Ma è importante non perdere il momento in cui il "progetto semplice" ha cominciato a diventare un "progetto complesso".

score 6 · Answer 2

È buona norma esporre solo le opzioni per le quali un utente è autorizzato.

Ciò impone che l'autorizzazione sia una preoccupazione trasversale. La "vista" deve sapere cosa è permesso fare a un utente prima che possa creare opzioni e menu per la visualizzazione.

Il back-end non dovrebbe fidarsi del front-end per prendere decisioni sulla sicurezza, quindi è necessario verificare l'autorizzazione stessa.

Potrebbero esserci regole aziendali che influiscono sull'autorizzazione a seconda dei dati, ad es. "Solo gli utenti con un saldo superiore a $ 5000 possono invocare un trasferimento di valuta estera" o "Solo un utente che si trova presso la sede centrale può visualizzare questi account". Quindi è necessaria una logica di autorizzazione all'interno della logica aziendale.

Esistono anche autorizzazioni tecniche da considerare: a chi è consentito visualizzare i registri, chi può eseguire il backup / ripristino del database, ecc.

Quindi alla fine ogni componente del tuo potrebbe avere alcuni requisiti di sicurezza e / o autorizzazione specifici, in pratica è quasi impossibile racchiuderlo in un "livello di autorizzazione" separato.

score 5 · Answer 3

Sono completamente d'aiuto nel spingere i controlli delle autorizzazioni più in basso possibile!

E così facendo, non ti è proibito scrivere test di autorizzazione automatici su ogni livello "sopra" di esso - cosa che incoraggerei se lenisca un sentimento paranoico, ti consente di applicare regole più rigide a livello di servizio (CanView / CanSerialize?), O introduce casi limite come solo un cattivo odore di deserializzazione.

Tuttavia , se le regole di autorizzazione sono testate e applicate solo nel livello di servizio, lasciando che i tuoi oggetti di dominio poveri si pieghino alle volontà di oggetti di servizio lunatici, Spesso viene richiesto di applicare ogni singola regola più di una volta, in più oggetti e più posizioni in ogni oggetto e in codice più complicato.

Inoltre, quando il tuo team di analisi assolda una società di consulenza per scrivere servizi di reportage usando i tuoi oggetti di dominio, non ti devi fidare di quegli sviluppatori! (O qualunque altra cosa. Costruisci servizi aggiuntivi o chiamate sugli stessi oggetti per qualsiasi motivo.) Non vorrai aprire il grande libro delle regole aziendali e sperare a applicare tali regole correttamente di nuovo ; vuoi che il tuo dominio li conosca già e applicali.