Проектування модуля аутентифікації користувача (Ролі та права)

Я намагаюся моделювати модуль аутентифікації користувача для бази даних MS SQL Server, яка буде задньою частиною додатка Delphi UI. В основному, я хочу мати облікові записи користувачів, де користувач належить лише одній групі. Група може мати "n" кількість прав.

Я також хочу додати в базу даних історію паролів, оскільки користувачеві потрібно буде змінити свій пароль, виходячи з налаштування програми (наприклад, кожні 90 днів).

Я також хочу зареєструвати подію щоразу, коли користувач увійде та вийде. Я можу поширити це на додаткові події в майбутньому.

Нижче ви знайдете мою першу тріщину. Будь ласка, дайте мені знати будь-які пропозиції щодо її вдосконалення, оскільки це вперше це роблю.

Чи бачите ви необхідність у додаткових атрибутах для рольової безпеки та обмежень щодо правил пароля / строків придатності?

Виходячи з заявлених вимог, ваша модель знаходиться в гарній формі.

Ось кілька пропозицій щодо вдосконалення:

• Ви не говорите так прямо, тому важко сказати - але схоже, що ви можете безпосередньо зберігати пароль користувача. Це було б дуже погано! Якщо ви подивитеся на загальні бази даних аутентифікації, паролі зберігаються в зашифрованому вигляді. Ви часто бачите і passwordстовпчик, і password_saltстовпець.

• У вашій USER_LOGSтаблиці є Eventстовпець. Вам не ясно, як це потрібно заповнити. Чи повинна бути EVENT_TYPEтаблиця, на яку USER_LOGSпосилаються? Це може спричинити дружніше звітування. Типові події включають в себе вхід, вихід із системи, помилка пароля, зміна пароля, скидання пароля, блокування, розблокування, ...

• У вашій GROUP_RIGHTSтаблиці не вказано, хто надав права. Для цілей аудиту люди часто ведуть журнал того, хто змінив запис та коли. Це може не бути проблемою для вас.

Ось кілька запитань щодо заявлених бізнес-вимог, які відрізняються від шаблону безпеки на основі "текстової книги" двома способами:

• Ви впевнені, що хочете, щоб користувачі були лише в одній групі? Перевага рольової безпеки полягає в тому, що ролі, як правило, є досить статичними, тоді як люди, які виконують ролі, приходять і йдуть досить часто. До цього входить те, що деякі люди часто «носять дві шапки».

• Ваш дизайн призначений лише для отримання грантів. Деякі системи включають надання та відкликання . Це дозволяє сказати, що широко доступне право недоступне для певної групи.

• У вас є користувачі та облікові записи, як USERSу вашому дизайні. Часто існує різниця між людьми та ідентифікаторами користувачів . Деякі ідентифікатори користувачів призначені для команд або машин, а деякі люди мають кілька ідентифікаторів користувачів для різних цілей. Це відмінність, яка б вам була корисною?

Я думаю, що побітний оператор - це найкращий спосіб впровадити дозвіл користувача. Тут я показую, як ми можемо це реалізувати за допомогою Mysql.

Нижче наведено зразкові таблиці з деякими зразками даних:

Таблиця 1 : Таблиця дозволів зберігати ім'я дозволу разом з ним біт 1,2,4,8..etc (кратне 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;

Вставте в таблицю деякі зразкові дані.

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

Таблиця 2 : Таблиця користувачів для зберігання ідентифікатора користувача, імені та ролі. Роль обчислюється як сума дозволів.
Приклад:
Якщо користувач "Ketan" має дозвіл "User-Add" (bit = 1) та "Blog-Delete" (bit-64), то роль буде 65 (1 + 64).
Якщо користувач "Мехата" має дозвіл "Перегляд блогу" (біт = 128) та "Видалення користувача" (біт-4), то роль буде 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;

Зразок даних-

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

Дозвіл на зберігання користувача Після входу, якщо ми хочемо завантажити дозвіл користувача, ми можемо запитувати нижче, щоб отримати дозволи:

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

Тут user.role "&" дозвіл.біт є оператором побітових операцій, який видасть результат як -

User-Add - 1
Blog-Delete - 64

Якщо ми хочемо перевірити погоду, певний користувач має дозвіл на редагування користувача чи ні -

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

Вихід = Немає рядків.

Ви також можете побачити: http://goo.gl/ATnj6j