Re: Authenticate user and allow anonymous access

From: Nilssons (nilssons@yahoo.com)
Date: 03/19/03


From: nilssons@yahoo.com (Nilssons)
Date: 19 Mar 2003 09:50:39 -0800


Joseph E Shook wrote in message:

> No, you didn't miss anything. I figure there isn't any way to allow both
> anonymous and authenticated users in without using two virtual directories
> so the only users that would ever have to enter credentials would be the
> anonymous. But all anonymous users would use the same credentials so they
> are sill anonymous in that we don't know who they are. You are definetly
> correct in that my solution would require anonymous users to enter some kind
> of credentials.
>
> You know I was thinking that maybe a custom http handler or some code in
> global.asax could be written to inform failed authentication attempts of the
> anonymous password. You know like when the server sends the browser a 401
> error.
>
> Kind of like the response code bellow:
>
> Response.StatusCode = 401;
>
> Response.StatusDescription = "Unauthorized";
>
> Response.Write("<h2>Anonymous Username = Bob, and Password =
> password</h2>");
>
> Going down that path might be interesting. Because at least then an
> anonymous user would learn the credentials. I am not sure this would work
> but I have had a lot of success with changing the browsers user credentials
> this way.

Hi Joseph,

Thanks for the insight on possible ways to approach this. I had
actually found a solution, and I just wanted to post it here, it ended
up being somewhat similar to what you are describing above.

The solution you suggest won't work for the simple reason that once
you send a 401.1 to the calling browser, the negotiation process will
start between the browser and IIS, at this point ASP, ASP.NET or
whatever is completely cut out, until the negotiation process is done,
causing a login popup to show for unidentified users. So how to get
around this?

As it turns out, I was able to get a hold of an ISAPI filter, with
source code in C++ that is called 'User.dll'. It is undocumented (at
least the base that I have) with the exception of a brief
implementation explanation. It works in the following way:

- A user will call a page, on which you would like to identify the
user
- If the presence of the http headers 'HTTP_AUTH_USER' and
'HTTP_REMOTE_USER' are not present (I will explain these shortly) do
the following.
- Set the response status to "307 Object Moved"
- Add a new http header "Location" whish should look something like
this
"http://hostname/User.dll/ScriptBeingExecuted.aspx"
- End the response

This will cause the browser and IIS to start the negotiation process,
but while this process happens, it will be picked up by the User.dll
ISAPI filter (provided you installed it in IIS), completely
circumventing the Windows authentication and just passing on the
results of the negotiation.

Once the negotiation is done, the User.dll will pass on a page request
to the page that was specified (ScriptBeingExecuted.aspx in this
case), now with the added headers 'HTTP_AUTH_USER' and
'HTTP_REMOTE_USER'. HTTP_AUTH_USER will contain the Domain\Username if
the user could be authenticated against the same domain that IIS is
deployed in. HTTP_REMOTE_USER will contain the Domain\Username that
the user used to log in on their machine.

That's it.

As you can imagine, I'm happy about the fact that this piece of code
does what I need it to do, although I'm very unhappy about the fact
that I can not identify where it came from, nor am I happy about the
way it circumvents the Windows security standards. I could be made to
feel more happy about the circumvention, if I knew the source of this
thing, so my question to everyone would be: Has anyone seen this, or a
variation of this anywhere else?

Best,
Stefan Nilsson

PS. I would be happy to send the code for User.dll to anyone who is
interested, but please understand that I will not support it, since I
am not the author...