Microsoft.NET

……………………………………………….Expertise in .NET Technologies

ASP.NET Architecture

Posted by Ravi Varma Thumati on April 6, 2009

This section provides an overview of the ASP.NET infrastructure and subsystemrelationships, as they relate to the subject of security. The following illustration shows the relationships among the security systems in ASP.NET.

aspnet1

As the illustration shows, all Web clients communicate with ASP.NET applications through IIS. IIS deciphers and optionally authenticates the request. If Allow Anonymous is turned on, no authentication occurs. IIS also finds the requested resource ( such as an ASP.NET application ), and, if the client is authorized, returns the appropriate resource.

In addition to the built-in ASP.NET security features, an ASP.NET application can use the low-level security features of the .NET Framework.


Integrating with IIS


This release of ASP.NET uses IIS 5.0 as the primary host environment. When considering ASP.NET authentication, you should understand the interaction with IIS authentication services.

IIS always assumes that a set of credentials maps to a Windows NT account and uses them to authenticate a user. There are three different kinds of authentication available in IIS 5.0: basic, digest, and Integrated Windows Authentication ( NTLM or Kerberos ). You can select the type of authentication to use in the IIS administrative services. For more information on IIS authentication, see the IIS documentation.

If you request a URL containing an ASP.NET application, the request and authentication information are handed off to the application. ASP.NET provides the two additional types of authentication described in the following table.

ASP.NET authentication provider

Description

Forms authentication

A system by which unauthenticated requests are redirected to an HTML form using HTTP client-side redirection. The user provides credentials and submits the form. If the application authenticates the request, the system issues a form that contains the credentials or a key for reacquiring the identity. Subsequent requests are issued with the form in the request headers; they are authenticated and authorized by an ASP.NET handler using whatever validation method the application developer specifies.

Passport authentication

Centralized authentication service provided by Microsoft that offers a single log on and core profile services for member sites.

Using ASP.NET Configuration Files

ASP.NET configuration, of which security is a part, has a hierarchical architecture. All configuration information for ASP.NET is contained in files named Web.config and Machine.config. Web.config can be placed in the same directories as the application files. The Machine.config file is in the Config directory of the install root. Subdirectories inherit a directory’s settings unless overridden by a Web.config file in the subdirectory. In a Web.config file, there are sections for each major category of ASP.NET functionality. To see an example of the way in which the hierarchical configuration system works for security see Hierarchical Configuration Architecture.

The security section of a Web.config file is organized as follows:

<authentication mode = " [ Windows/Forms/Passport/None ] ">
   <forms name = " [ name ] " loginUrl = " [ url ] " >
      <credentials passwordFormat = " [ Clear, SHA1, MD5 ] ">
         <user name = " [ UserName ] " password = " [ password ] " />
      </credentials>
    </forms>
    <passport redirectUrl = "internal" />
</authentication>
 
<authorization>
   <allow users = " [ comma separated list of users ] "
      roles = " [ comma separated list of roles ] " />
   <deny  users = " [ comma separated list of users ] "
      roles = " [ comma separated list of roles ] " />
</authorization>
 
<identity impersonate  = " [ true/false ] " />

The default settings for these elements are shown in the following table.

Default Value

Comment

<allow roles= >

No default value

<allow users = “*”>

All

<authentication mode = “Windows”>

The authentication mode cannot be set at a level below the application root directory.

<credentials passwordFormat = “SHA1”>

The hashing algorithm to be used on passwords.

<deny roles = “”>

Empty

<deny users = “”>

Empty

<forms loginUrl = “login.aspx”>

If you set the mode to forms, and if the request does not have a valid form, this is the URL to which the request is directed for a forms-based logon.

<forms name = “.ASPXAUTH”>

Forms name.

<forms path = “/”>

Path.

<forms protection = “type”>

Type= [ All|None|Encryption|Validation ]

<forms timeout = “30”>

Timeout in seconds.

<forms validation = “?”>

True or false.

<identity impersonate = “false”>

Impersonation is disabled by default.

<passport redirectUrl = “internal”

If you set the mode to passport, and if the requested page requires authentication but the user has not logged on with Passport, then the user will be redirected to this URL.

<user name = “”>

Empty

<user password = “”>

Empty

There are three major subsections: authentication, authorization, and identity. The values for each of the elements are usually set by overriding this section of the computer-level configuration file with a similar section in an application configuration file placed in the application root. All subdirectories automatically inherit those settings. However, subdirectories can have their own configuration files that override other settings.

NOTE: ASP.NET configuration only applies to ASP.NET resources ( those registered to be handled by Aspnet_isapi.dll ). Unfortunately, ASP.NET configuration cannot provide authorization for non-Aspnet_isapi.dll resources, so TXT, HTML, GIF, JPEG, ASP, and other types of files are still accessible by all users, subject to IIS permissions. For example, even though the ASP.NET resources in a directory might be restricted by a Web.config file, all users can still view the files located in that directory if directory browsing is on and no other restrictions are in place.

You can avoid this situation by explicitly mapping such files, but not directories, to Aspnet_isapi.dll using the IIS administration tool. However, there could be a performance impact if you do this.

You can use the <location></location> tags to specify a particular file or directory to which settings should apply. For more information about how to use the <location> tag, see Hierarchical Configuration Architecture and Configuration <location> Settings.

