Почему я должен использовать модель обеспечения безопасности Членства ASP.NET?

Я не вижу особой пользы в использовании членства для большого сайта. Это было продано как «решение» для аутентификации ASP.Net. Однако на самом деле похоже, что Microsoft просто пытается позиционировать старый продукт Membership Server как нечто такое, в чем вдруг все нуждаются.

Я работал на Membership Server в Msft около 10 лет назад. Также был ведущим разработчиком на shop.microsoft.com, и я могу сказать, что на этом сайте мы не использовали никаких внутренних серверных продуктов - ни коммерческий сервер, ни сервер членства. Не уверен, как они это делают сейчас - но я думаю, что общее мнение на тот момент заключалось в том, что пакеты такого типа обычно мешали тому, что мы пытались сделать.

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

Что я действительно не понимаю, так это то, что почти каждая книга ASP.Net, кажется, выдвигает это как единственный способ сделать это, а не как один из способов сделать это.

Если вы не единственный человек, который когда-либо будет работать над этим конкретным сайтом, я думаю, что тот факт, что он знаком разработчикам .NET, является хорошей причиной для того, чтобы пойти по встроенному маршруту членства. Другие разработчики, имеющие опыт работы с ASP.NET, могут подключиться к проекту и очень быстро освоить модель аутентификации / авторизации вашего сайта.

Мы используем встроенную модель провайдеров членства и ролей на нашем сайте, и она работает очень хорошо ... нам пришлось писать собственные классы провайдеров, поскольку мы используем другое хранилище резервных копий для данных (мы используем Microsoft Dynamics CRM ), но эти классы довольно просты и хорошо документированы. Проделав эту небольшую работу заранее, теперь мы можем использовать классы Membership и Roles в коде, а также различные серверные элементы управления, связанные с логином, на наших страницах.

Есть ли другая альтернатива, которую вы рассматриваете?

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

Это просто для того, чтобы вам не приходилось кататься самостоятельно.

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

Если Вы когда-нибудь хотите переместить свой сайт в кого-либо, отчасти уже сделанное портала программное обеспечение - как Сервер Сообщества или DotNetNuke с помощью поставщика членства допускает легкую миграцию. Можно даже использовать существующую базу данных и не иметь для реализации новых.

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

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

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

[Обновлено, чтобы отразить отзывы в комментариях]