Membership ASP.NET e protezione basata sui ruoli

Question

Sto sviluppando un motore di blogging con ASP.NET & C#. la soluzione principale è costituito da diversi progetti come elencato di seguito

• DomainModel: entità del dominio e interfacce per repository
• AppService: servizi applicativi, mapper vista del modello, messaggi, ecc
• Repositories: EF Repository, repository XML , Stub Repository
• Presentation: implementa il pattern MVP (viste, presentatori, interfacce)

Per ora il progetto user-end è un'applicazione web WebForms e il progetto è quasi terminato. l'ultima cosa è integrare l'intero sistema con ASP.NET Membership. ci sono due cose da considerare.

Prima di tutto, è necessario un account utente ID dal database di appartenenza nel database del blog. Infine, la sicurezza basata sui ruoli deve essere implementata nel progetto dell'interfaccia utente. dal momento che sono un po 'nuovo per lo sviluppo di applicazioni distribuite, DDD e roba, volevo sapere se l'implementazione della sicurezza basata sui ruoli è semplicemente responsabilità dell'app dell'interfaccia utente, o ci sono altre cose da considerare negli altri livelli di la soluzione. per quanto ne so per ora, solo le viste (pagine web) devono implementare la sicurezza basata sui ruoli e rendere diversi contenuti e offrire funzionalità diverse in base alla sessione corrente. ma è tutto?

So che questa potrebbe essere una domanda generica, naturalmente l'implementazione e il design variano in base alle esigenze del progetto. ma se ci sono delle regole generali da seguire quando si implementa la sicurezza basata sui ruoli e l'autenticazione dei moduli in un'applicazione distribuita/stratificata, sarebbe bello conoscerli in anticipo. ad esempio:

• L'implementazione della sicurezza è solo una responsabilità dell'applicazione per l'interfaccia utente.
• Posso modificare/modificare il design del mio modello di dominio e/o altri livelli, in modo che l'implementazione della sicurezza basata sui ruoli sia più semplice e non ricada interamente sull'app dell'interfaccia utente.
• È una buona idea prendere in considerazione la sicurezza in altri livelli, in modo che il livello dell'interfaccia utente sia solo una rappresentazione di dati e un supporto tra l'utente e il sistema.

Queste tre domande sembrano essere le stesse (duh).

Se si tratta di una domanda duplicata o fuori tema, è necessario fornire assistenza per collegamenti, riferimenti e commenti. ma se no, mi piacerebbe che questo fosse un argomento completo. tnx

Answer 1

La sicurezza dovrebbe essere responsabilità di tutte le app. Dipende davvero da come è strutturata la tua app.

La mia opinione è che tutti i livelli dovrebbero avere un certo coinvolgimento. La sicurezza dovrebbe essere un altro servizio, che gli altri servizi possono utilizzare. In questo modo è possibile accedere al modello di sicurezza a tutti i livelli. L'interfaccia utente dell'amministratore può bloccare immediatamente l'utente se non è autorizzato, ma afferma che il servizio di recupero dati può verificare che gli oggetti che sta recuperando siano validi per l'utente corrente.

È inoltre possibile ottenere vantaggi in questo modo se si desidera utilizzare il modello di dati in altri modi, ad esempio tramite servizi Web o da altre app, ad esempio Silverlight.

Aggiornamento

Tutti i livelli davvero bisogno di essere consapevoli di sicurezza, in quanto tutti i livelli hanno bisogno di toccare a un certo punto. L'interfaccia utente ne ha bisogno in modo che possa attivare e disattivare gli elementi dell'interfaccia utente. I servizi devono essere consapevoli di ciò per assicurarsi che le azioni che stanno eseguendo siano valide per l'utente corrente & così via.

La sicurezza non dovrebbe essere qualcosa che si pensa alla fine del progetto & basta accendere. dovrebbe essere qualcosa progettato nell'applicazione a tutti i livelli.

Il modo in cui lo si implementa dipenderà dal modo in cui è stata scritta l'applicazione. Direi che il modo migliore è quello di avere un livello di astrazione tra l'app & asp. Ottieni tutti i vantaggi che già conosci, ad esempio test, riprogettazione, ecc.

Una delle cose che potresti voler pensare è il concetto di diritti o permessi. ASP non ha librerie native per far fronte a questo, quindi dovresti far girare il tuo. Ogni volta che vuoi fare qualcosa, controlli che l'utente abbia il diritto. Questi diritti possono essere trasformati in ruoli che a loro volta possono essere assegnati a utenti o gruppi di utenti. Ottieni un controllo preciso su ciò che gli utenti possono fare & facilita l'aggiunta di nuovi ruoli in futuro.

Answer 2

La sicurezza è una preoccupazione trasversale: sono coinvolti UI, livelli applicazione e dominio. La mia comprensione è che ti occupi di regole come "Solo l'autore può modificare Blog" o "Solo gli utenti registrati possono commentare". In questo caso l'interfaccia utente dovrebbe essere a conoscenza di queste regole per decidere se eseguire il rendering dei link "Modifica" o "Commento". Gli oggetti di dominio dovrebbero essere in grado di applicare queste regole.

