ASP.Net_SessionId cookie через поддомены с использованием IE11

Question

У меня есть два веб-сайта ASP.NET: new.somecompany.com и legacy.somecompany.com.

«Новое» - это приложение интрасети, использующее проверку подлинности Windows. «Наследие» - это интернет и интранет; он использует аутентификацию форм.

С сайта «Новый» мой босс хотел бы иметь возможность щелкнуть ссылку и открыть окно браузера на уже зарегистрированную веб-страницу на сайте «Наследие». (Он хочет, чтобы это было сделано без изменений на устаревшем сайте.)

У меня есть решение, которое работает как с Chrome (версия 39.0.2171.95 м), так и с Firefox (версия 33.1.1), но не с Internet Explorer (версия 11.0 .9600.17501). На высоком уровне решение:

1. Контроллер на «новом» использует HttpWebRequest для входа в «наследие» с использованием сохраненных учетных данных.
2. Контроллер получает cookie «ASP.Net_SessionId» из ответа «legacy» и использует его в . Установите cookie «ASP.Net_SessionId» для домена «.somecompany.com» в браузере.
3. От браузера перейти на https://legacy.somecompany.com/somepage.aspx.

С Chrome и Firefox https://legacy.somecompany.com/somepage.aspx отображается в соответствии с хранимыми учетными данными, которые были использованы для входа. В IE 11 отображается страница входа в систему.

Я использовал средство анализатора сообщений Microsoft, чтобы узнать, что передается взад и вперед. В Chrome я вижу, как cookie ASP.Net_SessionId отправляется в HTTP-запросе на somepage.aspx. В IE 11 cookie не отправляется, и я получаю перенаправление на страницу входа в качестве ответа.

Есть ли что-нибудь, что я могу сделать, чтобы заставить это работать в IE 11?

Answer 1

Это blog дал мне ответ.В частности, этот пункт:

Проблема № 3 происходит на Windows Vista и выше, когда вы настроили один поддомен для запуска вне защищенного режима (например, поместить его в Trusted Zone) и другой связанной с субдомен запустите внутри защищенного режима (например, оставите его в интернет-зоне). Это не очень распространено, , но может возникнуть, если вы, например, поместите login.live.com в доверенную зону , но не поместите mail.live.com в доверенную зону. Основная причина этой непонятной проблемы заключается в том, что защищенный режим и не защищенный режим не делят файлы cookie, и, следовательно, cookie, установленный на сайте вне защищенного режима, не будет отображаться на сайте с внутри защищенного режима и наоборот.

В моем случае «new.somecompany.com» находился в локальной зоне интрасети в настройках IE, но «legacy.somecompany.com» не был. После добавления «legacy.somecompany.com» в зону интрасети, мой код работал в IE 11.

Answer 2

У меня была аналогичная ситуация. Совсем недавно я разработал веб-приложение, которое я хотел бы развернуть один раз и развернуть (в iFrame) на сайте Windows Authenticate and Anonymous.

Пользователь должен быть зарегистрирован Активным Директором или Вход на внешний сайт.

Вот как я справился с этим. В обоих случаях сайт iFrame работает в том же домене (как вы показываете) site1.company.com или site2.company.com

Вот как я его обработал.

1. Сайт A: Пользователь регистрируется, шифрует имя пользователя и сохраняет его в файле cookie. (Я использовал шифрование AES с закрытым ключом).

2. Сайт B: Прочтите файл cookie, расшифруйте идентификатор пользователя и зарегистрируйте пользователя на сайте.

В файле cookie также содержится зашифрованное значение (время даты), и это значение проверяется на 3-секундный срок действия.