Instead of using a link to make them login, you could automatically log them in if they are on the intranet and are using integrated security.
I've implemented this by checking the port, but you could check the hostname.
(I also ensure that the page is never cached for intranet users, by IIS or the browser, to ensure the authentication happens. In my situation, some intranet users are not MOSS users, so I set a cookie for an hour to avoid authentication attempts for every request, as that slows the site down.)
This is the code, which I put in the Page_Load() for the master page.
public void Page_Load(object sender, EventArgs e)
{
if ((Request.Url.Port != 80) && (HttpContext.Current.User.Identity.IsAuthenticated == false) && Request.Cookies["auto_auth_attempted"] == null)
{
try
{
using (SPSite spServer = SPControl.GetContextSite(Context))
{
using (SPWeb spWeb = SPControl.GetContextWeb(Context))
{
SPUtility.EnsureAuthentication(spWeb);
}
}
}
catch (Exception ex)
{
HttpCookie cookie = new HttpCookie("auto_auth_attempted", "true");
cookie.Expires = DateTime.Now.AddHours(1);
Response.Cookies.Add(cookie);
Response.Redirect(Request.Url.ToString());
}
}
if (Request.Url.Port != 80)
{
// never cache internal pages in IIS
Response.Expires = 0;
Response.Cache.SetCacheability(HttpCacheability.NoCache); // don't store on the proxy
Response.Cache.SetAllowResponseInBrowserHistory(false); // don't store page responses on client
Response.Cache.SetNoServerCaching(); // don't store in IIS
Response.Cache.SetNoStore(); // don't store on client PC
}
// other page load stuff
}
Kristofer Gafvert wrote:
Hi Tony,A web server cannot force the client to send the username and password.
09-Jan-08
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" skrev i meddelandet
Previous Posts In This Thread:
On Tuesday, January 08, 2008 2:45 PM
Rick Barber wrote:
Hi,Is there a specific reason you need to do it like that?
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
"TonyV" wrote in message
On Tuesday, January 08, 2008 4:33 PM
Rick Barber wrote:
I'm not aware of IIS being able to do what you are looking for.
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
"TonyV" wrote in message
On Wednesday, January 09, 2008 1:34 AM
TonyV wrote:
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?
On Wednesday, January 09, 2008 1:34 AM
TonyV wrote:
Re: Authenticate if available, anonymous if not?
On Jan 8, 2:45 pm, "Rick Barber" wrote:
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.
On Wednesday, January 09, 2008 12:36 PM
Kristofer Gafvert wrote:
Hi Tony,A web server cannot force the client to send the username and password.
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" skrev i meddelandet
On Friday, January 11, 2008 9:59 PM
David Wang wrote:
Re: Authenticate if available, anonymous if not?
On Jan 8, 12:44=A0pm, TonyV wrote:
roach
The
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
//
Submitted via EggHeadCafe - Software Developer Portal of Choice
Featured Product / Service Review: TekPub
http://www.eggheadcafe.com/tutorials/aspnet/ae6e21fa-3443-4134-9d2e-39...482c80e >> Stay informed about: Authenticate if available, anonymous if not? 
FAQ
Search
Profile
Private Messages
Log in
