Как разрешить несколько методов аутентификации в ASP.NET? - PullRequest
Новая
       22

Как разрешить несколько методов аутентификации в ASP.NET?

27 голосов
/ 15 января 2010

Я создаю новое приложение ASP.NET MVC (в C #), и одним из требований является создание новой базы данных участников. Для этого нам потребуются роли для управления различными типами участников и профили для управления дополнительными метаданными, прикрепленными к каждому члену. Пока все хорошо, просто используйте стандартные MembershipProvider, RoleProvider и ProfileProvider, предоставляемые как часть .NET Framework.

Однако уловка в том, что я хотел бы разрешить разные методы аутентификации. Я хотел бы, чтобы учетные записи и учетные данные для входа имели отношение один ко многим (к одной учетной записи может быть присоединено несколько учетных данных для входа). Например, пользователь может иметь учетную запись OpenID и ActiveDirectory, присоединенную к его учетной записи.

Однако, после экспериментов с несколькими способами, мы выбрали маршрут MembershipProvider (объяснил, как он был достигнут, как ответ ниже).

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

РЕДАКТИРОВАТЬ: После осмотра в течение хороших часов в течение ночи и этим утром - я все еще не убежден, что разделка одного члена MembershipProvider была бы самым простым вариантом. Дает ли наличие нескольких MembershipProviders одинаковый эффект?

BOUNTY EDIT: Без ответов я предполагаю, что нет более оптимального решения, чем то, которое я выложил в качестве ответа. Это действительно так? Я предлагаю вознаграждение, чтобы попытаться выяснить, есть ли у кого-нибудь еще какие-либо мысли по этому поводу и есть ли лучшие альтернативы.

BOUNTY ACCEPT EDIT: я думаю, что WIF - это ответ, принятый ниже, для выпуска .NET 4 и, возможно, других версий, поскольку он, вероятно, работает с 3.5. Кроме этого, может быть, урезанный членство в ProviderProvider или адаптированный может все еще иметь значение.

Ответы [ 3 ]

16 голосов
/ 22 января 2010

По моему мнению, "реальный способ" сделать это - использовать федерацию с WIF (Windows Identity Foundation, ранее Женевская структура).

Идея состоит в том, что вы отделяете аутентификацию от авторизации . Аутентификация выполняется так называемой STS (Security Token Service) и управляет всеми возможными механизмами входа, которые вы хотите поддерживать. После проверки подлинности пользователя STS выдает токен, содержащий набор утверждений и личность пользователя. Этот токен отправляется на веб-сайт (называемый в данном жаргоне проверяющей стороной), и веб-сайт определяет, к каким частям сайта имеет доступ пользователь, на основании утверждений в токене. WIF предоставляет поставщики членства и роли, которые извлекают информацию из токена.

Подробнее о создании веб-сайта, поддерживающего заявки, можно прочитать здесь .

Одним из плюсов этого подхода является разделение интересов между аутентификацией и авторизацией. Вам не нужно никаких сложных членов и ролевых провайдеров на вашем сайте. Кроме того, STS можно повторно использовать для аутентификации пользователей в других приложениях, которые у вас могут быть, при этом им не нужно регистрироваться более одного раза (эффективно достигая единого входа)

Недостатком является то, что вам придется потратить некоторое время на изучение этих концепций и на кодирование вашей STS. Имейте в виду, что кодирование STS с помощью WIF несложно, но это и не 100% тривиальная задача.

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

С уважением,

Klaus

4 голосов
/ 18 января 2010

Используйте стандартные вещи фреймворка. Смотри http://blogs.teamb.com/craigstuntz/2009/09/09/38390/

Вы можете иметь неограниченное количество методов аутентификации, привязанных к одной учетной записи, волшебство в FormsAuthentication.SetAuthCookie(userName, createPersistentCookie); заявлении

4 голосов
/ 15 января 2010

Одна из идей, которой мы придерживались, - это создание собственного провайдера членства / роли / профиля.Мы значительно изменили методы входа в систему / аутентификации и добавили дополнительную таблицу логинов.Эта таблица в основном содержала: 

LoginID (Auto-Incremental ID, PK)
UserID (FK)
LoginSystemID (FK)
...blah blah

В приведенном выше примере LoginSystemID представлял собой ссылку на внешнюю справочную таблицу, которая помогла системе определить, какую службу аутентификации использовать (например, Standard, AD, OpenID, FacebookConnect -и т.д.).

Проблема, с которой мы столкнулись, заключалась в том, что поле Имя пользователя в MembershipProvider не могло быть пустым, и хотя в нашей схеме у каждого был идентификатор пользователя (это было имя их учетной записи), у них не былоИмя пользователя, которое было уникальным.Мы должны были обойти это путем генерации GUID и использования этого.Это, конечно, скрыто от пользователя, и вместо него может отображаться атрибут DisplayName из нашей таблицы Users.

Все это было сделано с помощью FormsAuthenication (проверки AD выполнялись с помощью проверок LDAP).Однако был добавлен дополнительный слой (веб-форма) с соответствующими настройками в IIS, который предоставил средство для автоматической проверки подлинности Windows - мы перенаправляем туда в том случае, если мы считаем, что пользователь, вероятно, будет внутренним (на основе IP-адреса).

...