views:

235

answers:

1

Is there any way to provide a logout function for a site which uses classic asp, and which uses Windows authentication (i.e. the restricted folders have their permissions set via the server OS, and usernames/passwords are stored in Active Directory)?

If it makes any difference, the server is running IIS 5.0. The logout needs to work for IE (6, 7, and 8) and Firefox at the very least.

Note that this is an old and fairly large site - many hundreds of individual asp pages - so any solution that would involve changing individual pages simply will not work. (For the same reason, as well as basic politeness, please don't suggest changing to asp.net.)

What I've found so far suggests that sending a 401 response code might cause some browsers to clear the authentication, but (1) I don't know how to do that, and (2) I'd really prefer something that actually works, rather than just has an off chance of working. I also know that fiddling with the Session object (.Abandon, for example) would be completely pointless because that's not where the authentication is done.

+1  A: 

Your use of the term "logout" is confusing. Usually its the sites reposibility to manage logins/outs and this is typically done using the session object but this not what you are talking about.

I perceive two possible things you may be talking about.

Connection Authentication

Firstly the fact that authentication of the type done by Windows integrated security is performed at the connection level. Once a connection has been authenticated that connection (which under HTTP/1.1 is by default maintained in an open state) can be used with no further need for the authentications handshakes.

It may be possible to convince the client or server to close the connection by including the Connection: close header in the response but this may not actually result in the connection being closed.

Additionally a client may have 2 or more authenticated connections open at a time. This case the above approach would only close one of them.

The conclusion here is that there is little you can do about authenticated connections at a per session level.

Credential caching

IE will cache the credentials a user enters for a Network logon to a specific site for the duration of the IE session. So even if you do managed to close the existing authenticated connections IE will simply re-use the cached credentials to complete any subsequent authentication handshake silently. It may be possible to configure the client not to do this but I doubt that is something you can use.

Conclusion

The answer to (at least the question I perceive you are asking) is: no you can't.

AnthonyWJones
Martha
Oh, and "hav[ing] 2 or more authenticated connections open at a time" is precisely what we would like to achieve, but can't with non-IE browsers. IE6 and 7, if you open a new browser window, it's in its own session, and you can log in as a different user. IE8, you have to use the New Session command on the File menu to achieve the same thing. In Firefox and Opera, however, it's simply impossible to achieve.
Martha
@Martha: you are confusing connection authentication with site logon and connections with browser process instances. You can start a new instance of IE6 and 7 by launching the `iexplore.exe`. To start a new instance of firefox use `firefox.exe -no-remote -p`.
AnthonyWJones
I can guarantee you that exactly none of my users is going to go around starting browser windows via the command line. And I'm not confusing anything: our site use Windows authentication for logging in. As in, users open our home page (which doesn't require logging in), click the "log in" link, enter their username and password in the popup window (provided by the server OS, i.e. it's not an html or asp page), and then they're allowed in to their section of the site. Call it what you will, this is a logging-in action, and therefore common sense says there ought to be a corresponding logout.
Martha
@Martha: Hmm.. I am trying to help you but if want to stick with terminology from a users perspective rather than that of a developers perspective we are going to continue to struggle to communicate. Regardless of what it seems to you, that network dialog box is authenticating a connection (the TCP/IP pipe between the client and server) so that server code can run using the users identity. Despite there appearing to be a "logon to the website" that just what isn't what is happening.
AnthonyWJones