Разработка модуля аутентификации пользователя (Roles & Rights)


15

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

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

Я также хочу регистрировать событие при каждом входе и выходе пользователя. Я могу распространить это на дополнительные события в будущем.

Ниже вы найдете мою первую трещину в этом. Пожалуйста, дайте мне знать любые предложения, чтобы улучшить его, так как я делаю это впервые.

Видите ли вы необходимость в дополнительных атрибутах для безопасности на основе ролей и ограничениях для правил паролей / периодов истечения срока действия?

DB-дизайн


Подробный блог находится здесь: goo.gl/ATnj6j
Суреш Камруши

1
Я чего-то не понимаю В пользовательской таблице у вас есть group_id. Может ли человек быть членом более чем одной группы?
Джонни

Ответы:


11

Исходя из ваших заявленных требований, ваша модель находится в довольно хорошей форме.

Вот несколько предложений по улучшению:

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

  • Ваша USER_LOGSтаблица имеет Eventстолбец. Вам не ясно, как это должно быть заполнено. Должна ли быть EVENT_TYPEтаблица с USER_LOGSссылками? Это может сделать для более дружественной отчетности. Типичные события включают вход в систему, выход из системы, сбой пароля, изменение пароля, сброс пароля, блокировку, разблокировку, ...

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

Вот пара вопросов относительно заявленных вами бизнес-требований, которые отличаются от шаблона безопасности на основе ролей в «учебнике» несколькими способами:

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

  • Ваш дизайн только для грантов. Некоторые системы включают предоставление и отзыв . Это позволяет вам сказать, что широко доступное право не доступно для определенной группы.

  • У вас есть пользователи и аккаунты, как USERSв вашем дизайне. Часто существует различие между людьми и идентификаторами пользователей . Некоторые идентификаторы пользователей предназначены для групп или компьютеров, а некоторые люди используют несколько идентификаторов пользователей для разных целей. Это различие, которое было бы полезно для вас?


3

Думаю, побитовый оператор - лучший способ реализовать права пользователя. Здесь я показываю, как мы можем реализовать это с 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» (бит = 1) и «Blog-Delete» (бит-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');

Разрешение Loding пользователя После входа в систему, если мы хотим загрузить разрешение пользователя, чем мы можем запросить ниже, чтобы получить разрешения:

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

Здесь user.role "&" allow.bit - побитовый оператор, который выдаст вывод как -

User-Add - 1
Blog-Delete - 64

Если мы хотим проверить погоду, у конкретного пользователя есть разрешение на редактирование или нет.

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

Выход = Нет строк.

Вы также можете увидеть: http://goo.gl/ATnj6j


И что мы будем делать, если разрешений много, например 100?
ypercubeᵀᴹ

2
Вы разместили 3 одинаковых ответа - на разные вопросы! - все опубликовано сегодня с разницей в несколько минут. Это не хорошая практика. Если вы считаете, что вопросы совпадают или достаточно похожи, вы можете проголосовать за их закрытие как за дубликаты (или пометить их, если у вас нет репутации, чтобы голосовать за закрытие).
ypercubeᵀᴹ

Пожалуйста, также отредактируйте свою ссылку и объясните, что у нее есть (более подробно, это ваш блог или кто-то еще и т. Д.?)
ypercubeᵀᴹ

Пожалуйста, не копируйте и не вставляйте один и тот же ответ, разбрызгивая его на кучу старых вопросов. Если эти вопросы совпадают, отметьте их как дубликаты.
Аарон Бертран
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.