I had never really trusted upon .NET’s web security until I saw two US banks’ websites built in .NET. Of course there were some additional security settings like Secured Socket Layer etc etc, but the core security was implemented in .NET. Albeit I’m not a professional hacker, but still if two of the major US banks can trust upon .NET’s security against some geek professional hackers, then why can’t I?

In this article I’ll explain how easy yet sturdy Microsoft has made security implementation in .NET web applications. By using these simple techniques, without much of the coding; now you can make your web applications graceful, robust and bold enough to slap hands of any malicious hacker. Let’s see how:

Authentication Vs. Authorization:

Before we go ahead and start creating our example website, I believe it’s worth mentioning two buzz words that you’ll see a lot while implementing web security. But what you will not see a lot is, people explaining the difference between the two.

Authentication – How Application Knows Who Is Who:

So, Authentication is how application knows who is trying to access some resources or requesting some information from the application.

Authorization – How Application Decides Who Is Good:

So, Authorization is how application decides who is good and who is bad – who to grant access and who not to. The sequence of the two steps, as you might have already guessed, is exactly the same as I’ve mentioned here. First authentication, application sees who is coming to request, usually done by login/password (mostly in case of internet websites) or by using windows user account information (mostly in case of intranet websites). After application knows who has requested then comes authorization, application decides whether to grant what has been requested or not.

Creation of Intranet Application with Security:

Now let’s create a web application and assume that it would run as an internal website and then apply network security on it. For this purpose we’ll use Domain Name\User Name to authorize users to access certain portions of our web application.

Here WIT-WS52 is my computer name and mukarram is the user name in that domain. So you see, our web application has already started authenticating; in other words, website knows who is trying to access it. Now let’s see how we can authorize users, i.e. allow some users to access certain parts and deny access to some other. In order to do that, let’s prepare ground for this.

Let’s write the following lines in the body tag of ManagerDefault.aspx:

In line 01, path=”.” means the root folder of the application, which means that authorization settings in this block will be for root folder of the application. In line 02 <allow users=”*” /> means allow all logged in users. In line 03, <deny users=”?” /> means deny access to all users who are not logged into the network. By this, we’ve just implemented our authorization rule # 1. Now let’s move to authorization rules related to Manager folder; add following lines in web.config right under the above block (again, line numbers are given for explanation and are not part of the actual code):

Authorization In line 01, I’ve given the path as Folder Name/Page Name, since there is only one page in this folder. Furthermore, I wanted to show how you can apply security settings on page level. Folder level security settings are coming up in short. In line 02 I’ve given the user as Domain Name\User Name, considering there is only manager for this application. In line 03, I’ve denied access to all other users of the application; either they are logged in or not respectively; thus implementing rule # 2, 3 and 4.

Remember: Authorization rules in web.config, apply from top to bottom, which means first rule gets more precedence than the second one. So in the above example, we first gave mukarram access to ManagerDefault.aspx (line 02), then we denied access to all logged in users on this page (line 03); while mukarram is also a logged in user, line 03 did not apply on him because we had line 02 already giving him the access. However, if we change the order of these lines, mukarram will be deprived from the access on this page.

To deny mukarram access to Admin folder and to allow Admin role, add following lines:

In line 01, I’ve given the folder name on which I want to apply these security settings. In line 02, I’ve given the window’s group name who is allowed to access any page in this folder. Line 03 and 04 deny all other users. Since I haven’t yet created WebTestAdmins group in windows accounts, after applying these settings, when I ran the application all pages opened as before except the AdminDefault.aspx showed as follows:

Of course this error page could be displayed in a lot better format if we had applied central exception handling techniques explained in my article Exception Handling in .NET. Now let’s move forward and create a Windows NT group and add mukarram into that group so that he can access Admin page as well.

Albeit explaining how to create a Windows NT group and adding a user into it is beyond the scope of this article; nonetheless, I’m showing it here for the sake of novice programmers who don’t know this and might get stuck at this stage. So let’s start:

Now we are all set to run our application. The reason for the above steps is, sometimes running the web application from IDE blocks its most features that are available when it’s running from IIS. Let’s run our application, when I selected Admin link this time, I got this dialog box and subsequently Admin page:

After entering the User name/password, I got the following screen:

After that, if you want to add/remove users from the group, you can surely do so and running the application will allow or deny the access to the users. If adding and removing user from the role doesn’t work immediately; try restarting the web server. Sometimes a user keeps on getting access to a page even after it is removed from the role because of the cookies stored in cache.

So folks that pretty much it is; security in .NET on intranet web application is simple yet robust.