Мысль об отказе от моей идеи написать пользовательский член и поставщик ролей. Мнения?

Question

У меня есть веб-приложение, я здание в ASP.NET, который имеет следующие требования безопасности:

1. должны быть в состоянии интегрировать с помощью схемы аутентификации мастера, который проходит назад уникальный ключ к приложению к указать, что пользователь зарегистрировался через сторонний сайт.
2. Должен быть в состоянии использовать существующие таблицы пользователей/ролей.
3. Может использовать проверку подлинности форм и разрешить пользователям входить в систему через отдельную страницу входа, если они не являются участниками стороннего сайта.

Я попытался настроив SQL роли и членство провайдеров, но я столкнулся с проблемами, в частности, что существует строго типизированный объект MembershipUser, который имеет UniqueIdentifier (providerKey) и не имеет места для моих пользовательский набор ключей (их будет два), которые идентифицируют пользователей.

Должен ли я отказаться от моей реализации поставщика членского членства и просто пойти с cookie/сеансом вместо этого? Я бы очень хотел использовать встроенные функции, но это не кажется выполнимым.

Answer 1

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

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

Answer 2

Пойдите для этого, here's the source to the built in ASP.NET 2.0 Membership provider из блога Скотта Гатри.

Answer 3

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

Я создал свою собственную модель пользователя. Это позволяет мне иметь гибкую ролевую модель внутри моего приложения. Я могу свободно создавать контекстные роли домена и отделять их от реальной модели пользователя.

Это действительно не так сложно. Не забудьте солить ваши пароли и т. Д. И прочитать некоторые книги по безопасности.

Вы можете использовать FormsAuthentication с этим подходом.

Большинство систем, которые полагаются на провайдера членства asp.net, действительно шизофреничны. У вас будет 2 таблицы пользователей, например, в CommunityServer у вас есть aspnet_users и cs_Users, где cs_Users ссылается на MemberhipId aspnet_users и где он вводит еще один UserId. Он также отражает имя пользователя и т. Д.