Как аутентифицировать пользователей в разных доменах, используя ASP.NET и iframes?

Question

Я делаю веб-сайт ASP.NET для клиента, который хочет сделать страницу своих отчетов доступной через IFRAME на других веб-сайтах посредников. Сайты реселлеров предоставляют одну и ту же услугу с разным брендированием. Мне нужно избегать, где только можно, требования, чтобы они реализовали любой код на своем веб-сервере, чтобы включить это - следовательно, используя iframes.

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

Мы можем использовать SSL-сертификаты сервера, но не любые федеративные логины (например, OpenId) - бизнес-выбор клиента.

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

Любые мысли приветствуются!

Answer 1

Ваша форма входа в систему может использовать некоторый javascript для отправки формы входа в систему в скрытый iframe (вы не можете использовать XMLHTTPRequest из-за проблем безопасности между доменами) для каждого домена, для которого требуется вход в систему.

Обязательно перенаправьте ваш iframe обратно на исходный домен, иначе вы не сможете получить статус входа из iframe из-за междоменной безопасности.

Последний трюк для поддержки IE - перевернуть бит зла ​​и добавить

P3P: CP="CAO PSA OUR"

к вашим заголовкам ответа HTTP. Что говорит браузеру: «Я не собираюсь делать ничего плохого, честного».

http://support.microsoft.com/kb/323752

http://www.w3.org/P3P/

Answer 2

Я не вижу удовлетворительного способа сделать это без внедрения какого-либо кода на сайте реселлера.

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

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

Ответ на этот запрос будет содержать строку фрагмента html, которую посредник может внедрить на любую страницу.

Этот фрагмент будет содержать iframe, который, в свою очередь, будет загружать отчет для вошедшего в систему пользователя непосредственно с основного сайта, используя его имя пользователя. Содержимое этого отчета будет содержать ссылку на таблицу стилей для конкретного продавца.

При таком подходе я бы сказал, что HTTPS не требуется в браузере, поскольку как реселлер, так и его пользователь проходят аутентификацию, и если этот процесс произошел по HTTPS, мы можем предположить, что перехватчика нет.

В случае, если секретный ключ или пароль пользователя были скомпрометированы, HTTPS из браузера все равно ничего не изменит.

Answer 3

Возможно, я что-то упустил, но если клиент прошел аутентификацию на вашем сервере, он все равно будет аутентифицирован, если вы просматриваете его через iframe.

Например, создайте HTML-страницу на своем сервере с помощью iframe для gmail. Пока вы проходите проверку подлинности с помощью gmail в своем браузере, на этой странице вы увидите входящие сообщения ...