Схема аутентификации / авторизации

Question

Существует ли лучшая модель данных для схемы аутентификации / авторизации?

Answer 1

Модель данных, которая состоит из сопоставления ролей и привилегий, является достаточно гибкой и подходит для большинства целей.

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

В коде вы проверяете (через свои роли), что пользователь обладает необходимой привилегией для выполнения функции.

Аутентификация является отдельной, это просто проверка того, кто пользователь, а не то, что он может сделать. Обычно вы должны поддерживать это разделение (хотя существуют схемы, разработанные таким образом, чтобы они заботились только о том, что может сделать пользователь, а не о том, кто они).

В вашем проекте вы можете визуализировать систему контроля доступа в виде матрицы (роли для привилегий).

Я бы также остановился на ответе «не хранить пароли» - вообще не создавайте собственную схему аутентификации. Вы, вероятно, ошибетесь. Повторно используйте тот, который доказан.

Answer 2

Самая важная вещь

Не хранить пароли

Хранить дайджесты паролей. См. RFC 2069 и эту статью в Википедии . Когда кто-то пытается аутентифицироваться, вы сравниваете дайджест его входных данных с дайджестом, который вы должны увидеть, совпадают ли его учетные данные.

Answer 3

Я добавлю предостережение к ответу С. Лотта «Не хранить пароли: хранить дайджесты паролей»:

Если вы действительно хотите защитить от атак, убедитесь, что вы используете соль в дайджесте; если это хорошо известный алгоритм, такой как MD5, и кто-то может получить хеш-вывод, то в свое время ЦП они могут быстро проверить возможные пароли, и если они найдут совпадение, то они получат пароль. Добавление соли предотвращает подобные атаки (см. Статью википедии ).

Вы можете попробовать OpenID , так как это довольно простой способ обработки аутентификации. Известные сайты (OpenID провайдеры ) обрабатывают для вас аутентификацию и криптографически утверждают, что лицо с идентификатором X правильно аутентифицировалось. Тогда вам просто нужно обработать авторизацию, какие личности X могут делать. Вы всегда можете ограничить, каким поставщикам удостоверений вы доверяете (например, вы можете доверять Yahoo, AOL и Blogger, но не случайным сайтам, поскольку технически любой может разместить свой собственный сервер поставщиков удостоверений).