Есть ли реальная выгода от использования аутентификации ASP.Net с ASP.Net MVC?

Question

Я интенсивно исследую это последние несколько дней.

Мы разрабатываем сайт ASP.Net MVC, который должен поддерживать более 100 000 пользователей. Мы хотели бы сделать это быстрым, масштабируемым и простым. У нас есть собственные таблицы базы данных SQL для user и user_role и т. Д. Мы не используем серверные элементы управления.

Учитывая, что серверные элементы управления отсутствуют, и необходимо будет создать пользовательский членство в членстве, в чем еще преимущество использования ASP.Net Auth / Membership?

Другой альтернативой может быть создание пользовательского кода для добавления уникального идентификатора клиента в файл cookie и аутентификации с ним. Или, если мы параноики по поводу снифферов, мы могли бы также зашифровать куки.

Есть ли реальная выгода в этом сценарии (данные MVC и данные клиентов находятся в наших собственных таблицах) по сравнению с использованием структуры аутентификации / членства ASP.Net, или это полностью настраиваемое решение - жизнеспособный маршрут?

Обновление: я нашел одного человека (Мэтта Бриггса), который, похоже, пришел к некоторым из тех же выводов, что и я: Это происходит по этой ссылке: http://webcache.googleusercontent.com/search?q=cache:Xm1-OrRCZXIJ:mattcode.net/posts/asp-net-membership-sucks+asp.net+membership+sucks&hl=en&gl=us&strip=1

Членство в ASP.net плохо спроектированный API, который небезопасен из коробка, не в хорошем состоянии, и дает разработчикам ложное чувство безопасность. Аутентификация это выходные проект, если вы не строите рамки, но все же большинство .net разработчики слепо следуют официальным API, при условии, что основной Корпорация, как MS может потушить что-то приличное.

Answer 1

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

Для перечисления «преимуществ» требуется перечислить все меры безопасности, которые были приняты классами FormsAuthentication, что является длинным списком. С головы до головы, я могу подумать несколько:

1. Хэши паролей
2. Защита от SQL-инъекций
3. Защита куки, в которой хранится билет аутентификации
4. Использование и хранение билета вместо имени пользователя в куки.
5. Проверка на каждой странице, чтобы убедиться, что пользователь аутентифицирован
6. Заполнение IPrincipal и IIdentity для текущего пользователя
7. Перенаправление после входа в систему (предоставляется функция)
8. Обработка неудачных попыток входа в систему
9. Блокировка и разблокировка пользователей
10. Интеграция ActiveDirectory
11. Возможность легко устанавливать и изменять требования к длине и сложности пароля.
12. Соление (от Hightechrider) ....

Answer 2

Я написал свой собственный после прочтения всех хранимых процедур в поставщике членства ASP.NET. Это не сложно, и у вас гораздо больше контроля в конце дня.

Если вам нравится конфигурация XML, строки со слабым типом для ролей, небезопасные по умолчанию, случайные файлы web.config, засоренные в ваших каталогах вместо чистого интерфейса маркеров на ваших классах страниц, чтобы сказать «не требуется учетная запись», несколько попаданий в базу данных для одного входа в систему пользовательские объекты, которые не загружены из вашего текущего ObjectContext / DataContext и возможность менять провайдеров на лету (ау, кто это использует ?!), выбирают встроенные.

Если нет, создайте свой собственный, но если вы это сделаете, убедитесь, что вы добавили соль и зашифровали свои пароли, и сделайте правильный зашифрованный cookie, пожалуйста.

Answer 3

Просто чтобы устранить потенциальное заблуждение, использование идентификатора клиента, зашифрованного или нет, чрезвычайно уязвимо для снифферов. Вместо этого вы хотите создать заявку на вход во время успешной аутентификации и сохранить этот идентификатор в файле cookie. Это не защитит анализаторов от кражи сеансов, но, по крайней мере, сеанс (в конце концов) истекает, а идентификатор клиента - нет.

Answer 4

Вы можете настроить свой собственный провайдер. За кулисами провайдер членства использует ту же реализацию FormsAuthentication, которую вы напишите. В любом случае, я прочитал, что основные проблемы с производительностью, с которыми вы столкнетесь, будут связаны с хранимыми процедурами SQL SERVER, которые извлекают данные. В одной из книг о построении портальной системы Омара аль-Забира он упоминает некоторые улучшения хранимой процедуры, которые могут привести к более высокой производительности.

Answer 5

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

Самым большим преимуществом является то, что уже заявили другие; зачем изобретать велосипед?

Если вы реализуете свой собственный пользовательский интерфейс входа в систему с использованием MVC, вы можете использовать его также при переключении на другого поставщика членства.