For more details about ASP.NET configuration in general, see ASP.NET Configuration. The topics that follow provide the data flow details that show how security is handled by ASP.NET, and how the data flows through the security subsystems.

ASP.NET Architecture (Illustration)

ASP.NET uses ISAPI to run on the Internet Information Server (IIS) in Windows 2000 Server. Not only does IIS host ASP.NET but the ISAPI filter mechanism also allows both ASP and ASP.NET to coexist on the same IIS server. (IIS can direct a *.asp page to ASP and a *.aspx page to ASP.NET.)

The configuration of ASP.NET is managed by information stored in XML-format in a configuration file (Web.Config).

The cache allows for improved performance of ASP.NET, as the most commonly requested pages would be served from the ASP.NET cache.

State management services for ASP.NET are provided by the ASP.NET state service.

The .NET Framework provides the Common Language Runtime (CLR), which compiles and manages the execution of ASP.NET code, and the class libraries, which offer prebuilt programmatic functionality for Web Forms, XML support, and exception handling.

ADO.NET provides ASP.NET with connections to databases.

aspnet2

Asp.Net Page Life Cycle

Each request for an .aspx page that hits IIS is handed over to HTTP Pipeline. HTTP Pipeline is a chain of managed objects that sequentially process the request and convert it to plain HTML text content. The start point of HTTP Pipeline is the HttpRuntime class. The ASP.NET infrastructure creates each instance of this class per AppDomain hosted within the worker process. HttpRuntime class picks up an HttpApplication object from an internal pool and sets it to work on the request. It finds out what class has to handle the request. The association between the resources and handlers are stored in the configurable file of the application. In web.config and also in machine.config you will find these lines in <httpHandlers> section.

If you run through the following program, it will be much easier to follow

<add verb=”*” path=”*.aspx” type=”System.Web.UI.PageHandlerFactory”/>

This extension can be associated with HandlerClass or HandlerFactory class. HttpApplication object gets the page object that implements the IHttpHandler Interface. The process of generating the output to the browser is started when the object calls ProcessRequest method.

Page Life Cycle

Once the HTTP page handler class is fully identified, the ASP.NET runtime calls the handler’s ProcessRequest to start the process. This implementation begins by calling the method FrameworkInitialize(), which builds the control trees for the page. This is a protected and virtual member of TemplateControl class, class from which page itself derives.

Next the processRequest() makes page transits various phases: initialization, loading of viewstate and postback data, loading of page’s user code and execution postback server-side events. Then page enters in render mode, the viewstate is updated and HTML generated is sent to the output console. Finally page is unloaded and request is considered completely served.

Stages and corresponding events in the life cycle of the ASP.NET page cycle:

Stage

Events/Method

Page Initialization

Page_Init

View State Loading

LoadViewState

Postback data processing

LoadPostData

Page Loading

Page_Load

PostBack Change Notification

RaisePostDataChangedEvent

PostBack Event Handling

RaisePostBackEvent

Page Pre Rendering Phase

Page_PreRender

View State Saving

SaveViewState

Page Rendering

Page_Render

Page Unloading

Page_UnLoad


Some of the events listed above are not visible at the page level. It will be visible if you happen to write server controls and write a class that is derived from page.

Page Execution Stages

The first stage in the page life cycle is initialization. This is fired after the page’s control tree has been successfully created. All the controls that are statically declared in the .aspx file will be initialized with the default values. Controls can use this event to initialize some of the settings that can be used throughout the lifetime of the incoming web request. Viewstate information will not be available at this stage.

After initialization, page framework loads the view state for the page. Viewstate is a collection of name/value pairs, where control’s and page itself store information that is persistent among web requests. It contains the state of the controls the last time the page was processed on the server. By overriding LoadViewState() method, component developer can understand how viewstate is restored.

Once viewstate is restored, control will be updated with the client side changes. It loads the posted data values. The PostBackData event gives control a chance to update their state that reflects the state of the HTML element on the client.

At the end of the posted data changes event, controls will be reflected with changes done on the client. At this point, load event is fired.

Key event in the life cycle is when the server-side code associated with an event triggered on the client. When the user clicks on the button, the page posts back. Page framework calls the RaisePostBackEvent. This event looks up for the event handler and run the associated delegate.

After PostBack event, page prepares for rendering. PreRender event is called. This is the place where user can do the update operations before the viewstate is stored and output is rendered. Next stage is saving view state, all the values of the controls will be saved to their own viewstate collection. The resultant viewstate is serialized, hashed, base24 encoded and associated with the _viewstate hidden field.

Next the render method is called. This method takes the HtmlWriter object and uses it to accumulate all HTML text to be generated for the control. For each control the page calls the render method and caches the HTML output. The rendering mechanism for the control can be altered by overriding this render method.

The final stage of the life cycle is unload event. This is called just before the page object is dismissed. In this event, you can release critical resources you have such as database connections, files, graphical objects etc. After this event browser receives the HTTP response packet and displays the page.

Advertisements

2 Responses to “ASP.NET Architecture”

  1. Very effectively written information. Will probably be useful to anybody who usess it, together with myself. Keep up the nice work – for sure i’ll try extra posts.

  2. Thanks for taking the time to discuss this, I really feel strongly about it and love learning more on this topic. If possible, as you achieve experience, would you thoughts updating your weblog with further data? It is extremely useful for me.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: