Understanding Impersonation in ASP.NET

At times users access a resource as though they were someone else. This is known as impersonation. For example, if a web page has no access controls, then any user can access that web page. HTML pages, ASP pages, and components in version 3.0 and earlier can be accessed through two accounts named IUSR_machinename and IWAM_machinename. Both the accounts are set up during IIS installation, and are automatically added to all the folders in every web site on the server.

Anonymous access to a resource in IIS makes the task of identifying a user extremely difficult. But there is no need to authenticate a user in the case of IIS. When IIS receives a request for a web page or other resource that has permission for anonymous access, IIS treats the IUSR_machinename account as the user's account, to access the resources. If the resource requested by the user is an ASP page that uses a COM or COM+ component, that component is executed using the IWAM_machinename account.

In ASP.NET, when impersonation is turned off, the resources can be accessed using a "local system process" account. When impersonation is turned on, ASP.NET executes every resource using the account of a specified user who is authenticated when the user makes the request. If you specify the IUSR_machinename account to be used as the user account, then ASP.NET will behave like previous versions of ASP, in providing access to the resources.

In ASP.NET, you first need to check whether the application is configured to use impersonation. In the case of IIS, the IIS impersonates users with its own IUSR account. In the case of ASP.NET, impersonation is used to decide whether the user's request should be executed using the account of the requested user, or that of a local system-process account that ASP.NET uses for anonymous requests.

The concept of impersonation is complex to some extent due to the fact that ASP.NET uses the dynamic compilation features of the .NET Framework. The IUSR account has only limited permissions on the local machine, and so is not suitable without some reconfiguration. This account is also used by IIS to access resources like HTML pages, documents, and zip files that are not executed as part of the .NET Framework.

If impersonation is enabled in an ASP.NET application then:
• If anonymous access is enabled in IIS, the request is made using the IUSR_machinename account.
• If anonymous access is disabled in IIS, the request is made using the account of the authenticated user.
• In either case, permissions for the account are checked in the Windows Access Control List (ACL) for the resource(s) that a user requests, and a resource is only available if the account they are running under is valid for that resource.

If impersonation is disabled in an ASP.NET application then:
• If anonymous access is enabled in IIS, the request is made using the system-level process account.
• If anonymous access is disabled in IIS, the request is made using the account of the authenticated user.
• In either case, permissions for the account are checked in the Windows ACL for the resource(s) that a user requests, and a resource is only available if the account they are running under is valid for that resource.

ASP.NET Impersonation

ASP.NET Web Applications ASP.NET Web Application Security

When using impersonation, ASP.NET applications can optionally execute with the identity of the client on whose behalf they are operating. The usual reason for doing this is to avoid dealing with authentication and authorization issues in the ASP.NET application code. Instead, you rely on IIS to authenticate the user and either pass an authenticated token to the ASP.NET application or, if unable to authenticate the user, pass an unauthenticated token. In either case, the ASP.NET application impersonates whichever token is received if Impersonation is enabled. The ASP.NET application, now impersonating the client, then relies on the settings in the NTFS directories and files to allow it to gain access, or not. Be sure to format the server file space as NTFS, so that access permissions can be set.

For ASP compatibility, impersonation is disabled by default. If impersonation is enabled for a given application, ASP.NET always impersonates the access token that IIS provides to ISAPI extensions. That token can be either an authenticated user token, or the token for the anonymous user ( such as IUSR_MACHINENAME ). The impersonation occurs regardless of the type of authentication being used in the application and whether the user is authenticated, in which case, it is the anonymous user token.

Only application code is impersonated; compilation and configuration are read as the process token. If an application is on a UNC share, ASP.NET will always impersonate the token provided to IIS to access that share unless a configured account is used. If an explicit configured account is provided, ASP.NET will use that account in preference to the IIS UNC token. Applications that do want per-request impersonation can simply be configured to impersonate the user making the request.

Impersonation is disabled at the computer level by default and, unless overridden, all the application domains inherit this setting. You can enable impersonation by putting a configuration file in the application root directory. For more information about the ASP.NET configuration system, see ASP.NET Configuration.

As is the case with other configuration directives, this directive applies hierarchically. It is respected by nested applications in the hierarchy, unless explicitly overridden. The default value for this setting is as follows:



