ASP.NET Authentication

ASP.NET Authentication

Authentication is the process of obtaining identification credentials from a user ( such as name and password ), and validating those credentials against some authority.

If the credentials are valid, the entity that submitted the credentials is considered an authenticated identity. Once an identity has been authenticated, the authorization process determines whether that identity has access to a given resource.

ASP.NET implements authentication through authentication providers, the modules that contain the code to authenticate the requestor's credentials. This section describes the authentication providers built into ASP.NET.


The Windows Authentication Provider
Describes how to use the Windows Authentication provider The Passport Authentication Provider
Describes how to use the Passport Authentication provider.
The Forms Authentication Provider
Describes how to use the Forms Authentication provider.


The Windows Authentication Provider

The WindowsAuthenticationModule provider relies on IIS to provide authenticated users, using any of the mechanisms IIS supports. The provider module constructs a WindowsIdentity object. The default implementation constructs a WindowsPrincipal object and attaches it to the application context. The WindowsPrincipal object maps identities to Windows groups.

If you use IIS authentication, the provider module uses the authenticated identity passed in from IIS. IIS authenticates the identity using basic, digest, or Windows authentication, or some combination of them. You can use impersonation and you can use NTFS ACL permissions to restrict or allow access to protected resources. This is the provider configuration you should use if you want to implement site security with a minimum of ASP.NET coding.

An important reason to use the Windows Authentication provider is to implement an impersonation scheme that can use any of the authentication methods that might have already been performed by IIS before passing the request to the ASP.NET application. To do this, set the authentication mode to Windows, and confirm that the impersonate element is set to true, as shown in the following example:



Please note that configuring an ASP.NET application has no effect on the IIS Directory Security settings. The systems are completely independent and are applied in sequence. In addition to selecting an authentication mode for an ASP.NET application, it is also important to configure IIS authentication appropriately.

Next you must set the NTFS ACLs to allow access only to the proper identities. If you want to enable impersonation for only a short time during request processing, you can do it by using an impersonation context and WindowsIdentity.Impersonate.

NOTE: A Windows identity for an anonymous user cannot be impersonated because it causes an exception.

First, set the impersonate element to false, then set up a context using the WindowsIdentity.Impersonate method, as follows:

WindowsImpersonationContext context =
WindowsIdentity.Impersonate ( impersonateToken );
// do whatever.
context.Undo ( );

Dim context As WindowsImpersonationContext = _
WindowsIdentity.Impersonate ( impersonateToken )
' do whatever.
context.Undo ( )

C# VB

Notice that you can use context.Undo for identity reversion.

As mentioned earlier, you can implement a custom Windows authorization scheme by using a WindowsAuthenticate_OnAuthenticate event handler to create a WindowsPrincipal or a GenericPrincipal object from a WindowsIdentity object. You can then use one of the new objects to implement your own custom authentication scheme. The WindowsPrincipal object maps identities to Windows groups. The default implementation constructs a WindowsPrincipal object and attaches it to the application context.

See Also

How ASP.NET Security Works

How ASP.NET Security Works
Essentially, securing an ASP.NET Web application entails controlling access to its resources.

The ASP.NET security framework accomplishes this by working in conjunction with the various security subsystems present in the machine where ASP.NET is installed. This includes security provided by the operating system ( NTFS file access permissions ) as well as security provided by IIS ( host or IP address authorization ).

And since ASP.NET is built on the Microsoft .NET Framework, the ASP.NET application developer also has access to all of the built-in security features of the .NET Framework, such as code access security and role-based user-access security.

It is imperative to understand how the various security subsystems interact, to be able to secure your ASP.NET application effectively.

Basically, to enable security for an ASP.NET application, you need to configure the application to implement, at the very least, the two fundamental functionalities described in the following table.

Security function---Authentication
Description ---- The process of obtaining identification credentials from a user ( such as name and password ), and validating those credentials against some authority.

Security function---Authorization
Description ---- The process of controlling access to resources based on the authenticated identification credentials ( such as role ).

ASP.NET implements authentication through authentication providers, the modules that contain the code to authenticate user credentials. ASP.NET includes the following authentication providers.

