Asp.net Authentication and Authrozation

Because web applications use the stateless HTTP, no information is retained for the user between requests. As a result, the user must be authenticated and authorized at the beginning of each request. ASP.NET handles this by firing global application events. Authentication modules can handle these events to perform user authentication. Not all requests require authentication or authorization. However, the related events always fire.

The AuthenticateRequest event is raised by the HttpApplication object when a request requires authentication. Once the user is authenticated (typically supplying some sort of user credential such as a cookie with user information), the next step is to make sure the user identity information is readily available for the rest of the page-processing cycle. To accomplish this, you must create a new object with user information and attach it to the User property of the current HttpContext.

 The AuthorizeRequest event is raised after the user has been authenticated in the AuthenticateRequest event. Authorization modules use AuthorizeRequest to check whether the user is authorized for the resource they are requesting.

Note:The <authentication> element can be used only in the web.config that is in the root directory of an application. Attempting to use it in a subdirectory will cause an error. This means that only one authentication type can be defined for each application. However, different subdirectories can define different authorization rules.

Authorization
Once a user is authenticated, information such as the user’s name and security context is automaticallymade available by the ASP.NET infrastructure. You can access this information through the HttpContext.Current.User object and use this information to implement authorization in your code. Furthermore, ASP.NET includes the following prebuilt modules for implementing authorization:

UrlAuthorization: The UrlAuthorization module works based on the content of the <authorization>configuration in the web.config files of different directories of your web application. It can restrict access to both directories and files, based on the user’s name or the roles assigned to the user.

FileAuthorization: When using Windows authentication in intranets, ASP.NET automatically uses the FileAuthorization module for authorizing Windows users against files accessed by ASP.NET based on Windows ACLs. Therefore, each Windows user must have at least read access rights on the files of the web applications in that case. This module works with Windows authentication only—but without impersonation.

Membership API

The membership API is a complete user management system. It helps you create, edit, and delete users, and it includes functionality for password recovery.

Roles API

ASP.NET 2.0 includes a ready-to-use API that allows you to assign users to roles as needed.

Profiles API

The big difference between user profiles and session state is that profiles are persistent across multiple sessions. Again, ASP.NET 3.5 includes a ready-to-use infrastructure through the ASP.NET 2.0 foundation for managing profiles in your application.

Extending Membership, Roles, and Profiles
ASP.NET needs to store all the information of users, roles, and profiles somewhere. By default it stores the data in a SQL Server database. But the whole infrastructure is completely extensible through so-called custom providers.

Forms authentication is a ticket-based (also called token-based) system. This means when users log in, they receive a ticket with basic user information. This information is stored in an encrypted cookie that’s attached to the response so it’s automatically submitted on each subsequent request.

The Forms Authentication Classes
The most important part of the forms authentication framework is the FormsAuthenticationModule, which is an HttpModule class that detects existing forms authentication tickets in the request. If the ticket is not available and the user requests a protected resource, it automatically redirects the request to the login page configured in your web.config file before this protected resource is even touched by the runtime. If the ticket is present, the module automatically creates the security context by initializing the HttpContext.Current.User property with a default instance of GenericPrincipal, which contains a FormsIdentity instance with the name of the currently logged-in user.

Windows authentication

Unlike forms authentication, Windows authentication isn’t built into ASP.NET. Instead, Windows authentication hands over responsibility of authentication to IIS.

Basic authentication

After a user provides this information, the data is transmitted to the web server (in this case localhost). Once IIS receives the authentication data, it attempts to authenticate the user with the corresponding Windows account. The key limitation of Basic authentication is that it isn’t secure—at least not on its own. User name and password credentials obtained via Basic authentication are transmitted between the client and server as clear text. The data is encoded (not encrypted) into a Base64 string that eavesdroppers can easily read.

Digest Authentication
Digest authentication, like Basic authentication, requires the user to provide account information using a login dialog box that is displayed by the browser. Unlike Basic authentication, however, Digest authentication passes a hash of the password, rather than the password. (Digest is another name for hash, which explains the name of this authentication scheme.)

Currently, IIS Digest authentication works only with Internet Explorer 5.0 and later

Integrated Windows Authentication

For Integrated Windows authentication to work, both the client and the web server must be on the same local network or intranet.That’s because Integrated Windows authentication doesn’t actually transmit the user name and password information. Instead, it coordinates with the domain server or Active Directory instance where it is logged in and gets that computer to send the authentication information to the web server.