Authentication problem

[Dave Slinn]

I have come across a very weird situation. I made a slight modification to
our authentication process to allow a single deployed website to
authenticate a user with either forms authentication (if coming from an
unknown network, such as the internet) or windows authentication (if coming
from our own internal network). Everything is working fine, and the
authentication is working exaclty as expected. However, a weird side effect
is that once authenticated, the IsPostBack property will now only return
False, and event handler methods like Button.Click are not called.

This occurs even though the server variable REQUEST_METHOD is returning a
POST when a post back event, such as a button click, occur.

Sorry for the cross-post, but I'm not sure what category this problem falls
in. Has anybody ever experienced a situation where the IsPostBack = False
even though Request.ServerVariables("REQUEST_METHOD") = "POST"??

 

[Cowboy \(Gregory A. Beamer\)]

I am not familiar with this issue, but I can tell you a multitude of reasons
why this should be two sites (one internal and one external) with each
configured for its own authentication method. By channeling internal users
outside of the firewall or proxying internal sites out, you are taking a
chance that external users can hack through otherwise secure systems.
Despite how much quicker this type of development might be, you are better
to allow for both types of auth on the backend and flipping the config
method based on which site you are deploying than you are setting both types
in one site.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside of the box!
*************************************************

 

[Dave Slinn]

Thank you for your response, however, I feel I must tell you that I do not
know how your solution of deploying two instances of the same application -
one internal for windows authentication, one external with forms
authentication - is any more secure than a single instance accessible to
both parties. It's interesting that you are quick to criticize and dismiss
an architecture without knowing any of the details of it.

 

[Steven Cheng[MSFT]]

Hello Dave,

From your description, the page postback will not work for those pages in
the application that use forms/windows mixed authentication. I think this
is certainly an unexpected behavior and it is likely specific to the page's
request processing. Have you add any custom component like custom
httphandler or module in order to configure the mixed mode authentication.
Or would you provide some detailed info on how to do the mixed mode
authentication.

I've ever met some one experiencing such problem like page postback not
work, but most of them are caused by the client-side script is not
correctly registered or the server-side pages are being cached. For
general troubleshooting, I suggest you create a simplifed project with the
same setting and use some simple page to try reproducing the same problem.
If this can be simply reproducted, we can concentrate on the simplified one
which will be much helpful.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Cowboy \(Gregory A. Beamer\)]

I apologize if I got you angry in my response, as that was not the intent. I
am just dealing with my own experience with multi-purposed .NET security
applications and the disasters I have seen or averted in code. Your
architecture may cover all of the potential security isues, but allowing
external access in an app that also works with domain user security is an
increased risk over one that is completely sandboxed.

There are one of two reasons to use dual security models:

1. You have external users without system accounts
2. You have internal users that have to hit the system from outside (not
logged into the domain)

In the first instance, if you set up both security models, it is highly far
more likely you will allow permissions that give a user an escalated set of
permissions, without even realizing it, as you are mixing models. The same
is true for the second, but in the second, you are purposefully escalated
priveleges.

Now, in all fairness, you may have conquered this issue with your"sandbox".
I find, however, that it is generally easier to sandbox the app when you
consider it two models, if even both are in the system and one is configured
to work at a time (two models, one app, configured to fit one of models).

It is generally best to completely DMZ all external applications. If you can
live with the internal users fitting into the same DMZ, you are probably
fine, but what generally ends up happening is features get added that
internal users need that are potentially risky. Then, the users ask to hit
these from outside and since you already have the application exposed on one
server, both internal and external, you are asked to just open up this
feature. And, in the case of one application I know of, you spill out
personal data onto the web because some hacker figured out how to circumvent
your system.

Once again, you may have already covered the security concerns.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside of the box!
*************************************************

 

[Dave Slinn]

Hi Steven.

I have taken your suggestion and copied the code from our authentication
mechanism and reduced it to a simple ASP.NET project. I did make a couple
slight modifications. I removed the calls that do either the Active
Directory LDAP query for internal users or a SQL query for external users,
and simply hardcode the usernames and passwords for testing purposes.
However, I was able to recreate the situation where the Page.IsPostBack
property always returns False.

The good news is that I was able to find a resolution while doing this. It
had to do with the way I have IIS configured. I had originally configured
the application in IIS to be "Enable Anonymous Access = True" and
"Integrated Windows Authentication = False" for the application folder and
all pages except for one. This page, loginwa.aspx, is a page that logs
internal users in using windows authentication, and has "Enabled Anonymous
Access = False" and "Integrated Windows Authentication = True".

The fix for the problem was to allow both "Enable Anonymous Access = True"
and "Integrated Windows Authentication = True" for all pages (except
loginwa.aspx, which is still False and True, respectively, for those
settings). Once this is done, the PostBack problem disappeared. I would
like to provide the test application to see if you can recreate on your end.
I am using IIS 6 (Windows Server 2003 w/SP1). How can I provide this sample
code to you? Should I email it to your online.microsoft.com address?

Thanks for the help. I may not have found a fix if not going through this
exercise.

- Dave

 

[Steven Cheng[MSFT]]

Thanks for your reply Dave,

Seems the problem did become quite unexpected. As you said turn on windows
authentication(and keep allow anonymous access) for other pages can help
remove the problem, it seems the issue is quite specfic to the environment.
Based on my experience, such issue would be hard to troubleshoot from the
surface and usually require some thorough troubleshooting from product
support team. Anyway, it will be helpful if you can create a simplified
repro project so that I can help you test to see whether it is environment
specific.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Steven Cheng[MSFT]]

Hello Dave,

How are you doing on this issue? If necessary, you can email the repro
project through the email in my signagure(remove "online")

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.