A minimal configuration file to enable impersonation for an application might look similar to the following example:



There is also name support for running an application as a configurable identity. For example:



This enables the entire application to run as Redmond\Dev, regardless of the identity of the request, so long as the password is correct. This type of impersonation can be delegated to another computer.

Understanding WSDL and UDDI

Web Services Description Language (WSDL) is one of the prime specifications in web services, the other two being SOAP and UDDI. WSDL is the description language for web services that describes a set of SOAP messages and how these messages are exchanged across network. WSDL will be in XML format; therefore it can be easily understood and edited by humans and machines.

Another advantage of WSDL being in XML format is that it is programming language independent and also platform independent. In addition, WSDL defines where the web service is available from and what communications protocol has been used to talk to the web service. As a result the WSDL file describes everything that is required to write a program for an XML Web service. There are tools available in Microsoft Visual Studio .NET to read a WSDL file and generate the code required to communicate with an XML Web service.

Universal Discovery Description Language (UDDI) is a directory where you can expose your web services for other users to easily access it. You can also consume the web service that is already posted in UDDI. However, you can also post a web service without registering it in UDDI. DISCO is another directory where you can post your web service. But if you want to reach to maximum of customers, you can place it in UDDI. The UDDI directory offers three parts for you to register:

• White Pages
• Yellow Pages
• Green Pages

The white pages consist of the description such as name and address of the company offering the service. The yellow pages consist of industrial categories based on standard taxonomies such as North American Industry Classification System and Standard Industrial Classification. The green pages describe the interface to the web service in detail so that anyone can write an application after using the web service. Web services are described in UDDI directory through a document called Type Model or tmodel. Normally, this tModel contains a WSDL file that describes a SOAP interface to an XML Web service, but the tModel is flexible enough to describe almost any kind of web service.

Apart from using the web services from UDDI, you can also search a particular web service in UDDI. In addition, you can search for companies’ information that posted web services. In certain times, you might know the names of the companies that offer web services but you may not be aware of the web services that they offer. The WS Inspection is a specification in UDDI that allows you to search for a collection of web services that are located in a particular company name. You can evaluate these web services according to your requirements.

Access Control List in .NET Framework

Once you complete developing a web application, you need to secure it. This is when the aspect of security comes into picture. There will be some portions of your application which need to be secured from users. Securing an application may need extra hardware to build complex multi-layer systems with firewalls, and also some highly secure features. Security enables you to provide access to a specified user after the user is authenticated and authorized to access the resources in your web application. The Access Control List is used in the authorization process.

The basic concepts of security are Authentication, Authorization, Impersonation and Data or functional security. Authentication is the process that enables to identify a user, so that only that user is provided access to the resources. Authorization is the process that enables to determine whether a particular user can be given access to the resources that the user requests. Impersonation is the process that provides access to resources requested by a user under a different identity. Data or functional security is the process of securing a system physically, updating the operating system and using robust software.

Some elements of an operating system, the Internet Information Server (IIS), and the .NET Framework work in coordination to provide the features required to execute the security concepts mentioned above. For example, Windows 2000 uses its own list of user accounts for identifying and authenticating users. IIS identifies the users based on the information provided by Windows, when the users access a web site. IIS after identification of the users, passes this information to ASP.NET. Then the user information is checked for authorization.

To restrict access to the users for certain resources of an application, a process of identifying the users becomes a necessity. Authentication enables to restrict a user to access the resources by certain ways. It could be a combination of a username and password, a digital certificate, a smart card or a fingerprint reader. The validity of the information provided by the user helps identify the user, so that the user is provided access to the requested resources. The process of successful identification of the user implies that the user is authenticated.

After identification of the user is over, the next step is to determine whether the authenticated user has access to the resources. The process of determining the access to the resources for a particular user is known as Authorization. In Windows based systems, resources have an Access Control List, which provides a list of users who have access to that resource. The list also specifies the kind of access such as read, write, modify, and delete the resource, for each user. For example, if a user requests an ASP page, the operating system checks whether the user has Read access to the page and if the user has read permission, then the operating system allows the IIS to fetch the page. The IIS has authorization settings which enable the IIS to control the access of resources by users. File Access Control Lists are set for a given file or directory using the Security tab in the Explorer property page.

Web Forms in .NET Framework

