This is because of appearances. BTW, before reading this, I have a more
complete example on my blog -
http://snurl.com/mdbhl
I have used your post (anonymously) in the entry, as this is a common
topic.
What is actually going on is the user makes a request and is assigned an
anonymous token. In other words, he is authenticated as anonymous.
If the page allows anonymous access, nothing happens. If he is not allow
access, he is prompted to log in.
Possibly he has more than one login (bad form, but it happens all the time
in windows proper and very often in SQL Server (SQL Authentication)).
But, it is more an artifact of the IIS/ASP.NET authentication model.
Underneath the hood, the user is tied to the ASP.NET account for windows
access. The exception is windows authentication in ASP.NET, where the user
with the anonymous token is forced to log into windows to gain access. Then
he has his own domain account to use web resources. This is more applicable
to Intranet applications.
When a user hits the site, he has the anonymous token, which he can use as
long as it has rights. He then is forced to log in with an account. He can
use this until he hits a resource to which he has no rights. He is then
asked to log in again. It may not seem optimal, but there are few ways to
solve the authentication/authorization model, due to the fact the user is
ALWAYS authenticated, even if he is just authenticated as "anonymous".
And this is precisely what happens.
It would in some respects, but since the user is ALWAYS authenticated, even
if only as "anonymous", there is no easy way to distinguish one
authentication from another. If we say "if user is using the anonymous
token and does not have rights, force login, but if user is not using the
anonymous token and does not have rights, error out". This creates a bit
more complexity underneath the hood. And, there are times when you would
want it to always work the current default way (admitedly less than the
scenario you suggest).
Perhaps one day Micrsoft will allow the default to be set so you can choose
"only log in if anon token" or "always ask for login". It is not the case
today.
That happens due to windows authorization issues and not ASP.NET
authorization issues. You can get this error by setting the rights on the
resource in windows, but it will deny all users, as all users,
authenticated in ASP.NET or not, use the ASP.NET token for windows access.
I have some suggestions on hiding links the user cannot see, creating views
for logged in users, etc. in the blog entry:
http://snurl.com/mdbhl