ASP.NET Authentication Provider
Windows Authentication
Description--- Provider ASP.NET uses Windows authentication in conjunction with IIS authentication. Authentication is performed by IIS in one of three ways: basic, digest, or Integrated Windows Authentication. When IIS authentication is complete, ASP.NET uses the authenticated identity to authorize access.

ASP.NET Authentication Provider
Forms Authentication
Description----Provider 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.

ASP.NET Authentication Provider
Passport Authentication
Description----Provider Centralized authentication service provided by Microsoft that offers a single logon and core profile services for member sites.

To enable authentication for an ASP.NET application, you need to create an authentication section entry in the application root configuration file. The general syntax for the authentication section is as follows:



mode = " [ Windows | Forms | Passport | None ] ">



The mode is set to one of the authentication methods: Windows, Forms, Passport, or None. The default is Windows.

The authentication mode cannot be set at a level below the application root directory. Like all other configuration settings, all subdirectories within the application boundary inherit the authentication mode, unless explicitly overriden in a child configuration file.

ASP.NET Security

ASP.NET Security
Lately at SCS I have been assigned to build up the security module and related tasks in the Real Estate Management System we are building. So I decided to share what I have learned in this past period and of course to hear from the community to find optimal solutions for the scenarios I worked with, all what I write here might be repeated but I will share it anyway.

In this part, I will show some important basic points that should be clear to everyone before implementing asp.net security tasks.

Looking at any web application, the security is a matter of users/passwords/roles/groups... etc. While ASP.NET provides more mechanisms for authentication and authorization that work with the Operating system,IIS and .NET framework classes. So the ASP.NET application runs through these 3 levels.

IIS Level
ASP.NET worker process level
ASP.NET pipeline level
So, the Big Question, What is the Identity that runs my application ?

First, When an IIS web server machine receives an ASP.NET request, the IIS assigns it to one of the threads pooled in it, IIS runs under the SYSTEM account which has all the powers in a Microsoft Windows operating system. You can read extra information in the ASP.NET Application Life Cycle Overview article on the msdn.

Next, the 3 security levels run on the request one after the other.

1- The IIS thread context : the identity of this thread is determined according to the settings of the website in the IIS which has one of the following settings:

Basic authentication prompts the user for a user name and a password, also called credentials, which are sent unencrypted over the network.
Integrated Windows authentication uses hashing technology to scramble user names and password before sending them over the network.
Digest authentication operates much like Basic authentication, except that passwords are sent across the network as a hash value. Digest authentication is only available on domains with domain controllers running Windows Server operating systems.
Anonymous authentication allows everyone access to the public areas of the Web sites, without asking for a user name or password. When this is set, the identity impersonates the identity set in the textboxes, with the default user name IUSR_MACHINENAME. Like shown in the figure down below.

Microsoft .NET Framework

Introducing the Microsoft .NET Framework

.NET (dot-net) is the name Microsoft gives to its general vision of the future of computing, the view being of a world in which many applications run in a distributed manner across the Internet. We can identify a number of different motivations driving this vision.

Firstly, distributed computing is rather like object oriented programming, in that it encourages specialised code to be collected in one place, rather than copied redundantly in lots of places. There are thus potential efficiency gains to be made in moving to the distributed model.

Secondly, by collecting specialised code in one place and opening up a generally accessible interface to it, different types of machines (phones, handhelds, desktops, etc.) can all be supported with the same code. Hence Microsoft's 'run-anywhere' aspiration.

Thirdly, by controlling real-time access to some of the distributed nodes (especially those concerning authentication), companies like Microsoft can control more easily the running of its applications. It moves applications further into the area of 'services provided' rather than 'objects owned'.

Interestingly, in taking on the .NET vision, Microsoft seems to have given up some of its proprietary tendencies (whereby all the technology it touched was warped towards its Windows operating system). Because it sees its future as providing software services in distributed applications, the .NET framework has been written so that applications on other platforms will be able to access these services. For example, .NET has been built upon open standard technologies like XML and SOAP.

