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

Question

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

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

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

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

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

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

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

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

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

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

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 и перенаправьте их обратно туда, где " return " с указанием вашего токена: http://www.domain1.com/?token=123456 . После того как domain1 проверит токен по отношению к веб-службе (или напрямую по токену DB), он может установить свой собственный сеанс / 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

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