Как позволить несколько методов аутентификации в ASP.NET?
Я создаю новый ASP.NET, приложение MVC (в C#) и одно из требований должно создать новую базу данных участников. Для этого нам были бы нужны роли для управления различными типами участников и профилей для управления дополнительными метаданными, присоединенными к каждому участнику. Пока неплохо просто используйте стандартный MembershipProvider, RoleProvider и ProfileProvider, обеспеченный как часть Платформы.NET.
Однако выгода - то, что я хотел бы позволить различные методы аутентификации. Я хотел бы Учетные записи, и Данные для входа в систему, чтобы иметь связь "один ко многим" (одна учетная запись может иметь много присоединенных данных для входа в систему). Пользователь, например, мог бы иметь и счет OpenID и ActiveDirectory, наложенный арест в их учетную запись.
Однако после экспериментирования с несколькими путями мы выбрали маршрут MembershipProvider (объяснил, как это было достигнуто как ответ ниже).
Мой вопрос, как люди сделали это прежде и как люди предложили бы, чтобы я приблизился к нему? Это, кажется, что-то, что достигается на множестве сайтов, все же поиск на здесь не возвращает ничего твердого для проигрывания вокруг с.
Править: После оглядывания в течение хорошего периода часов в течение ночи и этим утром - я все еще не convincinced, что забой скота единственного MembershipProvider был бы самой легкой опцией. Наличие нескольких MembershipProviders дают тот же эффект?
РЕДАКТИРОВАНИЕ ЩЕДРОСТИ: Без ответов я предполагаю, что нет никакого более оптимального решения, которое тот я отправил как ответ. Этот действительно имеет место? Я предлагаю щедрость, чтобы попытаться видеть, есть ли у кого-либо дальнейшие мысли об этом и существуют ли лучшие альтернативы.
ЩЕДРОСТЬ ПРИНИМАЕТ РЕДАКТИРОВАНИЕ: Я думаю, что WIF является ответом, столь принятым ниже для.NET 4 выпуска и возможно другие версии, как это, вероятно, работает с 3,5. Кроме этого, возможно, забитый MembershipProvider или адаптированный могут все еще быть релевантными.
3 ответа
На мой взгляд, «реальный способ» выполнения этого является использование Федерации с Wif (Фонд идентификации Windows, ранее женевской структуре).
Идея состоит в том, что вы отделяете аутентификацию из авторизации . Аутентификация выполняется так называемым STS (службой безопасности безопасности), и она управляет всеми возможным механизмом входа в систему, который вы хотите поддержать. Когда пользователь был аутентифицирован, STS выдает токен, содержащий набор претензий и идентификатора пользователя. Этот токен отправляется на веб-сайт (называемая полагающейся вечеринкой в этом Lingo), и на веб-сайте определяется, какие части сайта пользователь имеет доступ к претензию в токене. Wif поставляет как членство, так и поставщики ролей, которые извлекают информацию от токена.
Вы можете прочитать о создании веб-сайта, предусмотренных здесь .
Одним из плюсов этого подхода является разделение опасений между аутентификацией и разрешением. Вам не нужна какое-либо комплексное членство и рольпроводы на вашем сайте. Кроме того, STS можно использовать повторно использовать для аутентификации пользователей к другим приложениям, которые вы могли бы иметь без них, чтобы зарегистрироваться более одного раза (эффективно достижение единого входа)
Недостаток - это то, что вам придется провести некоторое время, изучающее эти концепции и кодирование твои STS. Ум на вас, не сложно кодировать STS с WiF, но это либо не в 100% тривиальной задаче.
Если мне удалось щекотать ваш интерес, я бы порекомендовал, чтобы вы начнете считывали этой белой бумаги .
С уважением,
Клаус
Одна идея, которую мы следили, это создать пользовательское членство / роль / провайдера профиля. Мы значительно настроили методы логина / аутентификации и иметь дополнительную таблицу логинов. Эта таблица в основном только что содержится:
LoginID (Auto-Incremental ID, PK)
UserID (FK)
LoginSystemID (FK)
...blah blah
В пределах вышесказанного, логинсистемида была ссылкой на таблицу внешнего поиска, которая помогла системе определить, какую службу аутентификации использовать (например, Standard, AD, OpenID, FacebookConnect - ETC).
Проблема, в которую мы столкнулись, заключалась в том, что поле имени пользователя в членомПровидере не может быть пустым, и в то время как в нашей схеме у каждого был UserID (это было их имя учетной записи), у них не было имени пользователя, которое было уникально. Мы должны были обойти это, создавая GUID и используя это. Это, конечно, скрыто от пользователя, а атрибут DisplayName от наших пользователей может быть отображен вместо этого.
Это все было сделано с помощью формы (проверки рекламы были выполнены через проверки LDAP). Тем не менее, дополнительный слой (вебформ) был добавлен с соответствующими настройками в IIS, который предоставил средство для автоматического WindowsAuthentication - мы перенаправляем там, что мы чувствуем, что пользователь, скорее всего, будет внутренним (на основе IP-адреса).
Используйте стандартные рамки. См. http://blogs.teamb.com/craigstuntz/2009/09/09/38390/
Вы можете иметь неограниченное количество методов аутентификации, прикрепленные к одной учетной записи, магия находится в формате . .SetauthCookie (имя пользователя, CreatePersistentCookie); заявление