Внедрение системы аутентификации с несколькими базами данных и несколькими поставщиками - PullRequest
Новая
       14

Внедрение системы аутентификации с несколькими базами данных и несколькими поставщиками

2 голосов
/ 15 мая 2009

Мы начали создавать приложение asp.net mvc. Приложение будет состоять из одной основной базы данных с пользователями, проектами, общими таблицами и т. Д. И многими базами данных (все с одинаковой структурой) с данными, относящимися к конкретному проекту. Использование может иметь несколько глобальных ролей (хранящихся в основной базе данных) и некоторые специфичные для проекта роли (хранящиеся в базе данных проекта), и каждый пользователь может быть связан со многими проектами.

Моя цель - создать систему аутентификации, которая будет поддерживать классическую аутентификацию по имени пользователя и паролю, а также аутентификацию OpenID (для этой цели мы используем DotNetOpenAuth) и систему авторизации, которая будет поддерживать систему ролей, которую я описал выше.

Но я сталкиваюсь с несколькими вопросами: 1.) Я думаю, что мы должны поддерживать обе опции аутентификации (имя пользователя / пароль и Ppenid) для одного пользователя, так что пользователям с именем пользователя / паролем не нужно будет создавать дополнительную учетную запись, когда они решат, что будут использовать OpenId, и я думаю, что мы должны поддерживать несколько OpenId для одного пользователя, как это делает SO (если какой-то провайдер не работает).

2.) Я думаю, что лучшая база данных для этого будет: 

table Users (UserId (PK), LastActivityDate)
table UsernameLogins (UserId (PK,FK), Username, Password, IsApproved, IsLockedOut, LastLoginDate, LastLockedOutDate, etc...)
table OpenIdLogins(OpenIdUrl (PK), UserId(FK),LastLoginDate)
table Profiles(UserId(PK,FK), DisplayName(Unique), Email (Unique), FirstName, LastName, Address, Country, etc...)
table Roles(RoleName (PK), RoleType(1=GlobalRole,2=ProjectRole).
table UserRoles(UserId(FK,PK), RoleName(PK)).

3.) Нужно ли создавать собственных провайдеров (MembershipProvider, ProfileProvider, RoleProvider)? Кажется, что MembershipProvider не очень подходит для аутентификации OpenId (и, конечно, я могу поддерживать только базовые методы (GetUser, ValidateUser))? Должен ли я реализовать MembershipProvider только для логина и пароля? Я думаю, что ProfileProvider и RoleProvider не так сложно реализовать? Должен ли я просто использовать FormsAuthentication и использовать свои собственные «сервисы»?

Мы также используем NHibernate и Spring для DI.

Любой совет будет оценен.

Спасибо!

Ответы [ 2 ]

1 голос
/ 15 мая 2009

1.) Я думаю, что мы должны поддерживать оба (имя пользователя / пароль и Ppenid) параметры аутентификации для одного пользователь, так что имя пользователя / пароль пользователей не нужно создавать дополнительные счет, когда они решают, что они будет использовать OpenId, и я думаю, что мы должен поддерживать несколько OpenId для один пользователь, как это делает SO (если некоторые провайдер не работает).

Это кажется разумным. Мне нравится, как вы проектируете, чтобы пользователи имели несколько OpenID. StackOverflow ограничивает пользователей только двумя, но пользователи часто имеют больше, и могут захотеть связать их всех. Я думаю, что имя пользователя / пароль - хороший вариант, если ваша целевая аудитория требует его OpenID. StackOverflow - отличный пример того, насколько простым может быть вход в систему при использовании чистого OpenID. Это может сделать вход менее занятым, чтобы не предлагать имя пользователя / пароль. Но опять же, предоставление обоих вариантов кажется наиболее ориентированным на клиента, поскольку дает им выбор. В будущей версии DNOA будет предложена интегрированная версия InfoCard Selector в его систему входа в систему OpenID, так что вы даже сможете напрямую принимать информационные карточки, но при этом они будут выглядеть и чувствовать себя как OpenID, поэтому ваша система не потребует никаких изменений.

2.) Я думаю, что лучшая база данных для этого будет: <snipped/>

Это похоже на разумную схему. Как вы обнаружили, разделение таблиц учетных данных обеспечивает максимальную гибкость.

3.) Должен ли я создавать своих собственных провайдеров (MembershipProvider, ProfileProvider, RoleProvider)?

MembershipProvider определенно не очень хорошо подходит для OpenID. Если бы вы поддерживали только вход через OpenID, я бы сказал, выбросьте его и не беспокойтесь о реализации своего. RoleProvider отлично работает с OpenID, так что это хранитель. Я слышал от других, что ProfileProvider нужен членство MembershipProvider для функционирования. Я не знаю, правда ли это. Но ProfileProvider требует, чтобы вы использовали схему базы данных SQL членства ASP.NET, что, на мой взгляд, плохо, если вы можете написать свою собственную схему БД, которую вы сделали. И если вы пишете свою собственную базу данных, хранение дополнительных данных о ваших пользователях должно быть тривиальным, поэтому вам не нужен поставщик профиля.

Если вы используете и имя пользователя + пароль, и OpenID, то иметь членство MembershipProvider, которое вы реализуете самостоятельно, скорее всего, будет возможно, но, по моему опыту, большинство MembershipProvider, которые содержат любой код OpenID, являются хитрыми и даже имеют дыры в безопасности. Так что я бы по-прежнему избегал использования MembershipProvider, если в вашей системе есть место для OpenID.

0 голосов
/ 15 мая 2009

Интересно ... важна поддержка нескольких OpenID. Похоже, что это больше роль поставщика OpenID. Например, я использую ClaimID и получаю то, что по существу означает «идентификацию пересылки» (в смысле пересылки электронной почты), чтобы я мог привязать ее к другим удостоверениям. Сейчас я не часто перепривязываю провайдеров, но провайдер может это сделать (то есть, когда вы будете перенаправлены на страницу входа, они могут спросить вас, какую личность вы в конечном итоге хотели бы представить). Итак, вопрос в том ... действительно ли это прикладная работа для реализации?

...