At the development end of the .NET vision is the .NET Framework. This contains the Common Language Runtime, the .NET Framework Classes, and higher-level features like ASP.NET (the next generation of Active Server Pages technologies) and WinForms (for developing desktop applications).

The Common Language Runtime (CLR) manages the execution of code compiled for the .NET platform. The CLR has two interesting features. Firstly, its specification has been opened up so that it can be ported to non-Windows platforms. Secondly, any number of different languages can be used to manipulate the .NET framework classes, and the CLR will support them. This has led one commentator to claim that under .NET the language one uses is a 'lifestyle choice'.

Not all of the supported languages fit entirely neatly into the .NET framework, however (in some cases the fit has been somewhat Procrustean). But the one language that is guaranteed to fit in perfectly is C#. This new language, a successor to C++, has been released in conjunction with the .NET framework, and is likely to be the language of choice for many developers working on .NET applications.

State Management Techniques in ASP.NET-2

Control State:
Control State is new mechanism in ASP.NET 2.0 which addresses some of the shortcomings of View State. Control state can be used to store critical, private information across post backs. Control state is another type of state container reserved for controls to maintain their core behavioral functionality whereas View State only contains state to maintain control's contents (UI). Control State shares same memory data structures with View State. Control State can be propagated even though the View State for the control is disabled. For example, new control Grid View in ASP.NET 2.0 makes effective use of control state to maintain the state needed for its core behavior across post backs. Grid View is in no way affected when we disable View State for the Grid View or entire page
Server Side State management:
As name implies, state information will be maintained on the server. Application, Session, Cache and Database are different mechanisms for storing state on the server.
Care must be taken to conserve server resources. For a high traffic web site with large number of concurrent users, usage
of sessions object for state management can create load on server causing performance degradation
Application object:
Application object is used to store data which is visible across entire application and shared across multiple user sessions. Data which needs to be persisted for entire life of application should be stored in application object.
In classic ASP, application object is used to store connection strings. It's a great place to store data which changes infrequently. We should write to application variable only in application_Onstart event (global.asax) or application.lock event to avoid data conflicts. Below code sample gives idea
Application.Lock();
Application["mydata"]="mydata";
Application.UnLock();
Session object:
Session object is used to store state specific information per client basis. It is specific to particular user. Session data persists for the duration of user session you can store session's data on web server in different ways. Session state can be configured using the section in the application's web.config file.
Configuration information:

sessionState mode = <"inproc" | "sqlserver" | "stateserver">
cookieless = <"true" | "false">
timeout =
sqlconnectionstring =
server =
port =
Mode:

This setting supports three options. They are InProc, SQLServer, and State Server

Cookie less:
This setting takes a Boolean value of either true or false to indicate whether the Session is a cookie less one.
Timeout:
This indicates the Session timeout vale in minutes. This is the duration for which a user's session is active. Note that the session timeout is a sliding value; Default session timeout value is 20 minutes

SqlConnectionString:
This identifies the database connection string that names the database used for mode SQLServer.

Server:
In the out-of-process mode State Server, it names the server that is running the required Windows NT service: aspnet_state.

Port:

This identifies the port number that corresponds to the server setting for mode State Server. Note that a port is an unsigned integer that uniquely identifies a process running over a network.
You can disable session for a page using EnableSessionState attribute. You can set off session for entire application by setting mode=off in web.config file to reduce overhead for the entire application.
Session state in ASP.NET can be configured in different ways based on various parameters including scalability, maintainability and availability
• In process mode (in-memory)- State information is stored in memory of web server
• Out-of-process mode- session state is held in a process called aspnet_state.exe that runs as a windows service.
• Database mode – session state is maintained on a SQL Server database.
In process mode:

This mode is useful for small applications which can be hosted on a single server. This model is most common and default method to store session specific information. Session data is stored in memory of local web server
Configuration information:
sqlConnectionString="data source=server;user id=freelance;password=freelance"
cookieless="false" timeout="20" />
Advantages:
• Fastest mode
• Simple configuration
Disadvantages:
• Session data will be lost if the worker process or application domain recycles
• Not ideal for web gardens and web farms
Out-of-process Session mode (state server mode):

