Я недавно перешел с традиционной разработки на основе веб-форм ASP.Net на MVC2, и я искал лучшие практики и нормы, которые MVC может использовать для создания долгосрочного поддерживаемого веб-решения.
Я пришел к реализации аутентификации и RBAC (доступ на основе ролей).Раньше у меня был простой статический RBAC, чтобы избежать сложности, но теперь с MVC я ожидаю лучших вариантов и большего контроля над традиционным подходом.API членства были по умолчанию для безопасности ASP.Net, но для этого требовалось много объектов БД, и у него также не было простого способа изменить его поведение, например добавить свойства в User или переопределить некоторые из его функций по умолчанию.
Подводя итог , в прошлом мне приходилось избегать членства API и использовать свой собственный простой подход на уровне Userservice для достижения простой безопасности и RBAC.У меня был контроль доступа на уровне страниц, и я управлял им из базового класса (Pagebase), из которого были получены все страницы веб-форм.Мне просто нужно было передать некоторые параметры роли для настройки безопасности страницы.Наше обслуживание пользователей и ролей довольно простое, и мне не нужны такие вещи, как секретный вопрос, хэш-пароль, соль и т. Д. По крайней мере, до сих пор.
Теперь, с MVC - мне нужно что-топохоже с центральным управлением.Я могу иметь либо уровень контроллера, либо авторизацию на уровне действия ([Authorize] или мой пользовательский).Я могу развернуть «Фильтр авторизации» (например, фильтр действий).Я также хочу пойти на динамический RBAC.Я хочу использовать функции членства, но я не хочу использовать его таблицы и избегать других дополнительных вещей, упомянутых выше.
Статический подход на основе API членства: Ролевая защита asp.net mvc
Я узнал, что могу переопределить поставщика членства, а также поставщика ролей , чтобы получить полный контроль над фоновой обработкой и использовать функции API членства и RBAC, которые находятся нак началу.
Например,
Пользовательские поставщики членства
Реализация поставщика ролей
Я прошел весь этот путь и хочу убедиться, что я на правильном пути и что этот подход постепенно приведет меня к динамическому RBAC, который я могу предоставить пользователям уровня администратора для настройки RBAC.Вот мои требования -
- Я надеюсь, что использование Membership API будет полезно с MVC и позволит мне переопределить реализацию по умолчанию.
- Я не хочу никаких дополнительных таблиц.Я хочу сохранить минимальные пользовательские / ролевые таблицы без ненужных специальных полей.
- Я могу использовать свой собственный подход уровня сервиса для доступа к таблицам в БД и управления ими - никаких значений по умолчанию для членства.
- Если слишкомКомплекс, который я могу сделать со статическим RBAC на данный момент, но в будущем я хочу иметь динамический RBAC.
- Я склонен использовать API членства только потому, что я вижу, что он может предоставить полезные атрибуты, которые в противном случае мне пришлось быразверните себя.
- Надеюсь, что это не станет беспорядочным, следуйте моему DAL / уровню обслуживания и разрешите уровень контроллера и уровень действия RBAC.
Просьба направить меня и поделиться своими предложениями.
РЕДАКТИРОВАТЬ 1: Я нашел кое-что еще от SO: (говорит, что выкатывает наше собственное)