Intranet Web Application Security

Question

Using Active Directory / Windows Integrated authentication is a given. From a development standpoint, what is the best way to consume this?

Is it through configuration?

<location path="SecurePage.aspx">
    <system.web>
     <authorization>
      <allow roles="MyDomain\My Secure Users" />
      <deny users="*" />
     </authorization>
    </system.web>
</location>

Is it through code?

User.IsInRole(@"MyDomain\My Secure Users");

Is it a good idea to store this in a database? So granting new users/groups can be done via a custom application? (I ask this because this is the status quo.) What is wrong with this idea?

Answer 1

If its not going to change much, use the web.config.

If it is going to change a lot then use the code method but with a database to make it easily modifiable.

More a general answer to coding practices rather than related to security.

Answer 2

There is no reason you can't use both. Doing through the web.config is really simple and effective. Always operate at the role level though. You use the code version for scenarios where you have an use where the config isn't enough, and also when you want to display/hide specific parts of the UI (there are also controls version of this).

Update 1: You already have supports for the roles, so I assume the database is to actually map roles to features. Asp.net built-in support and the extensibility points it supports are at the role level. If you really need to be full dynamic, then you need to do the check at the code level (the .config operates on roles). It is a matter of the extra effort it takes, so it depends more on the size of the system. For most cases sticking with roles is enough.

Answer 3

I personally prefer a declarative approach (i.e. the location-based web.config approach). This makes it easier to make changes when necessary without requiring redeployment of code.

Under no circumstances do I recommend calling User.IsInRole() with a static string as you do in your example; use the web.config declarative approach if your auth doesn't change.

Going the route you suggest in your last paragraph is perfectly fine, but I would only recommend it for situations where your auth information is likely to change frequently, i.e. for CMS applications or similar ilk.

In short, I don't think there's a "best practice" on the subject; it really depends on the application.