This mode is ideal for scalable and highly available applications. Session state is held in a process called aspnet_state.exe that runs as a windows service which listens on TCP port 42424 by default. You can invoke state service using services MMC snap-in or by running following net command from command line.
Net start aspnet_state
Configuration information:

StateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=freelance; password=freelance"
cookieless="false" timeout="20"/>
Advantages:
• Supports web farm and web garden configuration
• Session data is persisted across application domain recycles. This is achieved by using separate worker process for maintaining state
Disadvantages:
• Out-of-process mode provides slower access compared to In process
• Requires serializing data
SQL-Backed Session state:
ASP.NET sessions can also be stored in a SQL Server database. Storing sessions in SQL Server offers resilience that can serve sessions to a large web farm that persists across IIS restarts.

SQL based Session state is configured with aspnet_regsql.exe. This utility is located in .NET Framework's installed directory
C:\\microsoft.net\framework\. Running this utility will create a database which will manage the session state.
Configuration Information:
sqlConnectionString="data source=server;user id=freelance;password=freelance"
cookieless="false" timeout="20" />
Advantages:
• Supports web farm and web garden configuration
• Session state is persisted across application domain recycles and even IIS restarts when session is maintained on different server.
Disadvantages:
• Requires serialization of objects
Choosing between client side and Server side management techniques is driven by various factors including available server resources, scalability and performance. We have to leverage both client side and server side state management options to build scalable applications.
When leveraging client side state options, ensure that little amount of insignificant information is exchanged between page requests.
Various parameters should be evaluated when leveraging server side state options including size of application, reliability and robustness. Smaller the application, In process is the better choice. We should account in the overheads involved in serializing and deserializing objects when using State Server and Database based session state. Application state should be used religiously.

State Management Techniques in ASP.NET-1

This article discusses various options for state management for web applications developed using ASP.NET. Generally, web applications are based on stateless HTTP protocol which does not retain any information about user requests. In typical client and server communication using HTTP protocol, page is created each time the page is requested.

Developer is forced to implement various state management techniques when developing applications which provide customized content and which "remembers" the user.
Here we are here with various options for ASP.NET developer to implement state management techniques in their applications. Broadly, we can classify state management techniques as client side state management or server side state management. Each technique has its own pros and cons. Let's start with exploring client side state management options.
Client side State management Options:

ASP.NET provides various client side state management options like Cookies, QueryStrings (URL), Hidden fields, View State and Control state (ASP.NET 2.0). Let's discuss each of client side state management options.
Bandwidth should be considered while implementing client side state management options because they involve in each roundtrip to server. Example: Cookies are exchanged between client and server for each page request.
Cookie:

A cookie is a small piece of text stored on user's computer. Usually, information is stored as name-value pairs. Cookies are used by websites to keep track of visitors. Every time a user visits a website, cookies are retrieved from user machine and help identify the user.

Let's see an example which makes use of cookies to customize web page.

if (Request.Cookies["UserId"] != null)
lbMessage.text = "Dear" + Request.Cookies["UserId"].Value + ", Welcome to our website!";
else
lbMessage.text = "Guest,welcome to our website!";
If you want to store client's information use the below code
Response.Cookies["UserId"].Value=username;
Advantages:
• Simplicity
Disadvantages:
• Cookies can be disabled on user browsers
• Cookies are transmitted for each HTTP request/response causing overhead on bandwidth
• Inappropriate for sensitive data
Hidden fields:

Hidden fields are used to store data at the page level. As its name says, these fields are not rendered by the browser. It's just like a standard control for which you can set its properties. Whenever a page is submitted to server, hidden fields values are also posted to server along with other controls on the page. Now that all the asp.net web controls have built in state management in the form of view state and new feature in asp.net 2.0 control state, hidden fields functionality seems to be redundant. We can still use it to store insignificant data. We can use hidden fields in ASP.NET pages using following syntax
protected System.Web.UI.HtmlControls.HtmlInputHidden Hidden1;

