Критика моей схемы системы аутентификации БД?

Question

Я разрабатываю веб-приложение RESTful, которое предоставит систему аутентификации для нескольких других приложений. Другие приложения будут запрашивать это приложение через HTTP и возвращать XML, описывающий прошедших проверку пользователей.

Приложение аутентификации должно отслеживать , какие пользователи могут делать на , какие приложения.

Я разрабатываю схему БД. Ниже мой первоначальный дизайн. (Предположим, что в каждой таблице есть столбец id.)

applications  # The various client apps that will query this auth system.
------------
name

users         # Table simplified for discussion
-----
username
password
email

roles
-----
name
application_id

roles_users
-----------
role_id
user_id

Идея в том, что кто-то пытался выполнить административную функцию в приложении «Инвентаризация оборудования». Таким образом, «Инвентаризация оборудования» сказала бы системе аутентификации «получить пользователя с именем пользователя xxx и паролем yyy». Затем он будет смотреть на возвращенный (через ActiveResource) объект User и проверять, содержит ли его roles Array Role с именем "ADMIN", который сам принадлежит объекту Application с именем "Equipment" Inventory».

Или, возможно, было бы лучше исключить таблицу applications и иметь гораздо больше ролей, например, "equipment_inventory_admin", "equipment_inventory_readonly", "job_tracker_admin" и т. Д.

Что важнее: нормализация сущности приложения или упрощение структуры таблицы? Возможно, после всего этого набора я только что ответил на свой собственный вопрос, но комментарии или предложения будут приветствоваться.

Answer 1

Схема выглядит вменяемой, Вы бы отправили

<login><username>abc</username><password>xyz</password><app>51</app></login>

и вы вернетесь

<auth> <user> <username>abc</a> <lastlogin>123456464</lastlogin> </user> <app> <name>Equipment Inventory</name> <version>3.1.5e</version> </app> <roles> <role>admin</role> <role>manager</role> <role>dataentry</role> </roles> </auth>

или

<auth><error type="1"></auth>

Answer 2

Определенно отделите аутентификацию от авторизации. (похоже, что вы делаете это; таблица «user» попадает в аутентификацию, остальные + user.id попадают в авторизацию)

Пароли: вы не храните их в открытом виде, не так ли? Хранение хэшей MD5 (+ соль для предотвращения атак) будет более безопасным.

Будет ли Kerberos возможностью? (возможно, он может быть адаптирован для работы через HTTP в качестве транспортного уровня)

Answer 3

Лично я склонен ошибаться в сторону нормализации. По крайней мере, по моему опыту, добавляются какие-то дополнительные модули. Гораздо проще добавить дополнительную строку в приложение и новые таблицы по мере необходимости, чем редактировать существующую схему и обновлять весь соответствующий код доступа к данным.

Редактировать: при втором взгляде вы можете объединить таблицу ролей и таблицу role_users. Это может быть одно место, которое определяет роли и то, как пользователи могут получить к ним доступ для каждого приложения.