Authenticate if available, anonymous if not?

Hey all, I'm running IIS 6.0.

I'd like to have a page that, if a user is logged in, will have access
to the username accessing the site. No problem, I can just set
Authenticated access / Integrated Windows authentication.

However, I'd also like for people who aren't logged in to have
anonymous access to the site, too. No problem, I can also check the
Enable anonymous access box and give it the local IUSR_ account.

However, if I have both of these boxes checked, every access to my
site is assumed to be anonymous, even if the user is an authenticated
user. As long as I have that Enable anonymous access box checked, I
can't get IIS to do any user validation.

Is there anyway for IIS to attempt to validate a user, and if
validation fails or isn't available, to show the page anyway with
anonymous access?

Rick
Tue Jan 08 13:45:33 CST 2008

Hi,

Is there a specific reason you need to do it like that? I usually approach
it the opposite way and give anonymous access to the main site, and then
only require a login to those areas of the site that I want secured. The
logged in user still has access to the anonymous areas of the site but
people aren't prompted just to get to the main public-facing site.

--
Rick Barber

http://www.orcsweb.com
Managed Complex Hosting
#1 in Service and Support

"TonyV" <kingskippus@gmail.com> wrote in message
news:d5edb9b4-c25a-4495-89d7-fa0a10046fe1@i7g2000prf.googlegroups.com...
> Hey all, I'm running IIS 6.0.
>
> I'd like to have a page that, if a user is logged in, will have access
> to the username accessing the site. No problem, I can just set
> Authenticated access / Integrated Windows authentication.
>
> However, I'd also like for people who aren't logged in to have
> anonymous access to the site, too. No problem, I can also check the
> Enable anonymous access box and give it the local IUSR_ account.
>
> However, if I have both of these boxes checked, every access to my
> site is assumed to be anonymous, even if the user is an authenticated
> user. As long as I have that Enable anonymous access box checked, I
> can't get IIS to do any user validation.
>
> Is there anyway for IIS to attempt to validate a user, and if
> validation fails or isn't available, to show the page anyway with
> anonymous access?

TonyV
Tue Jan 08 14:44:32 CST 2008

On Jan 8, 2:45 pm, "Rick Barber" <r...@orcsweb.com> wrote:
> Hi,
>
> Is there a specific reason you need to do it like that? I usually approach
> it the opposite way and give anonymous access to the main site, and then
> only require a login to those areas of the site that I want secured. The
> logged in user still has access to the anonymous areas of the site but
> people aren't prompted just to get to the main public-facing site.
>
> --
> Rick Barber

What I'm trying to do is to create a page that displays information to
the public-at-large. (Well, the public-at-large on our corporate
Intranet, anyway.) If a user is one of a predefined list of editors,
however, I'd like for editing controls to show up on the page.

I'm trying to make the page as smart as possible. If a person is an
editor, they shouldn't have to go to a separate URL to edit the
information, they should be able to right there in-place on the page
itself. If they're not, they should just see the information without
having editing controls that would only say that they're denied
access.

An added complication is that some people will be browsing the page
with their Blackberries, which doesn't automagically authenticate
users like IE does (the browser that will normally be used by the
editors). Editors won't be editing pages on their Blackberries,
though, so if they access the page via a Blackberry, it's perfectly
fine for them to see the same page that the public-at-large does.

So ideally, IIS would check to see if the user is authenticated using
IE's automagic authentication system, where you're not prompted with a
username or password. If that information isn't available, then and
only then would it bail out to anonymous access. Plus, I've gotta
admit, I'm a little curious as to why the anonymous access and
integrated Windows authentication boxes are checkboxes instead of
radio buttons if, as it appears to me, it will always be either one or
the other.

Rick
Tue Jan 08 15:33:14 CST 2008

I'm not aware of IIS being able to do what you are looking for. That
appears to be something that would be done in ASP.Net. I would recommend
asking that in an ASP.Net forum to see if anybody has any coding suggestions
to do what you are looking for.

--
Rick Barber

http://www.orcsweb.com
Managed Complex Hosting
#1 in Service and Support

