Projektowanie modułu uwierzytelniania użytkownika (Role i prawa)

15

Próbuję modelować moduł uwierzytelniania użytkownika dla bazy danych MS SQL Server, która będzie zapleczem aplikacji interfejsu użytkownika Delphi. Zasadniczo chcę mieć konta użytkowników, w których użytkownik należy do tylko jednej grupy. Grupa może mieć „n” liczbę praw.

Chcę również dodać historię haseł do bazy danych, ponieważ użytkownik będzie musiał zmienić swoje hasło w oparciu o ustawienia aplikacji (na przykład co 90 dni).

Chcę także rejestrować zdarzenie za każdym razem, gdy użytkownik loguje się i wylogowuje. Mogę to rozszerzyć na dodatkowe wydarzenia w przyszłości.

Poniżej znajdziesz mój pierwszy crack. Daj mi znać, jak mogę to ulepszyć, ponieważ robię to po raz pierwszy.

Czy widzisz potrzebę dodatkowych atrybutów zabezpieczeń opartych na rolach i ograniczeń reguł haseł / okresów ważności?

db-design

Johnny Holmes
źródło
Szczegółowy blog znajduje się tutaj: goo.gl/ATnj6j
Suresh Kamrushi
1
Czegoś nie rozumiem W tabeli użytkowników masz identyfikator_grupy. Czy dana osoba może być członkiem więcej niż jednej grupy?
Johnny

Odpowiedzi:

11

W oparciu o podane wymagania Twój model jest w bardzo dobrym stanie.

Oto kilka sugestii dotyczących ulepszeń:

  • Nie mówisz tego wprost, więc trudno powiedzieć - ale wygląda na to, że możesz przechowywać hasło użytkownika bezpośrednio. To byłoby bardzo złe! Jeśli spojrzysz na popularne bazy danych uwierzytelniania, hasła są przechowywane w postaci zaszyfrowanej. Często widzisz zarówno passwordkolumnę, jak i password_saltkolumnę.

  • Twój USER_LOGSstół ma Eventkolumnę. Nie masz jasności co do tego, jak należy to wypełnić. Czy powinna istnieć EVENT_TYPEtabela, która zawiera USER_LOGSodniesienia? Może to ułatwić raportowanie. Typowe zdarzenia obejmują logowanie, wylogowywanie, niepowodzenie hasła, zmianę hasła, resetowanie hasła, blokowanie, odblokowanie, ...

  • Twój GROUP_RIGHTSstół nie wskazuje, kto przyznał prawa. Do celów ścieżki audytu ludzie często rejestrują, kto i kiedy dokonał zmiany. To może nie stanowić problemu.

Oto kilka pytań dotyczących podanych wymagań biznesowych, które różnią się od wzorca zabezpieczeń opartego na rolach w „podręczniku” na kilka sposobów:

  • Czy na pewno chcesz, aby użytkownicy byli tylko w jednej grupie? Zaletą bezpieczeństwa opartego na rolach jest to, że role są raczej statyczne, podczas gdy ludzie pełniący role przychodzą i odchodzą dość często. Obejmuje to fakt, że niektórzy ludzie często „noszą dwa czapki”.

  • Twój projekt jest tylko dotacją. Niektóre systemy obejmują udzielanie i cofanie . Pozwala to powiedzieć, że powszechnie dostępne prawo nie jest dostępne dla konkretnej grupy.

  • Masz użytkowników i konta podejrzane jak USERSw twoim projekcie. Często rozróżnia się identyfikatory osób i użytkowników . Niektóre identyfikatory użytkowników dotyczą zespołów lub maszyn, a niektóre osoby mają wiele identyfikatorów użytkowników do różnych celów. Czy to rozróżnienie byłoby dla Ciebie pomocne?

Joel Brown
źródło
3

Myślę, że operator bitowy to najlepszy sposób na wdrożenie uprawnień użytkownika. Tutaj pokazuję, jak możemy to zaimplementować w Mysql.

Poniżej znajdują się przykładowe tabele z niektórymi przykładowymi danymi:

Tabela 1 : Tabela uprawnień do przechowywania nazwy uprawnień wraz z nią nieco jak 1,2,4,8..etc (wielokrotność 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;

Wstaw kilka przykładowych danych do tabeli.

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');

Tabela 2 : Tabela użytkowników do przechowywania identyfikatora użytkownika, nazwy i roli. Rola zostanie obliczona jako suma uprawnień.
Przykład:
jeśli użytkownik „Ketan” ma zezwolenie na „dodawanie użytkownika” (bit = 1) i „usuwanie bloga” (bit-64), rola będzie wynosić 65 (1 + 64).
Jeśli użytkownik „Mehata” ma zezwolenie na „Blog-View” (bit = 128) i „User-Delete” (bit-4), rola będzie wynosić 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;

Przykładowe dane-

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');

Umieszczanie uprawnień użytkownika Po zalogowaniu, jeśli chcemy załadować uprawnienia użytkownika, możemy zapytać poniżej, aby uzyskać uprawnienia:

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

Tutaj user.role „&” permutation.bit jest bitowym operatorem, który da dane wyjściowe jako -

User-Add - 1
Blog-Delete - 64

Jeśli chcemy sprawdzić pogodę, dany użytkownik ma uprawnienia do edycji lub nie-

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

Dane wyjściowe = brak wierszy.

Możesz także zobaczyć: http://goo.gl/ATnj6j

Suresh Kamrushi
źródło
A co zrobimy, jeśli uprawnień będzie wiele, na przykład 100?
ypercubeᵀᴹ
2
Wysłałeś 3 identyczne odpowiedzi - na różne pytania! - wszystkie opublikowane dzisiaj w odstępie kilku minut. To nie jest dobra praktyka. Jeśli uważasz, że pytania są identyczne lub wystarczająco podobne, możesz głosować, aby zamknąć je jako duplikaty (lub oflagować je, jeśli nie masz reputacji, aby głosować na zamknięcie).
ypercubeᵀᴹ
Edytuj również link i wyjaśnij, co ma (więcej szczegółów, czy to Twój blog, czy ktoś inny itp.?)
ypercubeᵀᴹ
Nie kopiuj i nie wklejaj tej samej odpowiedzi, rozpylając ją na kilka starych pytań. Jeśli te pytania są takie same, oznacz je jako duplikaty.
Aaron Bertrand