Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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
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.