Introduction:
When you begin a program for a customer using ASP.Net, you should consider about security. Security is one of the most important components of any application. Security is even more important when you are making a web application which is exposed to million of users. Asp.net provides classes and methods that ensure that the application is secure from outside attacks. In this article we will investigate the different types of authentication provided by ASP.Net. In web.config file you can set authentication mode value 'windows' or 'forms'. What's about difference and how to you use them? (Authentication have some other values to, this article does not consider them.)
Configure the Security Settings in the Web.config File:
This section demonstrates how to add and modify the <authentication> and <authorization> configuration sections to configure the ASP.NET application to use window-based or forms-based authentication.
How to use mode "Windows"?
Change the authentication mode to Windows.
Windows Authentication mode provides the developer to authenticate a user based on Windows user accounts. This is the default authentication mode provided by ASP.Net. You can easily get the Identity of the user by using User.Identity.Name. This will return the computer name along with the user name. Windows authentication also provides IsInRole method to find the role of the user and than you can give permissions to the user depending on the role.
<authentication mode="Windows">
<forms name=" AuthenticationDemo" loginUrl="logon.aspx" protection="All" path="/" timeout="30" />
</authentication>
Deny access to the anonymous user in the <authorization> section as follows:
<authorization>
<deny users ="?" />
<allow users = "*" />
</authorization>
Other you can make a special client to access you project with windows authentication. Code like this (this case you can get value using 'User.Identity.Name', then you can use it to do other work you like.):
<authorization>
<deny users ="?" />
</authorization>
How to use mode "Forms"?
Change the authentication mode to Forms.
Insert the <Forms> tag, and fill the appropriate attributes. (For more information about these attributes, refer to the MSDN documentation)
First you should specify a page and make sure all clients can found it. Code like this
<authentication mode="Forms">
<forms name=" AuthenticationDemo" loginUrl="logon.aspx" protection="All" path="/" timeout="30" />
</authentication>
Deny access to the anonymous user in the <authorization> section as follows:
<authorization>
<deny users ="?" />
</authorization>
Second in that page you to validate the user's Id and Password. Code like this:
You can use one of two methods to generate the forms authentication cookie and redirect the user to an appropriate page in the cmdLogin_ServerClick event. Sample code is provided for both scenarios. Use either of them according to your requirement.
(1). Call the RedirectFromLoginPage method to automatically generate the forms authentication cookie and redirect the user to an appropriate page in the cmdLogin_ServerClick event:
private void cmdLogin_ServerClick(object sender, System.EventArgs e)
{
If (ValidateUser(txtUserName.Value,txtUserPass.Value) )
{
FormsAuthentication.RedirectFromLoginPage(txtUserName.Value, false);
}
else
{
Response.Redirect("logon.aspx", true);
}
}
(2). Generate the authentication ticket, encrypt it, create a cookie, add it to the response, and redirect the user. This gives you more control in how you create the cookie. You can also include custom data along with the FormsAuthenticationTicket in this case.
Private void cmdLogin_ServerClick(object sender, System.EventArgs e)
{
if (ValidateUser(txtUserName.Value,txtUserPass.Value) )
{
FormsAuthenticationTicket tkt;
string cookiestr;
HttpCookie ck;
tkt = new FormsAuthenticationTicket(1, txtUserName.Value, DateTime.Now,
DateTime.Now.AddMinutes(30), chkPersistCookie.Checked, "your custom data");
cookiestr = FormsAuthentication.Encrypt(tkt);
ck = new HttpCookie(FormsAuthentication.FormsCookieName, cookiestr);
if (chkPersistCookie.Checked)
ck.Expires=tkt.Expiration;
ck.Path = FormsAuthentication.FormsCookiePath;
Response.Cookies.Add(ck);
string strRedirect;
strRedirect = Request["ReturnUrl"];
if (strRedirect==null)
strRedirect = "default.aspx";
Response.Redirect(strRedirect, true);
}
else
Response.Redirect("logon.aspx", true);
}
Additional Notes:
|
You may want to store passwords securely in a database. You can use the FormsAuthentication class utility function named HashPasswordForStoringInConfigFile to encrypt the passwords before you store them in the database or configuration file. |
|
You may want to store the SQL connection information in the configuration file (Web.config) so that you can easily modify it if necessary. |
|
You may consider adding code to prevent hackers who try to use different combinations of passwords from logging on. For example, you can include logic that accepts only two or three logon attempts. If the user cannot log on in a certain number of attempts, you may want to set a flag in the database to not allow that user to log on until that user re-enables his or her account by visiting a different page or by calling your support line. In addition, you should add appropriate error handling wherever necessary. |
|
Because the user is identified based on the authentication cookie, you may want to use Secure Sockets Layer (SSL) on this application so that no one can deceive the authentication cookie and any other valuable information that is being transmitted. |
|
Forms-based authentication requires that your client accept or enable cookies on their browser. |
|
The timeout parameter of the <authentication> configuration section controls the interval at which the authentication cookie is regenerated. You can choose a value that provides better performance and security. |
|
Certain intermediary proxies and caches on the Internet may cache Web server responses that contain Set-Cookie headers, which are then returned to a different user. Because forms-based authentication uses a cookie to authenticate users, this can cause users to accidentally (or intentionally) impersonate another user by receiving a cookie from an intermediary proxy or cache that was not originally intended for them. |