Доступ к однопользовательским веб-сайтам с перекрестным доменом с использованием .net

Question

Предположим, у меня есть два веб-сайта, которые живут на разных доменах, и они прошли аутентификацию с помощью входа в систему единого входа. Я вхожу на первый веб-сайт и аутентифицируюсь, и теперь я решил посетить второй веб-сайт, используя ссылку, видимую на 1-м веб-сайте. Эта ссылка перенаправляется на второй веб-сайт и не требует учетных данных. (Обратите внимание, что эти веб-сайты разработаны и размещены какой-либо другой компанией, и у меня нет доступа к исходному коду. У меня есть один учетный данные для входа в систему, и я ожидаю получить доступ к данным страницы второго веб-сайта)

Я хочу доступ к веб-сайтам с использованием .net-кода. Я проделал определенную работу и перешел к ссылке на первый сайт, используя HTTP-запросы и файлы cookie, которые перенаправляются на второй веб-сайт. Но вскоре после того, как я нажал ссылку, он откроет домен 2 на новой вкладке браузера и также создаст новый идентификатор сеанса. Он не имеет никакой связи с первым cookie веб-сайта. Но я могу получить доступ к данным веб-сайта 2, когда я передаю URL-адрес и текущий идентификатор сеанса веб-сайта 2 вручную.

Есть ли какой-либо механизм безопасности для входа в систему SSO, который может быть прорван для доступа к общему идентификатору сеанса как для веб-сайта 1, так и для веб-сайта 2? Как найти соединение между двумя доменами, когда у них есть два идентификатора сеанса. Я не могу публиковать коды здесь, так как у него есть информация о конфиденциальности моего клиента.

Answer 1

Я решил проблему. Было состояние запроса и ретрансляции SAML, которые были отправлены на сервер регистрации из обоих доменов. Несмотря на то, что они не идентичны, мы должны учитывать их при доступе к данным формы. Также с кукисами мне пришлось отправить pls_login_cookietime с самого первого запроса на последний запрос.

Ex:

вар печенье = новый { pls_login_cookieTime = Cookietime.CookieValue ("pls_login_cookieTime"), pls_login_SimpleSAMLSessionID = HttpUtility.UrlEncode (login.CookieValue ("pls_login_SimpleSAMLSessionID")), TimeOutCheckID = Войти .CookieValue ("TimeOutCheckID"), pls_login_SimpleSAMLAuthToken = login.CookieValue ("pls_login_SimpleSAMLAuthToken"), pls_login_rememberme = login.CookieValue ("pls_login_rememberme")

Здесь Co okietime и login - это два разных URL-адреса, где CookieTime является исходным URL-адресом, а логин включает URL-адрес сервера регистрации. Несмотря на то, что логин не предоставляет ответ cookie как pls_login_cookieTime, я должен был передать его для окончательного URL-адреса в качестве заголовков запросов.

У них было очень мало путаницы. Если вы используете такие инструменты, как скрипач, чтобы проверить HTTP-запросы, вы можете понять большую часть части, как они управляли куки-файлами в нескольких доменах. Отдых в ваших руках. Вы должны думать немного жестко и по-другому. Но в целом это не сложно. Это просто смущает.