ASP.NET's Built-In Web Security
page 1 of 1
Published: 20 Dec 2004
Unedited - Community Contributed
ASP.NET has some new features that allow a developer to easily secure certain areas of a web site. Securing files and folders has always been an option for web applications, but in the past it was necessary to use either a third-party tool like Authentix or to use NTFS and Windows user accounts.
by Web Team at ORCS Web
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 9218/ 15

ASP.Net has some new features that allow a developer to easily secure certain areas of a web site. Securing files and folders has always been an option for web applications, but in the past it was necessary to use either a third-party tool like Authentix or to use NTFS and Windows user accounts.

Security with ASP.Net is configured from within the web.config file. This is a standard ASCII file, with an XML format, that is located in the root of your web application. Here is a sample web.config file:

    <authentication mode="Forms"> 
      <forms name="TestAuthCookie" loginUrl="login.aspx" timeout="30">
        <credentials passwordFormat="Clear"> 
          <user name="user1" password="pass1"/> 
          <user name="user2" password="pass2"/> 
  <location path="admin"> 
        <deny users="?" /> 

The very first line is standard for a web.config file and has no bearing on the security.

The next section specifies that you are configuring the security for this web application. First we set the authentication mode to use a cookie in this specific example. You can specify a unique name for your cookie. In ASP.Net Beta 1 you could also set a decryption key but this is now controlled at the server-level in the machine.config file. This section also specifies the page or URL that will contain the authentication code (login.aspx in this case) and how long the authentication cookie should be persisted.

The next two lines specify valid usernames and passwords for this web application. As far as I know there is no limit to the number of user accounts you can place in the web.config, but if there were a large number - or if they change frequently - it might be better to place this information in an external file like a database or an XML file instead (I'll show this in a future article).

Now that we have specified some valid logon accounts, we need to actually specify that we want to password protect. For this example I have decided to password protect a folder under the web root named "admin". The "location path" attribute specifies this folder as the one we will manage. Once we have specified the path to manage, we can work with specific settings - we are interested in the "authorization" setting for this folder. We set the authorization to deny all non-authenticated users (deny users="?").

For the config.web, that is all that is needed. If someone tries to access the /admin/ folder and the user has not already authenticated, they will be redirected to the /login.aspx page.

Now of course this is only half the battle. We now need to create the login.aspx page to actually allow the user to authenticate to our application.

Here is the complete source of the sample login.aspx page:

<%@ Page Language="VB" Trace="false"%> 
<%@ Import Namespace="System.Web.Security" %> 

<script language="VB" runat=server> 
  'This sub validates the user against a list in the web.config file 
  Sub Login(Src as Object, E as EventArgs) 
    if (FormsAuthentication.Authenticate(txtUser.Value, txtPwd.Value)) then 
      FormsAuthentication.RedirectFromLoginPage(txtUser.Value, false) 
      lblStatus.InnerHtml = "Invalid login" 
    end if 
  end sub 

<form method=post runat=server> 
  Username: <INPUT type=text name=txtUser id=txtUser runat=server/><BR> 
  Password: <INPUT type=password name=txtPwd id=txtPwd runat=server/><BR> 
  <INPUT type=submit OnServerClick="Login" runat=server/> 

<SPAN id="lblStatus" runat=server/> 

Let's look at the bottom half of the page first. This is fairly straight-forward HTML format. These aren't actually "true" HTML tags, but rather ASP.Net HTML controls that will render HTML page to the client browser (you can tell the difference because the runat="server" tag at on the control). This is a form that accepts a username and password. When the submit button is clicked, this page executes the code located in the subroutine named "Login".

Inside of the Login method we use the FormsAuthentication object. The first line of the sub actually passes the entered username and password over to the object, which in turn compares this information to the values in the web.config file. If the values match, then the next line writes a cookie to the browser and redirects the user back to the original URL which was requested. The second value listed (false) tells the browser not to persist the cookie. So if this user authenticates, closes their browser, opens it again, and tries the secure URL - they will need to authenticate again.

If the username and password entered did not match, an error message is displayed to the screen and the visitor is allowed to enter a new username and password to try again.

This is a simple example and I don't cover any of the advanced configurations or options, but with this sample code, you should have a basis to work with if you want to implement security in ASP.Net

By Brad Kingsley, founder and president of ORCS Web, Inc. - a company that provides managed hosting services for clients who develop and deploy their applications on Microsoft Windows platforms.

User Comments

Title: Web Service Issue   
Name: Mark
Date: 2005-07-04 2:38:25 PM

Excellent article that has really helped get me kickstarted on a solution I've been developing.

However, when login.aspx redirects back to the original page I receive an error due to a web service call that the original page makes. Shouldn't this code allow all code to execute once authenticated through login.aspx?

Thanks, Mark
Title: Nothing   
Name: Arif sarwar
Date: 2005-05-13 3:20:40 AM
not good
Title: default.aspx?   
Name: Brad
Date: 2005-05-10 8:57:59 AM
I assume you are requesting a page other than default.aspx but getting sent there instead after the authentication? I am not sure off-hand why this would happen, but if you have any more details on the problem or things you may have noticed, perhaps myself or someone else here can assist.


Title: default.aspx woes!   
Name: andrew
Date: 2005-05-09 11:43:23 PM
any ideas why it always sends me to default.aspx when sucessfully authenticated??
Title: Auth against a database   
Name: Brad Kingsley
Date: 2005-05-05 2:24:31 PM
Check out the other article here:
Title: SA   
Name: Blake
Date: 2005-05-05 2:03:23 PM
Could you give me the url for the article that discusses storing the user info in a database?
Title: How to logout   
Name: Brad
Date: 2005-04-28 5:28:51 PM
You can put a button on a page that calls FormsAuthentication.SignOut() and that should logout the user.

Title: How to log out?   
Name: ahmun
Date: 2005-04-28 4:02:21 PM
Wow... thanks for the simple-yet-thorough description!

Any quick follow-ups on how to allow user to log out (before the expire time)...
Title: to "pz"   
Name: Brad Kingsley
Date: 2005-01-05 4:35:43 AM
In this sample, if *any* page on the site (not just the default.aspx) then the user is redirected to the logon.aspx page to authenticate.

As for a customer "denied" page... I haven't done it, but i don't see why you couldn't just do a redirect in the Else section rather than displaying an HTML message. Then the user would be sent to an HTML (HTML isn't protected by default - this is just .Net pages) as desired.

Title: more?   
Name: pz
Date: 2005-01-04 9:16:01 PM
good script. can i configure to open any page - this goes to default.aspx? and can i configure it to go to an html page for the wrong password (rather than just an html text message? thanks in advance
Title: To the "me" person   
Name: Brad Kingsley
Date: 2004-12-29 8:11:52 AM
For someone to view the web.config, they'd need access to the code - in which case they could probably also access the files are you are trying to protect :)

Look at our article on storing the user information in a database for more options. Or look into the process of encrypting the information in the web.config file.

Title: me   
Name: me
Date: 2004-12-28 5:36:02 PM
This is not the proper method of securing.Any one can open the web.config file to see the user name and password
Title: hjjvv   
Name: j,b, jl
Date: 2004-12-20 11:03:02 AM
good delivery

Product Spotlight
Product Spotlight 

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2024  |  Page Processed at 2024-06-18 4:07:56 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search