.NET Web Services and Security

By Juval Lowy

When you use .NET to build a Web service, you rely on the built-in security support in ASP.NET and Internet Information Services (IIS). While this support makes developing secure ASP.NET Web Forms a breeze, it may require some work to develop and consume secure Web services. The problem is that ASP.NET and IIS security assumes there is a user on the other side of the wire, and that the user can type a user name and password into a dialog. Of course, with Web services there is no user involved, because Web services connect a client (an object) to a remote object (the Web service). This means that client-side developers have to provide your Web service with security credentials either explicitly or implicitly. .NET offers two security options to Web service developers: rely on Windows security or provide custom authentication. This article describes these two options and their different flavors and provides a side-by-side comparison of the security techniques.

Windows-Based Security

Using Windows-based security requires that the calling client application provide the credentials of an account on the server (or on the domain server). As a result, Windows security is most appropriate for intranet applications that use Web services to interact across a well-administered corporate network. This is because typically you have relatively fewer clients in an intranet application than in an Internet application. However, if managing a large number

Understanding Object Lifetime

.NET objects are allocated in a memory called managed heap, where they will be automatically destroyed by the garbage collector.

Before going into details you have to know about the class, object, reference, stack and heap.

A class is nothing but a blueprint that describes how an instance of this type will look and feel in memory. Classes, of course, are defined within a code file (which in C# takes a *.cs extension).

Consider a simple Car class defined in a C# Console Application project named SimpleGC:

    //Car.cs
    public class Car
    {
        private int currSp;
        private string petName;
        public Car() { }
        public Car(string name, int speed)
        {
            petName = name;
            currSp = speed;
        }

        public override string ToString()
        {
            return string.Format("{0} is going {1} MPH",
            petName, currSp);
        }
    }

Once a class is defined, you can allocate any number of objects using the C# new keyword.

Understand, that the new keyword returns a reference to the

Beginner's Guide: How IIS Process ASP.NET Request

Introduction

When request come from client to the server a lot of operation is performed before sending response to the client. This is all about how IIS Process the request.  Here I am not going to describe the Page Life Cycle and there events, this article is all about the operation of IIS Level.  Before we start with the actual details, let’s start from the beginning so that each and every one understand it's details easily. 

What is Web Server ?

When we run our ASP.NET Web Application from visual studio IDE, VS Integrated ASP.NET Engine is responsible to execute all kind of asp.net requests and responses.  The process name is "WebDev.WebServer.Exe" which actually take care of all request and response of an web application which is running from Visual Studio IDE.

Now, the name “Web Server” come into picture when we want to host the application on a centralized location and wanted to access from many locations. Web server is responsible for handle all the requests that are coming from clients, process them and provide the responses.

What is IIS ?

IIS (Internet Information Server) is one of the most powerful web servers from Microsoft that is used to host your ASP.NET Web application. IIS has it's own ASP.NET Process Engine  to handle the ASP.NET request. So, when a request comes from client to server, IIS takes that request and  process it and send response back to clients

Behind the Scenes - Discover the Design Patterns You're Already Using in the .NET Framework

By Rob Pierry

Contents

• Observer Pattern
• Iterator Pattern
• Decorator Pattern
• Adapter Pattern
• Factory Pattern
• Strategy Pattern
• Composite Pattern in ASP.NET
• Template Method Pattern
• Patterns in the ASP.NET Pipeline
• Intercepting Filter Pattern
• Page Controller Pattern
• Other Web Presentation Patterns in ASP.NET

In this article, I'll cover a basic overview of several common design patterns and how they are used in the BCL and other areas of the .NET Framework. In doing so, you can discover some of the motivation for why the Framework is designed the way it is, as well as make the abstract concepts of the patterns themselves more intuitively understandable.

If you are already familiar with some of these patterns, feel free to read about those you aren't familiar with, since each section is relatively independent. The section on ASP.NET-related patterns requires familiarity with the request pipeline, a basic overview of which is provided in that section.

Within the .NET Framework, the use of some patterns is so prevalent that they have been built into programming languages themselves, instead of just represented by the class libraries. The first two patterns I will discuss, the Observer and the Iterator, are supported

I will not bore you about "why caching is so great"; it is assumed you already understand, at least in theory, what caching can buy you as an ASP.NET developer.

At a minimum a developer wants to be able to cache some (or possibly all) of the pages in her ASP.NET Application. The simplest way to achieve this is to add the @ OutputCache directive to the top of the .aspx file of each page:

<%@ OutputCache Duration="5" VaryByParam="none" %>

Now, that was easy, wasn't it? But - exactly what does it do? You are specifying how long the page is to be retained in the Cache with the Duration attribute, in seconds. In the above example, this page will be rendered on the first request for it, and stored in Cache. For five seconds, all subsequent requests for this page will be served from the Cache, which is hugely faster than having to go through the entire Page lifecycle, possibly combined with database access, re-render and finally serve the page HTML to the client. After five seconds, the page will again be rendered (and once again, stored in the Cache).

The VaryByParam attribute is used to define parameters that determine which cached copy of a page should be sent to the browser. If your page doesn't change, you can set this to "none".

Caching Pages Based on QueryString items

If the contents of one of your pages can vary based on the value of certain items on the querystring, which is a common technique in ASP.NET, you can populate the VaryByParam attribute with a semicolon-delimited