Назад | Перейти на главную страницу

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

У меня есть система на основе ASP.Net; идентичные копии сайта работают на трех разных серверах, все под управлением Windows 2008R2 IIS7.5. У каждого сайта есть собственная база данных аутентификации с собственными пользователями, ролями, профилями и т. Д.

Я хотел бы объединить эти базы данных вместе, чтобы была одна единственная база данных аутентификации, совместно используемая тремя серверами, а затем пользователи могли входить на любой из трех серверов.

У основного сайта самый большой набор пользователей; на каждом из двух других сайтов есть только несколько пользователей / профилей, поэтому при необходимости можно воссоздать их вручную. Однако что мне нужно сделать, чтобы гарантировать, что хэширование / соль пароля действительны и могут использоваться на каждом сервере?

Это просто случай установки идентичного MachineKeyс в web.config? Мне также нужно установить идентичные ApplicationIdс в aspnet_Applications стол?

Если вы объедините две меньшие таблицы членства в большую, при переносе таблиц членства в большие таблицы вы можете изменить ApplicationID новых строк, чтобы они имели тот же ApplicationID, что и первая. После этого у вас будет 1 большое (большее) приложение пользователей, которое разделяют 3 приложения. Поскольку вы используете хеширование (я предполагаю, что ваш web.config имеет validation = SHA1), вам не нужно беспокоиться о машинном ключе, поскольку он не используется для проверки логинов - для этого нужна соль. Машинный ключ используется для шифрования таких вещей, как сеанс, данные формы и ViewState. Ничего страшного, если ключи машины остаются разными для каждого из приложений. (Если вы выполняете балансировку нагрузки одного приложения на нескольких серверах, вам нужно, чтобы они были одинаковыми.)

Теперь несколько предостережений.

  • Имена пользователей в базе данных членства должны быть уникальными, поэтому, если у вас есть какие-либо дубликаты в трех приложениях, вам придется определять, как действовать дальше, в каждом конкретном случае. Надеюсь, если есть дубликаты, это один и тот же человек, повторяющий имя пользователя в обоих приложениях, но это не обязательно так. (Два разных пользователя могут иметь имя пользователя «Кен» в разных приложениях, и в этом случае один из них должен будет выбрать новое имя пользователя.) В случае, когда это один и тот же пользователь, у них могут быть разные пароли или адреса электронной почты, поэтому нужно будет побеждать.
  • Один и тот же пользователь может иметь две разные учетные записи в разных приложениях. Вероятно, вы захотите использовать только один из них.
  • Электронные письма также могут быть настроены так, чтобы они были уникальными, и в этом случае у вас будет аналогичная проблема с разными именами пользователей, имеющими один и тот же адрес электронной почты. Хотя это может действительно помочь вам, поскольку будет легче изолировать, если у одного и того же пользователя есть две разные учетные записи.
  • Роли будут иметь разные идентификаторы RoleID, и их нужно будет объединить, а также необходимо соответствующим образом обновить записи UsersInRoles.
  • Если вы используете таблицу aspnet_Profile и у некоторых пользователей есть учетные записи более чем в одном приложении, вам придется выяснить, как объединить данные. На самом деле это верно для всех таблиц, но с большинством других таблиц вы, скорее всего, просто выберете одно поле из более популярного приложения (дата последнего входа в систему, IsUserLockedOut и т. Д.). Однако для данных профиля его необходимо объединить, поскольку он содержит несколько пар имя / значение.
  • Это само собой разумеется, но вы захотите провести довольно обширное тестирование. Мой список предостережений ни в коем случае не является исчерпывающим; плюс это, очевидно, может быть критическим изменением для кода пользовательского приложения.