Как мне создать сеть сайтов, которые понимают единый вход?

Question

У меня есть несколько сайтов (Asp.Net), для которых я хотел бы иметь единый вход для ...

Я бы хотел, чтобы пользователь зашел на Сайт1 и связал Сайт1 с центральным сервером единой регистрации (SSS).

Затем SSS определит, что пользователь не вошел в систему (не уверен как), и перенаправит пользователя на экран входа в систему (все еще на SSS).

В случае аутентификации пользователь будет перенаправлен обратно на Сайт 1.

Сайт1 будет воспринимать это прибытие как новый и, вероятно, спросит SSS, если пользователь вошел в систему. На этот раз SSS предполагает, что данный пользователь действительно вошел в систему. И поэтому Site1 может сохранить этот факт в своем сеансе для дальнейшего использования (возможно, с некоторым подходящим временем ожидания)

Сайт1 будет содержать ссылку на Сайт2, по которой пользователь может перейти.

Прибытие на сайт 2 должно инициировать попытку сайта2 аутентифицировать пользователя.

Как я могу идентифицировать пользователя, прибывающего на Сайт2, как того же пользователя, который уже посетил Сайт1, и обнаружить, что они уже прошли аутентификацию, чтобы им не нужно было входить во второй раз?

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

Обновление: в настоящее время я не могу гарантировать, что Site1, Site2 и SSS будут находиться в одном домене ... Так что я не думаю, что куки-файлы его урежут.

Answer 1

Не выбрасывайте OpenID так быстро - как владелец сайта, вы сами выбираете, какого поставщика OpenID вы выбираете для поддержки. Вы можете запустить собственный сервер OpenID и доверять только ему.

Кроме того, помните, что OpenID - это система аутентификации - как пользователь X доказывает, кто он такой, какой он есть.

Здесь, в StackOverflow, они автоматически создают учетные записи, когда кто-то использует OpenID для входа в систему - но вам не нужно этого делать. Вы можете иметь полный контроль над созданием учетной записи, с OpenID, связанным с каждой учетной записью.

Помните также, что (как правило) любое программное обеспечение, которое вам не нужно писать и поддерживать, - это хорошо.

Answer 2

Сделайте это так же, как все остальные, передайте сгенерированные БД токены между сайтами с помощью GET или POST, а затем подтвердите эти токены обратно в веб-сервис, напрямую взаимодействующий с БД.

Итак, пользователь хочет зайти на сайт 1 (www.domain1.com). Сайт 1 проверяет сеанс / cookie для входа в локальный домен, не может их найти, перенаправляет пользователя на http://logindomain.com/?return=www.domain1.com. Если существует более ранний файл cookie логиндомена (от входа до аффилированных сайтов), отправьте его обратно на сайт 1. Если нет, делайте все, что вам требуется для аутентификации пользователя (проверки KERBEROS, аутентификация с помощью форм, openID и т. д.) для генерации уникального токена. Сохраните это в файле cookie для logindomain и перенаправьте их туда, куда указывает «возврат», с прикрепленным токеном: http://www.domain1.com/?token=123456. Как только домен1 проверяет токен в отношении веб-службы (или непосредственно в базе данных токена), он может установить собственный локальный сеанс входа / cookie с учетными данными пользователя.

Итак, вы находитесь на сайте 2 (www.domain2.com) и заходите, чтобы войти. Вы снова будете перенаправлены на logindomain с набором? Return var, но на этот раз он не запрашивает пароль - он уже содержит ваш токен в своем файле cookie единого входа. Вы сразу же будете перенаправлены обратно на: http://www.domain2.com/?token=123456 (тот же токен, что и для site1). Domain2 снова проверяет токен и позволяет войти без проверки пароля.

Это становится немного сложнее, если вы меняете URL-адрес входа на лету или пытаетесь создать гибридного монстра AD / Forms Auth, как мне было поручено построить, но это, кажется, работает нормально и точно соответствует (на высокий уровень), что, по словам IBM и MS, делают их проприетарные системы единого входа.

Answer 3

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

Answer 4

Вы можете попробовать использовать общий сервер состояний сеанса.