Web pages in ASP.Net are called ASP.NET Web Forms which have certain server controls such as text, dropdown list, checkboxes, and buttons. An ASP.NET Web Form looks similar to the web forms in HTML. The only difference is that in ASP.NET, the Web Forms runs at the server side and in HTML the web forms runs at the client side. Apart from this difference an ASP.NET Web Form has more features than an ordinary HTML web form such as:

The code blocks are processed on the server.
• The entire page in ASP.NET is compiled when it is requested for the first time. When you make subsequent requests, the page is not compiled but shown directly in your browser.
• ASP.NET Web Forms can contain page directives. Page directives allow you to set the default language and user controls tags for the entire page. You can also turn off session state and ViewState management using page directives.
• An ASP.NET Web Form can contain both user controls and Server side Includes (SSIs).
• An ASP.NET Web Form though run on the server can contain client side script such as JavaScript or Jscript.

An ASP.NET Web Form first gets compiled into Intermediate Language (IL) and later to the machine language. Not just the server side code gets compiled but every control and element in the page gets compiled. This enables the ASP.NET Web Form to be in any language that is compatible with Common Language Runtime (CLR) engine. Another advantage with the code getting translated to IL is that the user can use the application in any browser. In addition, you can reduce the processors and server’s load when you compile the ASP.NET Web Forms in ASP.NET, thereby, increasing the user’s productivity time. Thus ASP.NET allows you to create Web Forms that are platform independent, language independent, and browser independent.

User Controls in .NET Framework

Though you can apply multiple server controls in your web form, ASP.NET allows you to create new controls according to your requirements. The controls that you create are called ASP.NET User Controls. ASP.NET User Controls have .ascx extension. The biggest advantage of ASP.NET User Controls is that it allows you to save a part of the web form and reuse it many other web forms. This drastically reduces the developers’ time.

ASP.NET User Controls are self-contained entities that are saved in an independent file. You can relate a user control with a “black box”. ASP.NET User Controls are very helpful when you want to use functionality on multiple pages of a web-application. For example, if you want to use a site navigation header or footer on all the pages of the web application, you can create this site navigation header or footer as a user control in a separate page. You do not need to place this user control on each and every page. You just have to write a few lines code to call the user control.

<%@ Register TagPrefix="sampNamespace" TagName="Myname" Src="mypage.ascx" %>

The TagPrefix is the exclusive namespace provided to the user control so that multiple ASP.NET User Controls with similar name can be discriminated from each other. The TagName is the name of the user control and the Src is the virtual path to the user control. After registering the user control you can place the tag of the user control in an appropriate location on the web form. You have to include the runat=”server” attribute with the tag.

You can create a user control using only one programming language for a web form. However, you can create multiple ASP.NET User Controls for a web form. For example, you can create a user control using C# and another user control using VB.NET and use both the ASP.NET User Controls on the same web form.

ASP.NET Assemblies in .Net

An assembly in ASP.NET is a collection of single-file or multiple files. The assembly that has more than one file contains either a dynamic link library (DLL) or an EXE file. The assembly also contains metadata that is known as assembly manifest. The assembly manifest contains data about the versioning requirements of the assembly, author name of the assembly, the security requirements that the assembly requires to run, and the various files that form part of the assembly.



The biggest advantage of using ASP.NET Assemblies is that developers can create applications without interfering with other applications on the system. When the developer creates an application that requires an assembly that assembly will not affect other applications. The assembly used for one application is not applied to another application. However one assembly can be shared with other applications. In this case the assembly has to be placed in the bin directory of the application that uses it.

This is in contrast to DLL in the past. Earlier developers used to share libraries of code through DLL. To use the DLL that is developed by another developer for another application, you have to register that DLL in your machine. In ASP.NET, the assembly is created by default whenever you build a DLL. You can check the details of the manifest of the assembly by using classes located in the System.Reflection namespace.

Thus you can create two types of ASP.NET Assemblies in ASP.NET: private ASP.NET Assemblies and shared assemblies. Private ASP.NET Assemblies are created whey you build component files like DLLs that can be applied to one application. Shared ASP.NET Assemblies are created when you want to share the component files across multiple applications. Shared ASP.NET Assemblies must have a unique name and must be placed in Global Assembly Cache (GAC). The GAC is located in the Assembly directory in WinNT. You can view both the manifest and the IL using ILDisassembler (ildasm.exe).

