ASP Logout

[Jay Ohman]

I am using 'classic' ASP, trying to create logout functionality.

The main site is publicly available (Enable anonymous access = true), and
then a private sub-directory (and it's pages) are using Integrated Windows
authentication (Enable anonymous access = false), usernames are stored in AD.
Login works fine, in fact I have at the top of all the pages:
Logged in as <%= Request("AUTH_USER") %> to verify the currently
authenticated user.

The problem is, in my logout.asp page, Session.Abandon does not log out the
user. The following line: Response.Redirect("./default.asp") properly
redirects, but does not prompt for user credentials, and the logged in
username appears at the top of the page, indicating that in fact the user is
still logged in.

How can I make a logout really happen, so that re-authentication is required
to browse the private site?

TIA!! This one has kicked my but!

[Daniel Crichton]

Post by Jay Ohman
I am using 'classic' ASP, trying to create logout functionality.
The main site is publicly available (Enable anonymous access = true),
and then a private sub-directory (and it's pages) are using Integrated
Windows authentication (Enable anonymous access = false), usernames
are stored in AD.
Logged in as <%= Request("AUTH_USER") %> to verify the currently
authenticated user.
The problem is, in my logout.asp page, Session.Abandon does not log out
the user. The following line: Response.Redirect("./default.asp")
properly redirects, but does not prompt for user credentials, and the
logged in username appears at the top of the page, indicating that in
fact the user is still logged in.
How can I make a logout really happen, so that re-authentication is
required to browse the private site?
TIA!! This one has kicked my but!

You can't logout an authenticated user. The credentials are stored by the
browser and sent with each request, and have nothing to do with ASP
Sessions.

[Daniel Crichton]

Post by Jay Ohman
I am using 'classic' ASP, trying to create logout functionality.
The main site is publicly available (Enable anonymous access = true),
and then a private sub-directory (and it's pages) are using Integrated
Windows authentication (Enable anonymous access = false), usernames
are stored in AD.
Logged in as <%= Request("AUTH_USER") %> to verify the currently
authenticated user.
The problem is, in my logout.asp page, Session.Abandon does not log out
the user. The following line: Response.Redirect("./default.asp")
properly redirects, but does not prompt for user credentials, and the
logged in username appears at the top of the page, indicating that in
fact the user is still logged in.
How can I make a logout really happen, so that re-authentication is
required to browse the private site?
TIA!! This one has kicked my but!

Sorry, ignore my initial reply. There are apparently a couple of ways of
managing this:

http://www.adopenstatic.com/cs/blogs/ken/archive/2005/04/12/14.aspx

[Jay Ohman]

Dan--

Thanks much for the response. The link to Ken Schaefer's blog was
insightful, though not extremely helpful.

For search engine follow-up, here is the best solution I devised:
use the javascript "document.execCommand("ClearAuthenticationCache")" AND
use the ASP-VB command "Response.Status = 401".

The javascript command has an annoying side-effect that IE will clear
credentials for all sites currently open and authenticated! (example: I had
to re-login to this forum due to the javascript command executed in another
IE window). Also, this does not work with Netscape browsers (other browsers
not tested yet).

For the record, it is very frustrating that Session.Abandon does not really
abandon the user session in IIS 6, this was easily proved with:
Response.Write Session.SessionID. Only the above 2 commands together forced
a new session in IE6. I consider the lack of an easy ASP method to log out
an authenticated user a major security flaw in IIS 6, for several well-known
reasons.

It took quite a bit of playing to get the right combination, but as stated
in my original post, this site has a sub-directory with "Enable anonymous
access = false". By creating a "are you sure you want to logout page", then
linking the "Yes" to the parent (public) directory (HREF="../logout.asp"), I
was able to create a fairly clean user experience.

Again, for search engine reference, here is my logout.asp (from the root of
the public site):
---------------------------------------------
<HTML>
<HEAD>
<META HTTP-EQUIV="Refresh" CONTENT="1; URL=./">
</HEAD>
<script type="text/javascript">
// Clear current credentials, Requires IE6 SP1 or later
document.execCommand("ClearAuthenticationCache");
</script>
<% Response.Status = 401 %>
<BODY>
</BODY>
</HTML>
---------------------------------------------

[Daniel Crichton]

Post by Jay Ohman
For the record, it is very frustrating that Session.Abandon does not
Response.Write Session.SessionID. Only the above 2 commands together
forced a new session in IE6. I consider the lack of an easy ASP
method to log out an authenticated user a major security flaw in IIS
6, for several well-known reasons.

ASP Sessions have nothing to do with authentication. All Session.Abandon
does is to empty the Session object at the end of the page scope. A Session
is simply an object that contains semi-persistent data (it automatically is
discarded after the session timeout, so it's not fully persistent) on the
server side linked to a cookie on the client side. You need to get it
straight in your head that it has no relation to the Basic/Integrated
Authentication mechanisms which are driven by the client, there is no
relation between a Session object and the standard authentication schemes.
Does any other application platform for IIS (such as ASP.Net, PHP,
ColdFusion, and anything else that can run on IIS) have an "easy method" to
log out authenticated users?

[Jay Ohman]

Dan--

Thanks again for the insight. Despite my exhaustive attempts to research,
learn and fully understand ASP, it took your informative explanation to
finally get this concept "straight in my head". Hopefully, someone else who
has thrashed for hours on this topic, will come across this thread and gain
the education I needed.

As for your question posed, I can not respond. I feel I still have a
considerable way to go on fully understanding ASP before taking on the other
platforms (ASP.NET, etc.).

If I am understanding you correctly, then my presumption that the
authorization key for the "cryptographic exchange with the user's Web
browser" (from the IIS help screen) was based on Session data is false. It
seems that "Integrated Windows authentication" (as opposed to basic
authentication) is not as integrated as I presumed it to be. This runs
contrary to my primary experience with client/server permissions and
authentication where an authorization check seems to occur with every request
for server resources, and a client logout forces a re-authentication. On a
Windows server, denying and allowing access is integrated, whereas with IIS,
authorization seems to be a one-way door: once the door is open there is no
way to close it at the server, and there is no way to close the door (log
out) from the client browser (other than closing the browser).

Thanks again for the information... my education continues.

---Jay R O

[Daniel Crichton]

Post by Jay Ohman
If I am understanding you correctly, then my presumption that the
authorization key for the "cryptographic exchange with the user's Web
browser" (from the IIS help screen) was based on Session data is false.

Correct, it has nothing to do with the cookie used for the Session object.

Post by Jay Ohman
It seems that "Integrated Windows authentication" (as opposed to basic
authentication) is not as integrated as I presumed it to be.

It's integrated in that IIS itself and the browser handle the authentication
process, and that it uses a Windows crypto process to do so. It is wholly
seperate from how the content in the pages is generated.

Post by Jay Ohman
This runs contrary to my primary experience with client/server
permissions and authentication where an authorization check seems to occur
with every request for server resources, and a client logout forces a
re-authentication. On a
Windows server, denying and allowing access is integrated, whereas with
IIS, authorization seems to be a one-way door: once the door is open
there is no way to close it at the server, and there is no way to
close the door (log out) from the client browser (other than closing
the browser).

From what I remember this is how the authentication schemes work:

Basic: every request contains a HTTP header with the login and password
encoded using Base64, and the server compares this to what is expected.

Integrated: at the initial request to login a token is generated, and this
is passed by the browser on each subsequent request. The login and password
are therefore only passed on the initial login request making it less prone
to discovering the login and password.

It's up to the browser how it handles a "logout" in this case. IIS can send
the 401 response header to tell the browser that is it no longer
authenticated, but it's up the browser what it does with that information.
If you feel that the current implementation is "bad" then it's an issue for
the browser developers to deal with, it has nothing to do with ASP (which
can only send data to the browser and process data sent by it, it cannot
change the way the browser actually works).

[Daniel Crichton]

Post by Daniel Crichton

Post by Jay Ohman
If I am understanding you correctly, then my presumption that the
authorization key for the "cryptographic exchange with the user's Web
browser" (from the IIS help screen) was based on Session data is false.

Correct, it has nothing to do with the cookie used for the Session object.

Just to reiterate this, there are web sites that don't use ASP at all - if
the IWA key was linked to the ASP Session, you would never be able to use
IWA on a site that used any other way of producing HTML including just plain
text files. The IWA exchange has to be "lower" in the IIS system such that
it's dealt with outside of whatever you use to produce the content - ASP
simply has access to some of the variables that are exposed by the
Request.ServerVariables collection in order to allow the application code
being used to be able to use that information if required, just like a CGI
applicaton can obtain the same information via the HTTP headers parsed from
the data sent to it by IIS.

[unknown]

Hi all,
I am facing the same LogOut problem at my portal.

I tried session.Abandon and also added under JavaScript code:
document.execCommand("ClearAuthenticationCache");

I tried FireFox as the client, and the user still stays Logged in !?

Any solution!?

rajeev