NTLM 安全性 - 超时且无效之前多长时间
移动设备上的用户导航到受 Windows ntlm 安全保护的网站/页面。用户提供其凭据并使用该网站。他们离开并稍后返回，并且不需要重新输入凭据。
问题：什么决定了身份验证的有效时间？在他们必须重新输入 Windows 凭据之前，我们如何才能最好地限制其有效时间？
谢谢
A user on a mobile device navigates to a web site/page protected by windows ntlm security. The user provides their credentials and uses the site. They walk away and return later and they are not required to re=enter their credentials..
Question: What determines how long the authentication is valid? How best can we limit the time that it is valid before they have to re=enter their windows credentials?
thx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
简而言之，您的应用程序。任何针对受保护资源的请求都将强制执行整个 SPNEGO 流程。
SPNEGO 的工作原理本质上是由服务器向初始请求发送 HTTP 401 响应，其中包含header 表明它将支持 Negotiate 或 NTLM 等身份验证。请记住 HTTP 是无状态的。当然，SPEGNO 协议通过在每个连接的基础上维护服务器端状态来解决这个问题。然而，这始终可以由服务器通过 1) 关闭连接或 2) 向客户端发送初始 401 响应来强制进行 SPNEGO 握手来控制。
这里要认识到的重要一点是，许多用户代理（即浏览器）将在输入用户凭据后缓存用户的凭据，并简单地使用这些凭据来回复任何协商挑战（这类似于他们处理基本身份验证的方式） ）。任何“强迫”用户重新输入其凭据的方法都必须有点棘手，因为用户代理本质上是在欺骗服务器相信用户已重新输入其密码（从技术上讲，仅 SPNEGO提供用户代理是否知道用户 ID 和密码的验证——协议本身无法验证任何人是否确实在设备键盘上键入了任何内容）。
在我的脑海中，可能有效的方法（我不知道如何在不编写自己的 SPNEGO 处理程序服务器端的情况下执行类似的操作）是欺骗用户代理使凭证缓存失效。为此，您的服务器需要发送初始 HTTP 401 来启动 SPNEGO 协商，然后当客户端响应握手的第一步时，重新发送初始 401 错误。这里的问题是如何处理这将在很大程度上取决于所讨论的用户代理。有些可能会提示用户验证他们的凭据（因为从客户端的角度来看，服务器说凭据是错误的），但其他的可能只是显示错误页面，这可能是不可取的。
Simply put, your application. Any request aimed at a protected resource is going to force the whole SPNEGO process.
SPNEGO works by essentially by the server sending a HTTP 401 response to the initial request with a header indicating that it will support Negotiate or NTLM, etc. authentication. Remember HTTP is stateless. Of course, the SPEGNO protocol somewhat works around this by maintaining server-side state on a per-connection basis; nevertheless, this can always be controlled by the server by either 1) closing the connection or 2) Sending the initial 401 response to the client forcing a SPNEGO handshake.
The important thing to realize here is that many user-agents (i.e., browsers) are going to cache the user's credentials once they've been entered and simply use those to reply to any negotiate challenges (this is similar to how they handle Basic authentication). Any way of "forcing" the user to re-enter their credentials is going to have to be a little tricky, since the user-agent is essentially tricking the server into believing that the user has re-entered their password (technically, SPNEGO only provides verification that the user-agent knows the user's id and password -- the protocol itself has no way of verifying that anyone actually typed anything on the device keypad).
Off the top of my head, what might work (and I don't know how you can do something like this without writing your own SPNEGO handler server-side) is to trick the user-agent into invalidating is credential cache. To do this, your server would need to send the initial HTTP 401 to start the SPNEGO negotiation and then, when the client has responded with the first step of the handshake, resend an initial 401 error. The problem here is that how this is handled is going to be heavily dependent on the user-agent in question. Some will likely prompt the user to verify their credentials (since, from the client's perspective, the server is saying that the credentials are wrong), but other's may just show the error page, which is probably undesirable.