Just in time (JIT) compiler

The high level programming languages that need to be compiled require a runtime, so that the architecture on which the language runs is provided with details on how to execute its code. All the programming languages use its corresponding runtime to run the application. For example, to run an application developed using Visual Basic, the computer on which the application will be run must be installed with the Visual Basic runtime. The Visual Basic runtime can run only the applications developed with Visual Basic and not the ones developed with any other programming language like Java.

In the .NET Framework, all the Microsoft .NET languages use a common language runtime, which solves the problem of installing separate runtime for each of the programming languages. Microsoft .NET Common Language Runtime installed on a computer can run any language that is Microsoft .NET compatible.

The main advantage of the .NET Framework is the interoperability between different languages. As all the Microsoft .NET languages share the same common runtime language, they all work well together. For example, you can use an object written in C# from Visual Basic.NET. The same applies for all the other Microsoft .NET languages.

When you compile a Microsoft.NET language, the complier generates code written in the Microsoft Intermediate Language (MSIL). MSIL is a set of instructions that can quickly be translated into native code.

A Microsoft.NET application can be run only after the MSIL code is translated into native machine code. In .NET Framework, the intermediate language is complied "just in time" (JIT) into native code when the application or component is run instead of compiling the application at development time. The Microsoft.NET runtime consists of two JIT compilers. They are standard JIT compiler and the EconoJIT compiler. The EconoJIT compiler compiles faster than the standard JIT compiler, but the code it produces is not as optimized as the code obtained from the standard JIT compiler.

Understanding Globalization in .NET

Globalization refers to the process with which an application or software will be designed and developed so as to make it run across all platforms and all sites with minimum or no modification to the software application. The software is very amenable to customisation so as to suit to the location-specific conditions and it is also capable of providing information based on the varied inputs and the location-specific operating system.


Under any normal circumstance, there will be two processes in Globalization and they are customisation or localisation of the application and internationalizing the application codes so as to meet the standards of the local culture and other related matters.

In internationalization process the application code base will be same and the efforts will be on jobs such as translating, storing, retrieving and to make the application user friendly for the selected locale. In any given place the culture and the language will always be different and besides this you should also take into account the other factors such as time zone, normal date pattern usage, cultural and language environments, currencies, telephone numbers, and so many other factors that are specific to the locale.

In globalization the process of internationalization enables you to remove from the code base and the presentation layer all the contents and make you to use only a single presentation layer and single code base with a common contents that can suit any culture. The internationalization process will aid you to keep all the contents in a common place with an idea of making it easily accessible by the programme codes and the results can easily be populated all over presentation layer and the application with ease and efficiently.

In addition to the above, the internationalization process also enables you to store the contents and all the collected inputs from the user in a user friendly format and in a highly secured manner without compromising any standards pertaining to the local culture. The internationalization process is one step before any attempt for localising the application to suit to the local needs.

With the help of the localization process of globalization, you can make your application adaptable to the various location specific conditions and it will be easy for you to translate and re-format your application to suit to your new location and that too without changing any of the codes. Further, you can make use of the process for rectifying any of the reported bugs and for fine tuning the application for running smoothly without any hitch.

The globalization process also makes use of the locally prevailing information on culture where the software or the application is to be installed and maintained. The locational details and the language used in that particular area constitute to culture information and for working with any culture based information the namespace concept is utilised and the SystemGlobalization, SystemResources and SystemThreading are the available namespaces in .NET Framework.

Out of the various namespaces, the SystemGlobalization namespace constitute classes that are used to hold information relating to region or country, the local language used, type of calendars, date format used, numbers, currency, etc., all in a meticulously arranged fashion and all these classes are used while developing the globalized (internationalized) applications.

You can use advanced globalization functionalities with the assistance of classes such as StringInfo and TextInfo classes and the various functionalities include text element processing and surrogate support systems.

The SystemResources namespace constitutes interfaces and classes that are very helpful for developers and maintenance experts in creating, storing, retrieving, and managing various resources used in the application that are culture and location-specific.

The SystemThreading namespace constitutes interfaces and classes that aid in multithreaded programming. The classes that are used in this type of SystemThreading namespace are also useful in accessing data and for synchronization of thread activities.