//to assign a value to Hidden field
Hidden1.Value="Create hidden fields";
//to retrieve a value
string str=Hidden1.Value;
Advantages:
• Simple to implement for a page specific data
• Can store small amount of data so they take less size.
Disadvantages:
• Inappropriate for sensitive data
• Hidden field values can be intercepted(clearly visible) when passed over a network
View State:

View State can be used to store state information for a single user. View State is a built in feature in web controls to persist data between page post backs. You can set View State on/off for each control using EnableViewState property. By default, EnableViewState property will be set to true. View state mechanism poses performance overhead. View state information of all the controls on the page will be submitted to server on each post back. To reduce performance penalty, disable View State for all the controls for which you don't need state. (Data grid usually doesn't need to maintain state). You can also disable View State for the entire page by adding EnableViewState=false to @page directive. View state data is encoded as binary Base64 - encoded which add approximately 30% overhead. Care must be taken to ensure view state for a page is smaller in size. View State can be used using following syntax in an ASP.NET web page.
// Add item to ViewState
ViewState["myviewstate"] = myValue;

//Reading items from ViewState
Response.Write(ViewState["myviewstate"]);

Advantages:
• Simple for page level data
• Encrypted
• Can be set at the control level
Disadvantages:
• Overhead in encoding View State values
• Makes a page heavy
Query strings:
Query strings are usually used to send information from one page to another page. They are passed along with URL in clear text. Now that cross page posting feature is back in asp.net 2.0, Query strings seem to be redundant. Most browsers impose a limit of 255 characters on URL length. We can only pass smaller amounts of data using query strings. Since Query strings are sent in clear text, we can also encrypt query values. Also, keep in mind that characters that are not valid in a URL must be encoded using Server.UrlEncode.
Let's assume that we have a Data Grid with a list of products, and a hyperlink in the grid that goes to a product detail page, it would be an ideal use of the Query String to include the product ID in the Query String of the link to the product details page (for example, productdetails.aspx?productid=4).
When product details page is being requested, the product information can be obtained by using the following codes:
string productid;
productid=Request.Params["productid"];
Advantages:
• Simple to Implement
Disadvantages:
• Human Readable
• Client browser limit on URL length
• Cross paging functionality makes it redundant
• Easily modified by end user


NEXT>>>

Interfaces and Abstract classes

Interfaces and Abstract classes

Introduction
The choice of whether to use an interface or an abstract can sometimes be a difficult one. This article shows you the differences between these two and also tells you when and where to use them.
Interfaces
Interfaces, like classes, define a set of properties, methods, and events. But unlike classes, interfaces do not provide implementation. An interface represents a contract, and a class that implements an interface must implement every aspect of that interface exactly as it is defined.
You declare an interface by using the interface keyword
Example
interface IPerson
{
void Eat();

void Sleep();

int Weight
{
set;
get;
}
}
In order to use this interface, you must declare your class in the same way that you declare a class inheriting from any other object.
Example
public class Man:IPerson
{
int iWeight;

public Man()
{
}

public void Eat()
{
MessageBox.Show("Man:Eat");
}

public void Sleep()
{
MessageBox.Show("Man:Sleep");
}

public int Weight
{
set
{
iWeight = value;
}
get
{
return iWeight;
}
}

static void Main()
{
Man i = new Man();
i.Eat();
i.Sleep();
}

}

You get the following result when you run the above code.
Man:Eat
Man:Sleep

It is important to note here that an interface is very different from a base class. An interface is implemented, not extended.
1.A class can implement multiple interfaces.
2.An interface cannot contain data declarations but you can declare properties.
3.All method declarations in an interface are public.
4.There can be no implementation in an interface.
5.The class implementing the interface must provide implementation code.
6.An interface can be derived from another interface
Abstract Classes
An abstract class is a class that cannot be instantiated, but must be inherited from. An abstract class may be fully implemented, but is more usually partially implemented or not implemented at all, thereby encapsulating common functionality for inherited classes.

When you have a class that contains methods that have no implementation (i.e. abstract methods), the class is said to be abstract as well. An abstract method is simply a shell or place-marker for a method that will be defined later in a derived class. The intention of abstract methods is to force every derivation of the class to implement those methods. If a derived class does not implement an abstract method, then that class must also be declared as abstract.

