There are many best practices to consider for web programming security and authorization. One approach to authorization involves placing some relatively boilerplate code on top of each page you want to protect, which redirects any connecting user to a login page. In the login page, the user is prompted for credentials, authenticated, and if all goes just fine, redirected to the originally requested page. This pattern doesn’t require rocket science, but is still made of code that you have to write yourself and use over and over again.
Forms authentication is just the ASP.NET built-in infrastructure that greatly simplifies the implementation of such a security and authentication model.
Any web developer would agree that Forms Authentication is the most practical security mechanism available in ASP.NET. The Forms Authentication is the ideal choice whenever you need to collect user credentials and process them internally; for example, against a database of login names. You enable Forms Authentication by putting the following code in the application’s web.config file:
<configuration>
<system.web>
<authentication mode="Forms">
<forms loginURL="login.aspx" />
</authentication>
</system.web>
</configuration>
This code alone doesn’t cause significant changes in your application as long as anonymous access to the pages is allowed. If some of the pages in your application must be available only to well-known users, you might want to indicate which users are not directly admitted. You can do this using the <authorization> section in the web.config file. For example, the following code blocks direct access to all the pages to anonymous users:
<authorization><br> <deny users="?" /><br></authorization>
A protected resource is any ASP.NET resource (.aspx, .asmx, .ashx, and so forth) located in a folder in which Forms Authentication and URL authorization is requested. When the browser attempts to access a protected resource, the Forms Authentication module kicks in and attempts to locate an authentication ticket for the caller. If no ticket is found—a ticket is merely a cookie with a particular name—the module redirects the request to a login page. The user enters name and password into the login form and clicks a button to have credentials processed by the system:
void LogonUser(object sender, EventArgs e)
{
string user = userName.Text;
string pswd = passWord.Text;
// Custom authentication
bool bAuthenticated = AuthenticateUser(user, pswd);
:
}
If the authentication process ends successfully, the Forms Authentication module creates the authentication ticket with a particular name and duration. When the browser issues a new request for the same original page, the module gets involved again, but this time the ticket is found and the call can be successfully resolved.
The ticket is a protected resource and can be encrypted and transmitted over a secure connection. If encryption is specified, then the cookie is encrypted using the Triple-DES (3DES) algorithm. Encryption is much more effective if combined with data validation. Data validation verifies that the contents of an encrypted cookie have not been tampered with along the way. Encryption and validation take some CPU time; for this reason, if you’re going to use HTTPS channels, you might want to drop cookie security entirely. By default, the authentication cookie lives 30 minutes, or whatever is the timeout set on the <forms> element. The cookie lifetime is independent from the duration of the browser session.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