"TonyV" <kingskippus@gmail.com> wrote in message
news:cecb2642-8b6c-4700-9af9-3742dfb370ae@d70g2000hsb.googlegroups.com...
> On Jan 8, 2:45 pm, "Rick Barber" <r...@orcsweb.com> wrote:
>> Hi,
>>
>> Is there a specific reason you need to do it like that? I usually
>> approach
>> it the opposite way and give anonymous access to the main site, and then
>> only require a login to those areas of the site that I want secured. The
>> logged in user still has access to the anonymous areas of the site but
>> people aren't prompted just to get to the main public-facing site.
>>
>> --
>> Rick Barber
>
> What I'm trying to do is to create a page that displays information to
> the public-at-large. (Well, the public-at-large on our corporate
> Intranet, anyway.) If a user is one of a predefined list of editors,
> however, I'd like for editing controls to show up on the page.
>
> I'm trying to make the page as smart as possible. If a person is an
> editor, they shouldn't have to go to a separate URL to edit the
> information, they should be able to right there in-place on the page
> itself. If they're not, they should just see the information without
> having editing controls that would only say that they're denied
> access.
>
> An added complication is that some people will be browsing the page
> with their Blackberries, which doesn't automagically authenticate
> users like IE does (the browser that will normally be used by the
> editors). Editors won't be editing pages on their Blackberries,
> though, so if they access the page via a Blackberry, it's perfectly
> fine for them to see the same page that the public-at-large does.
>
> So ideally, IIS would check to see if the user is authenticated using
> IE's automagic authentication system, where you're not prompted with a
> username or password. If that information isn't available, then and
> only then would it bail out to anonymous access. Plus, I've gotta
> admit, I'm a little curious as to why the anonymous access and
> integrated Windows authentication boxes are checkboxes instead of
> radio buttons if, as it appears to me, it will always be either one or
> the other.

Kristofer
Wed Jan 09 11:36:22 CST 2008

Hi Tony,

A web server cannot force the client to send the username and password. So
browsers always tries to use anonymous authentication first. When the server
replies that anonymous access is not available or not allowed, the client
may try to authenticate (either automatically or manually, depending on the
setting in the browser).

This means that you cannot accomplish what you want to do; You cannot first
check if the user is able to authenticate and then use anonymous access if
it cannot be authenticated.

So now when we know that we cannot force the client to authenticate, we also
realize that we cannot distinguish between "public" users and editors
without "asking them". That is, if both groups authenticate as anonymous
users we do not know who they are. And since browsers always try anonymous
access first (and will use it if the server does not "complain"), we will
never find out who they are without asking them.

By "asking them" i mean that we need to ask them for a username and
password, so we can figure out who they are. This means that we must send a
401 telling the client they need to authenticate. We must do this for all
users, no matter if they are "public" or editors.

If we do this, the browser will try to automatically log on (if set up to do
so), and if it can authenticate the user will never be bothered. But, if the
client is not authenticated (which will be the case for the "public" if they
have no username and password that works) they will be asked for a username
and password.

So the only solutions i can find are these:
- Require all users to authenticate, but only those in the "editors" group
can edit the page. Since this is an Intranet, it is a possible solution, but
may not be practical and may require some work.
- Require your editors to use a link so they can log in.

I say this because you need to distinguish between the editors and the
others, and you can only do that by knowing who are editors This means that
you must require them to log on, or separate them among all authenticated
users. And based on how webservers and browsers work, i can only find the
above solutions.

--
Regards,
Kristofer Gafvert
http://www.gafvert.info/iis/ - IIS Related Info


"TonyV" <kingskippus@gmail.com> skrev i meddelandet
news:cecb2642-8b6c-4700-9af9-3742dfb370ae@d70g2000hsb.googlegroups.com...
> On Jan 8, 2:45 pm, "Rick Barber" <r...@orcsweb.com> wrote:
>> Hi,
>>
>> Is there a specific reason you need to do it like that? I usually
>> approach
>> it the opposite way and give anonymous access to the main site, and then
>> only require a login to those areas of the site that I want secured. The
>> logged in user still has access to the anonymous areas of the site but
>> people aren't prompted just to get to the main public-facing site.
>>
>> --
>> Rick Barber
>
> What I'm trying to do is to create a page that displays information to
> the public-at-large. (Well, the public-at-large on our corporate
> Intranet, anyway.) If a user is one of a predefined list of editors,
> however, I'd like for editing controls to show up on the page.
>
> I'm trying to make the page as smart as possible. If a person is an
> editor, they shouldn't have to go to a separate URL to edit the
> information, they should be able to right there in-place on the page
> itself. If they're not, they should just see the information without
> having editing controls that would only say that they're denied
> access.
>
> An added complication is that some people will be browsing the page
> with their Blackberries, which doesn't automagically authenticate
> users like IE does (the browser that will normally be used by the
> editors). Editors won't be editing pages on their Blackberries,
> though, so if they access the page via a Blackberry, it's perfectly
> fine for them to see the same page that the public-at-large does.
>
> So ideally, IIS would check to see if the user is authenticated using
> IE's automagic authentication system, where you're not prompted with a
> username or password. If that information isn't available, then and
> only then would it bail out to anonymous access. Plus, I've gotta
> admit, I'm a little curious as to why the anonymous access and
> integrated Windows authentication boxes are checkboxes instead of
> radio buttons if, as it appears to me, it will always be either one or
> the other.

