Вход для проверки подлинности NT

Question

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

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

Возможно ли это сделать?и как бы я этого добился?Есть ли лучший способ сделать это?

Answer 1

Вот (непроверенная) теория, детали которой будут в значительной степени зависеть от того, какие типы аутентификации будет принимать сайт Sharepoint.Я займусь Базовые модели, так как это самое простое.

Вы напишете некоторый JavaScript, который использует XMLHttpRequest для отправки запроса на сайт Sharepoint, и добавите свое имя пользователя и пароль в заголовки запроса.Их браузер запустит этот JavaScript и войдет в систему на сайте Sharepoint.

Теперь, когда пользователь нажимает на ссылку, браузер клиента должен иметь кэшированные учетные данные для отправки на сайт Sharepoint.

Возможные проблемы:

• XMLHttpRequest не разрешает междоменную аутентификацию
• Браузер и XHR не обмениваются информацией об авторизации
• Sharepoint и XHR не могут договориться о методе аутентификации

Другим вариантом является прокси-подключение к Sharepoint, которое позволяет вам входить в систему на стороне сервера (минуя ограничения XHR и безопасность браузера), но требует нагрузки на ваш сервер и, возможно, некоторых проблем с целевым URL.

Answer 2

Как другой сайт подтвердит ваше имя пользователя и пароль?

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

Что делать, если ваш сайт предоставил токен пользователю, который представляет этот токен новому сайту, который, в свою очередь, просит ваш сайт подтвердить этот токен.По сути, второй сайт доверяет вам сообщить им, кто этот пользователь.

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

Answer 3

Если вам нужно пройти аутентификацию на втором сайте, возможно, вам потребуется создать новый поток и вызвать Windows LogonUser API.Как только у вас будет токен безопасности, назначьте его новому потоку и установите соединение через этот поток.

LogonUser требует расширенных привилегий и не является управляемым кодом, поэтому при его использовании возникают довольно серьезные проблемы.Но это был единственный обходной путь, который я смог найти, чтобы заставить сайт, прошедший проверку подлинности Forms, взаимодействовать со службой / сайтом, прошедшим проверку подлинности Windows.

Надеюсь, это поможет.

Answer 4

Является ли это средой интрасети?Если это так, то им все равно не нужно входить в систему.Если sharepoint настроен с использованием "Интегрированной аутентификации" и сайт указан в IE как доверенный сайт, браузер будет использовать там сетевой кредит для автоматического входа в систему.Это можно настроить на firefox также хорошо.

Answer 5

Ваши пользователи не смогут напрямую подключиться к сайту NTLM, не получив запрос NTLM.Я бы написал то, что фактически было бы прокси-сервером для сайта NTLM;т.е. ваш серверный код будет иметь учетные данные для подключения к сайту NTLM, и он проходит через запросы от ваших пользователей.

Как вы уже упомянули, это SharePoint (плюнуть) имейте в виду, что в SharePoint есть множество веб-сервисов, которые вы могли бы использовать для этого (вместо того, чтобы выполнять очистку экрана).