Application Security with ASP.NET

Security on the Web can be difficult. The difficulty, however, isn't in conceiving a security model for your application but in implementing and managing it. You typically have to rely on the type of security that the OS provides. Active Directory (AD), for example, offers (among other things) a highly scalable user data store that's integrated into Windows to let you apply security to folders on your Web sites. But utilizing your OS for security presumes that your application will fit into the security model these types of services provide. What you need is a simpler way of applying security that's tightly integrated with your application. Before Microsoft .NET, you were pretty much stuck with what the OS provided unless you wanted to build or buy a whole new security layer. But with ASP.NET, you have all the flexibility you need to deliver secure solutions quickly.

Before you rip out all your custom security on your existing Active Server Pages (ASP) pages and move to ASP.NET, you need to understand the type of security that ASP.NET offers. The beauty of ASP.NET's approach to security is that it's quite simple to implement. Let's take a project that I'm currently working on as an example. Like everyone else, my team is frantically learning about all the cool new features that come with .NET. So we started this .NET project without understanding the power of the security built into ASP.NET. Our application is highly role-driven, meaning that one person can have more than one role that controls the types of activities he or she can perform in the application. At the tail end of a crushing project, at 3:00 in the morning (really), when we knew we had to implement security, we were tempted to follow old ways of embedding code at the top of each page to check whether a person is logged on and whether he or she has the proper authorization to view each page. Fortunately, the coffee was brewing, and we soon got smart about ASP.NET security.

Within hours, our application was fully locked down based on the roles within the application, and we didn't have to modify any of our Web pages. In ASP.NET, you can control and apply security within web.config files in each directory. The web.config files control many facets of your site, including authorization. Place a web.config file within each directory that you want to secure to lock it down. In the web.config file, we identified which roles could view the applications running within each directory. Here is a snippet of a web.config file we're using on our site:

     <authorization>
          <deny users="?" roles="TO,ED,TC,SP,CS,SM,IN,AT"/>
        </authorization>

This XML snippet within the web.config file shows which roles can't view the contents of the folder in which this file resides. These roles are part of the Web application.

So now ASP.NET is available, you're free to secure your Web sites in the way that works best for your application and not just for the OS. Better, the security moves with your application—wherever you install the application, you can be sure that it's locked down.