Soluzione di sicurezza a livello di riga indipendente dal database

qualcuno sa sulla libreria di authorization indipendente del database Java / C #. Questa libreria dovrebbe supportare leggere, scrivere, eliminare, inserire azioni nella struttura organizzativa della società.

Qualcosa come questo:
– l’utente può vedere tutti i documenti
– l’utente può inserire un nuovo documento assegnato alla sua unità
– l’utente può cambiare tutti i documenti assegnati alla sua unità e tutte le unità subordinate.
– l’utente può cancellare i documenti che gli sono stati assegnati

Dovrei anche essere in grado di creare azioni personalizzate (oltre a leggere, scrivere, …) collegarle a determinate classi e assegnare quel “token di sicurezza” all’utente (ad esempio, document.expire). Se non ci sono librerie libere o commerciali, c’è un libro che potrebbe essere utile per implementare questa funzionalità?

Grazie.

Anch’io sono sorpreso dalla mancanza di strutture di sicurezza.

C’è la sicurezza di Rhino . Ayende ha una manciata di post su questo blog .

Un altro blog contiene anche un paio di articoli .

È ansible utilizzarlo anche con l’ architettura S # arp .

Non posso dire di averlo implementato in un progetto, basta leggerlo un po ‘di tempo fa. È stata l’unica implementazione del suo genere che ho potuto trovare.

Ho trovato una libreria che ha funzionalità simili alle mie esigenze:

http://www.codeproject.com/KB/database/AFCAS.aspx

È strano che non ce ne siano più sul web poiché questo è un problema che ogni applicazione seria deve affrontare. Per quanto riguarda la documentazione / esempio, il meglio che ho trovato sono i moduli di authorization dei sistemi CRM come:
– Siebel – Guida alla sicurezza di Siebel – Capitolo 10. Controllo dell’accesso
– Sugar CRM – http://www.sugarcrm.com/crm/products/capabilities/administration/access.html
– Microsoft CRM – http://msdn.microsoft.com/en-us/library/ms955698.aspx

Questo è un tipo di funzionalità di cui ho bisogno. Immagino che sarà compito di DIY.

Il problema con l’implementazione della soluzione di sicurezza nella libreria client è che è efficace solo con lo strumento client. Questo suona piuttosto DUH, ma lasci aperta l’enorme buco di sicurezza che è il database stesso. Pertanto, se un utente si connette direttamente a un database (ad esempio utilizzando un ADP di accesso a SQL Server) ha il controllo completo su qualsiasi ruolo utente. Che avrebbero bisogno di accesso completo a tutto il database, se si stanno facendo le restrizioni nella libreria client.

L’unico caso in cui questo non sarebbe un grosso problema sarebbe con le applicazioni web e i servizi web. Se il tuo servizio web ha fatto la sicurezza e l’ha nascosto dietro l’interfaccia del servizio web (quindi non c’era un accesso diretto al database), allora sarebbe sicuro. Questo potrebbe essere ciò di cui stai parlando, ma non è stato specificato nella tua domanda.

Se si sta utilizzando un client grasso, esiste una ragione per cui non si vorrebbe inserire la logica di sicurezza nel lato del database? Hai menzionato il database indipendente, ma nulla di ciò che hai specificato sarebbe difficile da fornire in ogni piattaforma. Fondamentalmente stai descrivendo pre / post-trigger che controllano se un utente ha i diritti per modificare un record. Un RLS completo limiterebbe anche i diritti dell’utente di visualizzare e rendere le cose leggermente più difficili a seconda della piattaforma.