You declare an interface by using the interface keyword
abstract public class Person
{
abstract public void Eat();

public void Sleep()
{
MessageBox.Show("Person:Sleep");
}

abstract public int Weight
{
set;
get;
}
}
You can inherit the abstract class just like any other class.
public class Man:Person
{
int iWeight;

public Man()
{
}
override public void Eat()
{
MessageBox.Show("Man:Eat");
}
override public int Weight
{
set
{
iWeight = value;
}
get
{
return iWeight;
}
}

static void Main()
{
Man i = new Man();
i.Eat();
i.Sleep();
}
}

You get the following result when you execute the above code.
Man:Eat
Person:Sleep

So why would you declare a class abstract? It’s actually a very powerful class hierarchy design tool since you can provide the structure for something that is not very specific —just like our Person class. You will never create an Person object; but you will create Man and Woman objects. The other advantage is that you are moving the code to where it actually belongs. This helps you locate program logic problems.

A class that is derived from an abstract class may still implement interfaces.

Abstract classes are useful when creating components because they allow you specify an invariant level of functionality in some methods, but leave the implementation of other methods until a specific implementation of that class is needed. If additional functionality is needed in derived classes, it can be added to the base class without breaking code.

In the above example, an abstract class is declared with one implemented method, one unimplemented method and one unimplemented property. A class inheriting from this class would have to implement the Eat method and Weight property

When implementing an abstract class, you must implement each abstract method in that class, and each implemented method must receive the same number and type of arguments, and have the same return value, as the method specified in the abstract class.
Recommendations on using Abstract Classes and Interfaces
1. If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
2. If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
3. If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
4. If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.

Storing Session information

Storing Session information

HTML (which is what gets displayed in your browser) is great for displaying web pages, but is a stateless protocol. So each page is dealt with as an isolated (request and response) transaction and there is no management of which browser a request came from.
ASP.NET has the concept of a "session", which starts when a client first requests a page and ends after a definable period of inactivity. ASP.NET sends a unique cookie to the browser with each page which the browser then sends back for each subsequent page request which enables the server to associate each request with a session.
As well as the information ASP.NET stores in the session, applications can also store information in the session through the session object.
ASP.NET provides three methods to store session information:
• In Process (InProc)
• State Server
• SQL Server
InProc is the default method, but which is best for your application? The following is provided as a summary of the strengths and weaknesses of each:



In Process:::

Advantages:1. Default.
2. Fastest.
3. Simplest

Disadvantages
1. Session information lost if the worker process (either aspnet_wp.exe or w3wp.exe) is restarted (for a developer this includes a rebuild on the development machine).
2. Not suitable for web-farms




State Server:::
Advantages:
1. Tolerant of worker process crashes.
2. Suitable for web-farms.

Disadvantages:
1. Slower than In-Process.
2. State is maintained on a single server, and thus a single point of failure (only an issue if site up-time and fault tolerance is an issue)


SQL Server:::

Advantages:
1. Tolerant of worker process crashes.
2. Suitable for web-farms.
3. Supports failover clusters

Disadvantages:
1. Requires SQL Server.
2. Slowest method.
3. Most complex to set up.





