web application security

[Stephen]

I have my intranet setup on our web server. It contains multiple
applications, but none are set up in the default application pools. In
other words, I create a webform and plop it into a directory on the web
server. My question revolves around security models for the
applications. I have been rethinking my current security strategy,
which is basically as follows:

dim strUser as string=ucase(User.Identity.Name)
dim boolAccess as boolean = false
if strUser = "DOMAIN\USERNAME1" or strUser = " DOMAIN \ USERNAME3" then
boolAccess=true
end if

if boolAccess = false then
response.write(strUser & "-You are not authorized to access this
area.")
response.end
end if

This validates the user on the page load event. The only problem with
this is now I have about 50+ web forms and managing this is getting to
be an issue, not to mention if someone new needs access to the webform,
someone (me) has to go into the code and add them. This isn't
(obviously) an ideal situation, as I would like to make it so the sys
admin can add/remove users/roles from a webform. Here is what I have
contrived in my puny head about my options:

1.Create (application) roles in AD, then use this code to restrict
access in each of the webforms that need it:

string strUser =User.Identity.Name.ToUpper();
bool boolAccess = false;
if (User.IsInRole("DOMAIN\\RoleName")) {
<Allow access>
}
else {
<Deny access>
}
return;

2. Set the permissions (AD role based) on the files in IIS (I think
this is called file authorization)

There are a couple others such as URL Author & .Net Roles of which I no
little about. Option 1 above has the problem of still requiring
manipulating code if roles need adding or removing, so I don't much
like this option except for very specific functions. Option 2 seems
like the best for controlling access to a entire webform from an
non-developer admin point. The other two options I need some educating
on.

Our intranet uses integrated windows authentication with anonymous
access turned off. I don't forsee ever needing to allow
non-authenticated users access to this site.

I have downloaded information on asp.net security, but there is a
mountain of information to wade through. I was hoping someone could
give me some pointers on implementing a simple security model and maybe
share some experiences they've had. Some of this is driven by
compliance with Sarbanes-Oxley.

Any help is appreciated.

 

[ashish]

you can use forms authentication with active directory, then you wont
have to worry about anything

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod16.asp


hth
-ashish

 

[Guest]

Stephen,

Because your existing intranet uses Windows Integrated security you are
already on the right track. ALWAYS resist the temptation to apply any kind of
security to a specific user, create a role and validate membership within the
role to secure the item. Typically I find myself doing a lot of role checking
in the presentation tier, for instance I have an application that everyone in
the organization uses but some users only get to read, others get to update
others get to audit and so on depending on role membership. When you start
authenticating users to the database using Integrated Security you'll run
into the limitations of NTLM and you'll have to use kerberos, ultimately this
is what your dba's will want because it shifts the user management piece to
the network administrators. I will post more later I have an urgent task that
just came up...

 

[Stephen]

I happen to be the dba too. One on many jobs I have here .

I agree with you. The only problem I can see is the number of
potential roles getting out of hand. After doing some reading I am
looking into a solution using web.config files and roles. I will check
back and see what else you have to say.

 

[Guest]

Hi Stephen,

Just one thing I'd like to add, IIS is already authenticating clients
against AD, they have access by virtue of being logged into the domain and
the ACL permissions on the web server, there's no sense in having them
authenticate again using a forms authentication scenerio.

 

[Stephen]

I was under the impression that forms auth was meant primarily for
anomous access.

I didn't realize the breadth of security issues and methodologies
surrounding web applications. I downloaded a 600+ page document that
covered asp.net security alone.

 

[Brock Allen]

I was under the impression that forms auth was meant primarily for

anomous access.

If you wanted anonymous access then you'd not use any authentication at all.
Forms is for authenticating users when you have your own username/password
store for such thing. Typically it's used when your users are not windows/domain
users.

 

[Stephen]

That makes sense, anonymous is anonymous. I thought it had something
to do with AD non-authenticated users.

Thanks.