Что такое хорошая схема базы данных для проверки подлинности форм с OpenId?

Question

Я пытаюсь найти хороший стандарт для схемы базы данных, который позволил бы мне сделать пару вещей. В основном я пишу веб-приложение, которое должно обрабатывать различные типы логинов. Во-первых, это стандартная учетная запись ASP Application Services, во-вторых, вход в систему OpenId / oAuth, а в-третьих, вход в Active Directory.

Какое хорошее предложение для схемы данных, которая обрабатывает большинство из них? Я планирую использовать DotNetOpenAuth для oAuth и OpenId. Я уже знаю, как заставить все эти элементы работать по отдельности, но я пытаюсь найти способ сделать их без хака, чтобы связать их все вместе.

Приложение также должно управлять различными разрешениями на основе этих пользователей. По сути, если есть группа «Администратор», то в группу можно добавить пользователя, будь то учетная запись AD, учетная запись OpenId или учетная запись Forms Auth, и приложение может проверить разрешения на уровне страницы или метода (используя MVC).

Открыт для предложений?

РЕДАКТИРОВАТЬ: Поскольку я не получаю никаких предложений, я постараюсь уточнить. Как правило, если я получаю идентификатор (скажем, это либо ключ пользователя OpenId, либо ключ пользователя oAuth, либо домен / пользователь AD), как я могу связать его со стандартным профилем / пользователем ASP Membership Profider? Должен ли я создать нового пользователя для членства со случайным паролем и связать учетную запись OpenId / oAuth / AD с профилем через свойства?

По сути, я ищу что-то похожее на этот сайт. Пользователь входит через что-то, создается профиль, что-то сохраняется, поэтому мы знаем, что это такое. По сути, мне просто нужна идея, как заставить все эти методы аутентификации работать вместе.

Спасибо!

Answer 1

Понял, я попытаюсь объяснить, что я сделал, чтобы решить эту проблему.

Сначала я решил отказаться от стандартных таблиц ASP Sql Services, для этого я создал свои собственные таблицы User, AuthenticationServices и AuthenticationServicesUsers.

Таблица User - это в значительной степени объединенные таблицы asp_Users и asp_Membership. Таблица AuthenticationServices - это список, в котором я планирую разместить информацию, содержащую службы аутентификации, которые я хочу использовать (например, Facebook, MySpace, MyOpenId, Google и т. Д.)

Поскольку я хотел, чтобы пользователи связывали столько сервисов, сколько они хотят, к своим учетным записям, я установил третью таблицу AuthenticationServicesUsers, где я храню UserId и AuthenticationServiceId.

Поскольку эта реализация не будет работать со стандартным SqlMembershipProvider, я пошел дальше и начал писать свой собственный пользовательский поставщик членства. Здесь я расширил функциональность, чтобы принимать различные методы, такие как метод CreateUser, который позволяет мне не передавать информацию о пароле, а вместо этого идентификатор, который я получаю от службы.

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

Спасибо за ваш ответ, хотя!