In Process
Storing session information "In Process" (also sometimes referred to as "InProc") means that all session information is stored in the worker process "aspnet_wp.exe". It has the following advantages:
• It is the default method - so its simple because no configuration is required on the part of the developer.
• Is is the fastest method.
It also has the following disadvantages:
• All session information is lost if the aspnet_wp.exe process is restarted. This also means that session information will be lost after a recompile of the application, but there are numerous other times when the aspnet_wp.exe process will be recycled.
• It is not suitable for use on a web-farm, i.e. where there is more than one computer that could respond to a request. This is simply because if a subsequent request is handled by a different server then that server will not have access to the session information (because the session information is stored on a different server).
The following is the entry in the web.config file to configure session information to be stored InProc:
mode="InProc"
cookieless="false"
timeout="20" />
The default configuration installed will also contain entries for "stateConnectionString" and "sqlConnectionString". These are default entries that are only used if the "mode" is changed and can be ignored if storing "InProc".
State Server
With the "State Server" model session information is stored in a separate "state server" process. The worker process (aspnet_wp.exe) will communicate with the State Server (aspnet_state.exe) to store and retrieve session information.
If you are working in an environment where there is more than one web server then another key difference from the in-process model is that all the servers should be configured to talk to the same state server process. This is a configuration issue and it would be easy to (wrongly) configure a web farm to use separate state server process on each server.
Storing session information in the state server has the following advantages:
• It is tolerant of the worker process being recycled. For developers this has the advantage (or disadvantage!) that session information is maintained across compiles of the application.
• It is suitable for use on web-farms.
and the following disadvantages:
• It is slightly slower and more resource demanding than the in-process model, because there is an extra level of communication required between processes.
• State information is stored on a single server - this is not an issue normally but might be if you need to avoid a single point of failure (in which case SQL Server is the route to go because it supports failover servers).
To configure to use the state server model requires the sessionState parameter in the web.config file to be updated:
mode="StateServer"
stateConnectionString="tcpip=server1:42424"
cookieless="false"
timeout="20" />
The default entry for stateConnectionString is "stateConnectionString="tcpip=127.0.0.1:42424", this is reasonable if the state server is on the same server (The IP address 127.0.0.1 is by definition the local machine). If however you are running in a web-server environment then it is vitally important that you set the server name, so substitute the name of a server for "server1" in the above example. Otherwise each server will communicate with the state server process running locally and session information will not be shared between servers.
You also need to ensure that the state server is running on the chosen server. Do this by looking at the services on the server and ensure that "ASP.NET State Service" is started and set to "Automatic" start-up.
SQL Server
In "SQL Server" mode session information is stored in an SQL Server database. The worker process (aspnet_wp.exe) will communicate with the SQL Server database to store and retrieve session information.
SQL Mode has the following advantages:
• Tolerant of worker process crashes.
• Suitable for web-farms.
• Can be configured to work in a failover cluster. Basically the session information is stored on more than one server so if a database fails then the session information is not lost. This is ideally suited to environments where high availability is required (but doesn't come cheap!).
and the following disadvantages:
• It requires SQL Server
• It is the slower than both In-Proc and State-Server methods.
• Is the most complex to set up.

SDLC Model in Software Development

SDLC Model in Software Development
Basic models used by software development firms are
a) System Development Life Cycle (SDLC) Model
b) Prototyping Model
c) Rapid Application Development Model
d) Component Assembly Model
we study the basic
System Development Life Cycle Model (SDLC Model)
This is also known as Classic Life Cycle Model (or) Linear Sequential Model (or) Waterfall Method. This has the following activities.
1. System/Information Engineering and Modeling
2. Software Requirements Analysis
3. Systems Analysis and Design
4. Code Generation
5. Testing
6. Maintenance

System/Information Engineering and Modeling
This system view is essential when software must interface with other elements such as hardware, people and other resources. System is the basic and very critical requirement for the existence of software in any entity. So if the system is not in place, the system should be engineered and put in place. In some cases, to extract the maximum output, the system should be re-engineered and spruced up. Once the ideal system is engineered or tuned, the development team studies the software requirement for the system.

Software Requirement Analysis
This is also known as feasibility study. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system. By the end of the feasibility study, the team furnishes a document that holds the different specific recommendations for the candidate system. It also includes the personnel assignments, costs, project schedule, and target dates

System Analysis and Design
In this phase, the software development process, the software's overall structures are defined, the number of tiers needed for the package architecture, the database design, the data structure design etc are all defined in this phase. A software development model is created. The logical system of the product is developed in this phase.

Code Generation
The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication. Programming tools like Compilers, Interpreters and Debuggers are used to generate the code. Different high level programming languages like C, C++, Pascal, and Java are used for coding. With respect to the type of application, the right programming language is chosen.

Testing
Once the code is generated, the software program testing begins. Different testing methodologies are available to unravel the bugs that were committed during the previous phases. Different testing tools and methodologies are already available.

Maintenance
Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period