Per quanto ne so l'abbonamento a ASP.NET fa un sacco di cose tra cui la memorizzazione degli utenti, l'autenticazione, l'autorizzazione e la gestione dei ruoli. Tuttavia non è a conoscenza del tuo dominio. Non sa cosa sia il Blog. Sa cos'è la pagina ASP. Pertanto, se non desideri esprimere le regole del tuo dominio come regole di accesso alla pagina, potresti voler tracciare una linea spessa tra la tua app e l'iscrizione ad ASP.NET. È possibile delegare la conservazione e l'autenticazione degli utenti a ASP.NET, ma fare il resto da soli. Potrebbe anche essere una buona idea non avere dipendenza diretta da ASP.NET nel tuo modulo di dominio. Si desidera inoltre considerare il funzionamento dell'appartenenza ASP.NET se in seguito si decide di passare da Web Form a MVC o se si dispone di un'API Web per il proprio motore di blogging.

Answer 3

Non sai quale sia esattamente dopo, ma vale la pena notare che lo standard PrincipalPermissionAttribute Class funziona correttamente con i ruoli ASP.NET implementati con questa tecnologia provider.

Significa che è possibile utilizzare la protezione dall'accesso di codice e gli attributi dichiarativi per garantire che l'API/il dominio/i metodi possano essere accessibili solo dagli utenti in un ruolo specifico. Quindi sì, puoi rafforzare la sicurezza oltre i livelli dell'interfaccia utente utilizzando l'abbonamento a ASP.NET.

Answer 4

Dopo aver lavorato su questo problema per un po 'sono giunto a questa conclusione che segue.

Implementazione di sicurezza come Authentication, Role-based security, Authorization ecc.nel livello user-experience non è una buona idea soprattutto per due motivi:

1. Se si desidera creare altre interfacce utente per l'applicazione, dire una WinForms o Silverlight interfaccia utente, quindi dovrai implementare questa sicurezza da capo.
2. È sempre possibile utilizzare altri componenti/livelli del sistema senza creare un'app UI. Supponiamo di creare un'applicazione di console semplice che faccia riferimento ad altri livelli nel sistema (ad esempio Repositories). quindi è possibile creare un'istanza di un repository e manipolare i dati. nel qual caso hai superato con successo la sicurezza.

Quindi la soluzione è implementare questo tipo di sicurezza in un altro livello che è incorporato nel modello di dominio stesso e non è legato al livello dell'esperienza utente (UI).

Ora ci sono alcune variazioni su come si potrebbe andare su questo. diciamo che abbiamo un livello chiamato AppService che è il punto di ingresso dell'intero sistema. questo livello consiste di messaggi (un modello di messaggistica come il modello Request-Response), ViewModels che sono viste appiattite delle entità di dominio e Methods for retrieving and manipulating data ecc. qui possiamo implementare tali misure di sicurezza con l'aiuto degli oggetti PrincipalPermission. possiamo applicare le regole di sicurezza a classi e metodi. qui è un semplice esempio:

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)] 
public void DoSomething() 
{ } 

Con l'attributo definito per questo metodo, il codice richiede al chiamante di essere autenticato. il modello di autenticazione può essere qualsiasi cosa compreso Windows Authentication, Forms Authentication e così via. ora funziona bene, perché ora abbiamo liberamente accoppiato l'interfaccia utente dalle regole di sicurezza definite nel livello di servizio. tuttavia c'è ancora un problema.

Questo progetto funzionerà correttamente, fino a quando il livello di servizio è veramente il punto di ingresso principale nel sistema. ciò significa che se è ancora possibile creare un'istanza, ad esempio un repository, senza la necessità di ottenere un'istanza del proprio AppService, è comunque possibile ignorare le regole di sicurezza. Detto questo, devi progettare il tuo modello di dominio in modo tale che lavorare con componenti/livelli del tuo sistema richiederebbe un'istanza di AppService. in tal caso, qualsiasi funzione fornita nel sistema è accessibile solo attraverso il livello di servizio dell'applicazione. d'altra parte, se questo non è possibile, o non ti preoccupare al momento, dovrai definire le tue regole di sicurezza anche in altri livelli. nel senso che dovresti definire le regole di sicurezza anche nei tuoi repository. cosicché, se qualcuno crea un'istanza di un repository e tenta di manipolare i dati, senza eseguire i suoi comandi attraverso il livello UI o il livello AppService, si applicano comunque misure di sicurezza.

Un'altra cosa è che l'utilizzo delle regole PrincipalPermission sulle classi e sui metodi non è legato a uno specifico modello di autenticazione/autorizzazione. in questo modo è possibile utilizzare tali regole di sicurezza nelle applicazioni Web con Forms Authentication o applicazioni Windows con Windows/AcctiveDirectory Authentication e così via.

Come si ricorda sto sviluppando un semplice motore di blogging in ASP.NET e questo modello sta funzionando bene per il momento. se ci sono pro e contro approfondimenti più dettagliati, o esempi e post di blog che possono aiutare in questo argomento, assicurati di pubblicare i tuoi commenti e risposte [: