Sto scrivendo un'applicazione web-form-frontend aziendale per uso interno. Ha il controllo di accesso diretto (DAC) mascherato da controllo di accesso basato sui ruoli (RBAC).
Per scopi di anonimizzazione, chiamiamo l'unità di informazioni principale memorizzata nella mia applicazione un documento, ei ruoli in azienda sono un capo, un grugnito e un dirigente di livello C. Ci sono anche Externals (ad esempio qualcuno che lavora per un nostro partner commerciale). La linea guida generale è che tutti, tranne gli esterni, dovrebbero essere in grado di leggere tutti i documenti, i dirigenti di livello C possono scrivere tutto, i Boss possono scrivere i documenti appartenenti al proprio dipartimento e Grunt può solo scrivere documenti assegnati personalmente a loro. Abbastanza standard finora.
Ma ciò che gli utenti effettivamente vogliono è che possono fare eccezioni arbitrarie a quanto sopra. Vogliono che a qualsiasi persona nel sistema possa essere concesso l'accesso in scrittura a qualsiasi documento e che a Externals possa essere concesso l'accesso in lettura a qualsiasi documento. (In realtà, è più complicato di così, con più ruoli e una granularità più fine delle autorizzazioni, inclusa la gestione di chi può propagare quale autorizzazione per gli altri, ma la descrizione precedente illustra abbastanza bene il nucleo del problema). Quindi quello che ho sono fondamentalmente permessi a livello personale, e i ruoli sono solo un modo conveniente di avere impostazioni predefinite per le autorizzazioni a livello personale quando un utente o un documento viene aggiunto al sistema, invece di avere qualcuno che riempie un intero riga o colonna in una matrice di controllo degli accessi a mano.
Ora ho già progettato una tabella delle autorizzazioni nel mio database, che ha FK utente, FK del documento e colonne per i diversi tipi di autorizzazioni. Quello che non sono sicuro è ciò che dovrei salvare sul tavolo.
- Alternativa 1: salvataggio tutte le autorizzazioni in questa tabella (puro DAC) e il livello logico simula un RBAC. Per esempio. quando viene aggiunto un nuovo Boss, una riga per ogni Documento nel sistema viene aggiunta al DB, con le autorizzazioni di Lettura per tutti i documenti e Scrivi per i Documenti del suo dipartimento.
- Alternativa 2: salvo le deviazioni dalle linee guida sul ruolo. Quindi, quando viene aggiunto un nuovo Boss, non viene scritto nulla nella tabella delle autorizzazioni. Ma quando un dirigente dà a un capo i diritti di scrivere su un documento da un dipartimento diverso, allora viene aggiunta una singola riga per riflettere quell'informazione.
Non sono sicuro di quale alternativa sarebbe meglio. Il primo sembra più vicino all'implementazione dei libri di testo e, se un principio lo ha trasformato in un libro di testo, di solito c'è una buona ragione per usarlo. Ma nel mio caso, danneggia anche il principio DRY - dopo tutto, se l'informazione che un exec di livello C può scrivere su Document X è derivabile dal suo ruolo, scrivere una riga con queste informazioni nel DB è ridondante.
Quali sono i vantaggi e gli svantaggi di ciascun approccio in termini di a) prestazioni dell'applicazione e b) complessità di implementazione? Quali grattacapi posso aspettarmi da ciascuno?
Ricorda che 1) Non ho intenzione di implementare un livello logico completo. L'intera applicazione è praticamente un comodo frontend CRUD per un database, quindi eseguirò query DB per ogni visualizzazione di pagina invece di tenere una raccolta di oggetti Document in memoria. (Conosco i vantaggi di un pattern MVC, ma è stato deciso che sarà eccessivo per questo progetto). 2) Sto programmando questo in ASP .NET 4.5, quindi più mi avvicino ai ruoli, più posso lasciare che il framework faccia il lavoro più pesante per me. 3) Ho pensato di implementare gruppi ortogonali ai ruoli per gestire l'accesso, ma nel mio caso non ha senso.