Progettazione di un modulo di autenticazione utente (ruoli e diritti)

Sto cercando di modellare un modulo di autenticazione utente per un database MS SQL Server che sarà il back-end di un'applicazione IU Delphi. Fondamentalmente, voglio avere account utente in cui l'utente appartiene a un solo gruppo. Un gruppo può avere "n" numero di diritti.

Voglio anche aggiungere la cronologia delle password al database, poiché all'utente verrà richiesto di modificare la password in base a un'impostazione dell'applicazione (esempio, ogni 90 giorni).

Voglio anche registrare un evento ogni volta che un utente accede e disconnette. Potrei estenderlo ad altri eventi in futuro.

Di seguito troverai la mia prima crepa. Per favore fatemi sapere eventuali suggerimenti per migliorarlo, poiché questa è la mia prima volta a farlo.

Ritieni che siano necessari ulteriori attributi per la sicurezza basata sui ruoli e vincoli per le regole password / i periodi di scadenza?

Sulla base dei requisiti dichiarati, il modello è in buone condizioni.

Ecco alcuni suggerimenti per il miglioramento:

• Non lo dici esplicitamente, quindi è difficile dirlo, ma sembra che tu stia memorizzando direttamente la password dell'utente. Questo sarebbe molto male! Se si esaminano database di autenticazione comuni, le password vengono archiviate in forma crittografata. Spesso vedi sia una passwordcolonna che una password_saltcolonna.

• La tua USER_LOGStabella ha una Eventcolonna. Non sei chiaro su come questo debba essere popolato. Dovrebbe esserci una EVENT_TYPEtabella che fa USER_LOGSriferimento? Questo potrebbe rendere più amichevole la segnalazione. Gli eventi tipici includono accesso, disconnessione, errore password, modifica password, reimpostazione password, blocco, sblocco, ...

• La tua GROUP_RIGHTStabella non indica chi ha concesso i diritti. Ai fini dell'audit trail, le persone spesso tengono un registro di chi ha cambiato il record e quando. Potrebbe non essere un problema per te.

Ecco un paio di domande sui requisiti aziendali dichiarati, che differiscono dal modello di sicurezza basato sul ruolo "libro di testo" in un paio di modi:

• Sei sicuro di volere che gli utenti appartengano a un solo gruppo? Il vantaggio della sicurezza basata sui ruoli è che i ruoli tendono ad essere piuttosto statici, mentre le persone che ricoprono ruoli vanno e vengono piuttosto spesso. Incluso in questo è che alcune persone spesso "indossano due cappelli".

• Il tuo design è solo concessione. Alcuni sistemi includono concessione e revoca . Ciò consente di dire che un diritto ampiamente disponibile non è disponibile per un determinato gruppo.

• Hai utenti e account in arrivo come USERSnel tuo progetto. C'è spesso una distinzione tra persone e ID utente . Alcuni ID utente sono per team o macchine e alcune persone hanno più ID utente per scopi diversi. È una distinzione che ti sarebbe utile?

Penso che l'operatore bit per bit sia il modo migliore per implementare l'autorizzazione dell'utente. Qui sto mostrando come possiamo implementarlo con Mysql.

Di seguito è riportato un esempio di tabelle con alcuni dati di esempio:

Tabella 1 : tabella delle autorizzazioni per memorizzare il nome dell'autorizzazione insieme ad essa come 1,2,4,8..etc (multiplo di 2)

CREATE TABLE IF NOT EXISTS `permission` (
  `bit` int(11) NOT NULL,
  `name` varchar(50) NOT NULL,
  PRIMARY KEY (`bit`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Inserisci alcuni dati di esempio nella tabella.

INSERT INTO `permission` (`bit`, `name`) VALUES
(1, 'User-Add'),
(2, 'User-Edit'),
(4, 'User-Delete'),
(8, 'User-View'),
(16, 'Blog-Add'),
(32, 'Blog-Edit'),
(64, 'Blog-Delete'),
(128, 'Blog-View');

Tabella 2 : tabella utente per memorizzare ID utente, nome e ruolo. Il ruolo verrà calcolato come somma delle autorizzazioni.
Esempio:
se l'utente "Ketan" ha l'autorizzazione di "Aggiungi utente" (bit = 1) e "Elimina blog" (bit 64), il ruolo sarà 65 (1 + 64).
Se l'utente "Mehata" ha l'autorizzazione di "Blog-View" (bit = 128) e "User-Delete" (bit-4), il ruolo sarà 132 (128 + 4).

CREATE TABLE IF NOT EXISTS `user` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL,
  `role` int(11) NOT NULL,
  `created_date` datetime NOT NULL
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1;

Dati di esempio

INSERT INTO `user` (`id`, `name`, `role`, `created_date`)
   VALUES (NULL, 'Ketan', '65', '2013-01-09 00:00:00'),
   (NULL, 'Mehata', '132', '2013-01-09 00:00:00');

Presentazione dell'autorizzazione dell'utente Dopo il login se si desidera caricare l'autorizzazione dell'utente, è possibile eseguire una query di seguito per ottenere le autorizzazioni:

SELECT permission.bit,permission.name  
   FROM user LEFT JOIN permission ON user.role & permission.bit
 WHERE user.id = 1

Qui user.role "&" permesso.bit è un operatore Bitwise che fornirà output come -

User-Add - 1
Blog-Delete - 64

Se vogliamo controllare il meteo, un determinato utente ha l'autorizzazione di modifica dell'utente o no-

  SELECT * FROM `user` 
     WHERE role & (select bit from permission where name='user-edit')

Output = Nessuna riga.

Puoi anche vedere: http://goo.gl/ATnj6j