Как реализовать единый вход в MVC4

Question

Как реализовать Зингель Sign On (SSO) в кросс-домен MVC4 веб-приложений

Answer 1

И наконец, я могу реализовать. Ниже перечислены шаги, которые я сделал

• Войти в App1
• Получить Варианта Войти с App2
• Нажмите на кнопку «Вход с App2»
• Перенаправление экране входа App2
• по щелчку кнопки входа в приложение 2, которая перенаправляется на SSOInMVCWcfService. Здесь метод Login вызывает метод Аутентификация службы App1, т. Е. SSOAuthService. Если аутентифицируется, то генерирует токен для этого имени пользователя, а также извлекает идентификатор пользователя из службы App1.
• После того, как маркер и идентификатор пользователя были получены для этого пользователя с проверкой подлинности, эти значения вводятся в таблицу, например «SessionDetails» в базе данных.
• Затем отправьте идентификатор пользователя и токен для текущего пользователя в App2.
• Теперь App2 отправляет returnurl, то есть URL-адрес аутентифицированной страницы app1 вместе с идентификатором пользователя и токеном на страницу входа в App1, добавив эти значения в виде файлов cookie в объекте Response.
• Теперь на странице входа в App1 эти файлы cookie извлекаются и на основе идентификатора пользователя текущее имя пользователя извлекается из таблицы «SessionDetails».

Answer 2

же домен SSO может быть легко достигнуто путем установки domain свойство куки проверки подлинности форм в корень домена и настройки тех же машинных клавиш для обоих приложений.

Перекрестный домен SSO является более сложным. Существуют различные методы его реализации. Например, StackExchange использует локальное хранилище HTML5. Их механизм описан в this blog post.

Вот некоторые из основных шагов:

1. Настройки мастеров-домен для пользователей для входа в систему. Например logon.com
2. Когда пользователь, не прошедший проверку подлинности, пытается получить доступ к защищенному ресурсу в некоторых из двух приложений, он перенаправляется в домен входа для аутентификации.
3. Пользователь аутентифицируется, и домен входа в систему генерирует идентификатор сеанса, содержащий имя пользователя зарегистрированного пользователя. Этот идентификатор сеанса шифруется с использованием симметричного алгоритма с общим секретом между 3 доменами. Домен входа также устанавливает cookie для проверки подлинности форм, чтобы указать, что пользователь уже прошел аутентификацию.
4. Область входа в систему переадресовывает обратно на защищенный ресурс, проходящий по идентификатору сеанса.
5. Приложение, содержащее защищенный ресурс, расшифровывает идентификатор сеанса, чтобы извлечь имя пользователя и установить cookie для проверки подлинности форм в своем домене.
6. Пользователь запрашивает защищенный ресурс во втором домене.
7. Поскольку он еще не аутентифицирован, он перенаправляется в домен входа.
8. Пользователь уже аутентифицирован в домене входа в систему, и сгенерирован и передан идентификатор сеанса с использованием того же метода.
9. Второй домен расшифровывает идентификатор сеанса, чтобы извлечь имя пользователя и испустить файл cookie проверки подлинности для второго домена.

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