2014-10-03 1 views
0

У меня есть 3 веб-сайта ASP.NET MVC, работающие с Entity Framework на SQL-сервере. Каждый сайт работает как независимое приложение с независимыми базами данных. Я хочу, чтобы бизнес-клиенты могли создавать «Паспорта», а также токены, которые позволяют им входить в один сайт, одновременно регистрируя их на других сайтах. Чтобы войти на сайт, паспорт должен иметь действительную «визу», выдаваемую через систему Passport, паспорта могут управляться с помощью диспетчера сайтов Passport, который может использоваться администраторами для доступа к информации учетной записи пользователя с веб-сайтов A, B, и C и делайте админ. В каком-то смысле паспорт можно рассматривать как имеющее индивидуальную переписку с реальной личностью людей.Многопользовательский логин с одним «паспортом»

passport diagram

Вот мои вопросы, как я могу передать пользователю попытку входа с сайта A, чтобы проверить его с базой данных паспорта и возвращать результат к вебсайту? Как мне скрывать это общение? Другими словами, чтобы только приложения веб-сайта A, B, C могли проверить попытку входа в базу данных паспорта? Должно ли быть другое приложение, которое предоставляет этот интерфейс? Будет ли это веб-API ASP.NET?

Вторая часть моего вопроса, когда пользователь регистрируется на сайте A, им не нужно повторно указывать свои учетные данные, чтобы попасть на сайты B и C. Вместо этого при входе на сайт A они создают сеансы с сайтами B и C , или создать ключ, который может разрешать сеансы с сайтами B и C. Как бы выглядел этот процесс?

Я не ищу полного решения, но если вы можете указать мне на пример, к документации по технологиям/библиотекам/объектам, которые я сочтет полезными.

ответ

1

То, что вы ищете, доступно в Windows Identity Foundation. Просмотрите комплект разработчика на сайте и то, что вы хотите, достаточно легко выполнить.

Ваш «Паспортный сайт» называется службой маркеров безопасности (STS). Веб-сайты A, B и C называются «Оповещающие стороны» (RP). Рассмотрим простой случай, когда вы реализуете свой STS с использованием ADFS 2.0 (все ваши пользователи поддерживаются в Active Directory). Windows Identity Foundation (WIF) имеет модули аутентификации ASP.NET, которые могут работать из коробки с ADFS 2.0 через SAML. STS представляет пользовательскую информацию в форме «Претензий» и создает подписанный токен X509 со всеми претензиями и предоставляет это в качестве файла cookie для пользователя. РП могут читать токен, проверять подпись и использовать претензии для целей их аутентификации и авторизации.

Образец потока поясняется ниже:

a. Сайт пользователя для посещения A для первого раза

  1. Модуль WIF проверяет файлы cookie на наличие действительного токена. Поскольку пользователь не вошел в систему, нет токена.
  2. WIF делает HTTP-перенаправление браузера пользователя на сайт STS с использованием специального URL-адреса, который передает намерения (логин/выход из системы, имя RP и т. Д.).
  3. Сайт STS проверяет токен, а так как его нет, отображает страницу входа.
  4. Пользователь Регистрирует и получает токен с требованиями пользователя. Существует также второй токен, характерный для имени RP (это указывает логин для RP). STS перенаправляет обратно запрашивающий RP.
  5. Модуль WIF на сайте A теперь распознает токен и использует его для AuthN и AuthZ.

b. Рассмотрим теперь, что пользователь посещает веб-сайт B.

  1. Модуль WIF проверяет действительный токен. Поскольку он отсутствует, нет токена.
  2. WIF перенаправляет HTTP на STS с разными параметрами (изменен RP)
  3. STS проверяет токен входа. Поскольку Пользователь уже вошел в систему, он присутствует.
  4. STS создает маркер для веб-сайта B и перенаправляет обратно на сайт B.
  5. Сайт модуль B WIF распознает маркер и использует его для AuthN и AuthZ

Пользователь не должен снова войти в систему с его имя пользователя и пароль.

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

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