David
Thu Jan 10 06:47:03 CST 2008

On Jan 8, 12:44=A0pm, TonyV <kingskip...@gmail.com> wrote:
> On Jan 8, 2:45 pm, "Rick Barber" <r...@orcsweb.com> wrote:
>
> > Hi,
>
> > Is there a specific reason you need to do it like that? =A0I usually app=
roach
> > it the opposite way and give anonymous access to the main site, and then=

> > only require a login to those areas of the site that I want secured. =A0=
The
> > logged in user still has access to the anonymous areas of the site but
> > people aren't prompted just to get to the main public-facing site.
>
> > --
> > Rick Barber
>
> What I'm trying to do is to create a page that displays information to
> the public-at-large. =A0(Well, the public-at-large on our corporate
> Intranet, anyway.) =A0If a user is one of a predefined list of editors,
> however, I'd like for editing controls to show up on the page.
>
> I'm trying to make the page as smart as possible. =A0If a person is an
> editor, they shouldn't have to go to a separate URL to edit the
> information, they should be able to right there in-place on the page
> itself. =A0If they're not, they should just see the information without
> having editing controls that would only say that they're denied
> access.
>
> An added complication is that some people will be browsing the page
> with their Blackberries, which doesn't automagically authenticate
> users like IE does (the browser that will normally be used by the
> editors). =A0Editors won't be editing pages on their Blackberries,
> though, so if they access the page via a Blackberry, it's perfectly
> fine for them to see the same page that the public-at-large does.
>
> So ideally, IIS would check to see if the user is authenticated using
> IE's automagic authentication system, where you're not prompted with a
> username or password. =A0If that information isn't available, then and
> only then would it bail out to anonymous access. =A0Plus, I've gotta
> admit, I'm a little curious as to why the anonymous access and
> integrated Windows authentication boxes are checkboxes instead of
> radio buttons if, as it appears to me, it will always be either one or
> the other.




The reason that authentication protocols are checkboxes instead of
radio buttons is this:
1. By specification, Clients can choose to authenticate using any of
an arbitrary number of protocols. Almost all Clients choose anonymous
authentication by default.
2. By specification, Servers can choose to require authentication
through any number of authentication protocols. You control the
requirement through the check boxes
3. Thus, while a particular client-server interaction will select a
single agreed-upon authentication protocol (you mistake this to mean a
radio-button choice), the selected protocol can certainly change for
server interactions from client to client (this is why it's a check-
box choice for the server)

In other words, you configure via checkboxes to tell the server
"please require authentication of EITHER Anonymous OR Integrated from
the Clients" (check-box). When clients make the first request to the
server, they have to choose some authentication protocol, and most
choose Anonymous (no authentication) by default. Thus, if anonymou is
checked, you are guaranteed that clients will use anonymous even if
other authentication protocols are configured -- that's just how the
web works.

So you see, reality works very differently from what you imagine.
Servers like IIS do not check on the client's authentication status
and act accordingly. HTTP is a client-pull model, not server-push
model. Servers can only make requirements of authentication AFTER
being contacted by a client, and client can choose to fulfill them or
not, and the fulfillment can be via auto-login.

I think Kristofer's explanation is spot on.

Over the years, lots of people have asked for this sort of "fallback
authentication protocol" where users authenticate to IIS by default
and on failure, fallback to anonymous access. The user usually want to
have a single website with pages that give multiple user experiences
-- a basic one for the anonymous, and an enhanced one for the
authenticated user based on some authorization profile. This is
basically what you are trying to do.

However, there is no public authentication protocol that works like
this, and for good reason -- the protocol is flawed. For example, how
can such a protocol distinguish between "failed login so should give
degraded experience" vs "failed login because of mistaken auto-login
so should try again for enhanced experience".

I know you are trying to make the page "smart", but what you are
really doing is muddling the boundary between AuthN (authentication)
and AuthZ (authorization). You are not alone, but just because you
have company does not make your desire any more reasonable.

The solutions are as Kristofer says -- either:
1. Authentication everyone, then Authorize users to be able to edit
2. Make users click a link to initiate authentication and
authorization to edit


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//