NTLM Security - сколько времени до истечения времени ожидания и не действует - PullRequest
1 голос
/ 01 октября 2011

Пользователь на мобильном устройстве переходит на веб-сайт / страницу, защищенную системой безопасности Windows NTLM.Пользователь предоставляет свои учетные данные и использует сайт.Они уходят и возвращаются позже, и им не требуется повторно вводить свои учетные данные.

Вопрос: Что определяет, как долго аутентификация действительна?Как лучше всего ограничить время, в течение которого он действителен, прежде чем им придется повторно вводить свои учетные данные Windows?

thx

1 Ответ

1 голос
/ 01 октября 2011

От чего зависит срок действия аутентификации?

Проще говоря, ваше приложение. Любой запрос, направленный на защищенный ресурс, будет вызывать весь процесс SPNEGO .

SPNEGO работает , по сути, сервером, отправляющим ответ HTTP 401 на первоначальный запрос с заголовком, указывающим, что он будет поддерживать проверку подлинности Negotiate или NTLM и т. Д. Помните, что HTTP не имеет состояния. Конечно, протокол SPEGNO в некоторой степени обходит это, поддерживая состояние на стороне сервера для каждого соединения; тем не менее, сервер всегда может контролировать это, либо 1) закрыв соединение, либо 2) отправив первоначальный ответ 401 клиенту, вызвавшему рукопожатие SPNEGO.

Как лучше всего ограничить время, в течение которого он действителен, прежде чем им придется повторно вводить свои учетные данные Windows?

Здесь важно понять, что многие пользовательские агенты (например, браузеры) собираются кешировать учетные данные пользователя после их ввода и просто использовать их для ответа на любые проблемы с переговорами (это похоже на то, как они обрабатывать базовую аутентификацию). Любой способ «заставить» пользователя повторно ввести свои учетные данные должен быть немного хитрым, поскольку пользовательский агент по сути обманывает сервер, заставляя его поверить, что пользователь повторно ввел свой пароль (технически, только SPNEGO). обеспечивает проверку того, что пользовательский агент знает идентификатор пользователя и пароль - сам протокол не может проверить, действительно ли кто-либо что-либо печатал на клавиатуре устройства).

Сверх того, что может сработать (и я не знаю, как вы можете сделать что-то подобное, не написав свой собственный обработчик SPNEGO на стороне сервера), это обмануть пользовательский агент в аннулировании кеша учетных данных. Чтобы сделать это, вашему серверу потребуется отправить начальный HTTP 401, чтобы начать согласование SPNEGO, а затем, когда клиент ответил первым шагом рукопожатия, повторно отправить исходную ошибку 401. Проблема здесь в том, что то, как это обрабатывается, будет сильно зависеть от рассматриваемого пользовательского агента. Некоторые, вероятно, предложат пользователю подтвердить свои учетные данные (поскольку, с точки зрения клиента, сервер говорит, что учетные данные неверны), а другие могут просто показать страницу с ошибкой, что, вероятно, нежелательно.

...