Re: Authentication problem

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" <CougarDave@xxxxxxxxxxxxxxx> wrote in message
news:OYQ3X052GHA.328@xxxxxxxxxxxxxxxxxxxxxxx
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.


"Cowboy (Gregory A. Beamer)" <NoSpamMgbworld@xxxxxxxxxxxxxxxxxx> wrote in
message news:%23w7Yw132GHA.4312@xxxxxxxxxxxxxxxxxxxxxxx
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" <CougarDave@xxxxxxxxxxxxxxx> wrote in message
news:OZybZI32GHA.2152@xxxxxxxxxxxxxxxxxxxxxxx
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"??









.