In general, two approaches to Authorization are possible for ASP.NET applications.

First is role based, users are grouped in application-defined roles. Members of a particular role share same privileges within the application. Access to operations is authorized based on the role-membership of the caller. Resources are accessed using fixed identities (such as Web application’s or Web service’s process identity).

The second approach is resource based. Individual resources are secured using Windows Access Control Lists (ACL). The ACL determines which users are allowed to access a particular resource and also the types of operations the user can perform with that resource. In this case, resources are accessed using original caller’s identity.

.NET Web applications typically use one of the following two security models for resource access.

a) Trusted subsystem model
b) Impersonation/delegation model


Under the Trusted subsystem model, the middle tier service uses a fixed identity to access downstream services and resources. The security context of the original caller does not flow through the service at the OS level, although the application may choose to flow the original caller’s identity at the application level. (Why? It may need to do so in order to support back end auditing requirements or to support per-user data access and authorization). The downstream service “trusts” the upstream service to authorize callers.

Under the Impersonation/delegation model, a service or component (usually somewhere within the logical business services layer) impersonates the client’s identity (using OS-level impersonation) before it accesses a downstream service. If the next service in line is in the same computer, impersonation is sufficient. Delegation is required if the downstream service is located on a remote computer. As a result of delegation, the security context used for the downstream resource access is that of the client.

There are two common ways to scale your application to handle more number of users, more data volume or a combination of both.
Scaling up is one of the two methods under which you increase the capability of a server by adding more hardware, such as more memory, more processor power, more network ports, etc. It does not add additional maintenance and support costs. Beyond a certain threshold, adding more hardware to existing servers may not produce desired results. For an application to scale up, the underlying framework, runtime and computer architecture must scale up as well. When scaling up, consider which resources the application is bound by. For instance, if your application uses sizeable chunk of available memory in the server, increasing memory might help. On the contrary, if your application, on an average uses only 20-30% of the CPU, adding more processor power would not help in scaling up because the problem is elsewhere.

The other way to scale an application is scaling out. Under this option, you would add more servers and use load balancing or clustering solutions. Unlike the scaling up option discussed above, adding more servers can also help in improving availability since there are alternate servers that can be used for running the application in case one server fails. However, adding more servers and implementing load balancing and/or clustering solutions may involve additional maintenance and support costs.

ASP.Net 2.0 replaces the good old classic DataGrid control with the GridView control. Do you remember what all steps you used to take care of to allow the pagination in the data grid? ASP.NET 2.0 makes it simpler with the Grid View control.
This control is much like the DataGrid server control, but the GridView server control (besides offering many other new features) contains the built-in capability to apply paging, sorting, and editing of data with relatively little work on your part.
Following is a code snippet using the GridView control. This code builds a table from the Customers table in the Northwind with paging features.

<%@ Page Language=”VB” %>
<%@ Page Language=”VB” %>
<html>
<head runat=”server”>
<title>GridView Demo</title>
</head>
<body>
<form runat=”server”>
<asp:GridView ID=”GridView1” Runat=”server” AllowPaging=”True”
DataSourceId=”Sqldatasource1” />
<asp:SqlDataSource ID=”SqlDataSource1” Runat=”server”
SelectCommand=”Select * From Customers”
ProviderName=”System.Data.OleDb”
ConnectionString=”Provider=SQLOLEDB;Server=localhost;uid=sa;
pwd=password;database=Northwind” />
</form>
</body>
</html>

That’s all you have to do! Paging is enabled by setting the server control attribute AllowPaging of the GridView control:

<asp:GridView ID=”GridView1” Runat=”server” AllowPaging=”True”
DataSourceId=”SqlDataSource1” />

If you might have noticed all the processing of the above code is not included in runat=”server”. This means
We don’t need to write any server-side code to make this all work! Only some server controls needs to be included:
one control to get the data and one control to display the data.

Visit this msdn link for much more about GridView control
http://msdn.microsoft.com/msdnmag/issues/04/08/GridView/

You can follow the guidelines listed below for ensuring that your application is Secure By Design.



· When you application stores or transmits data that attackers want, use Cryptography. You can implement encryption yourself or require your end users to use platform encryption features such as Encrypting File System (EFS), Secure Sockets Layer (SSL) or IP Security (IPSec).

o Sample scenarios are when storing or transmitting personal information about people, financial information or authentication credentials.

· Use Authentication and authorization mechanisms built into the .NET framework

· Use Standard network protocols for network communications when possible. This is to improve compatibility with firewalls, since typically firewalls are configured to analyze network traffic and drop all packets that are not specifically allowed.

· Implement the principle of least privilege. Design and implement your applications so that they use the least privileges necessary to carry out any action. A simple example is when connecting to a database for data access. Instead of connecting with credential with very high permissions, determine what permissions your application requires, create a role that has permissions and use a credential appropriate to that specific role.

· Follow known techniques for reducing the attack surface. In other words, minimize the entry points to your application.

Some of you might have heard about SQL Injection attacks. SQL Injection attacks insert database commands into user input to modify commands sent from an application to a back-end database. Applications that employ user input in SQL queries can be vulnerable to SQL injection attacks.

Sample:
Consider the following simplified C# source code, intended to determine whether an order number (stored in the variable Id and provided by the user) has shipped:

Sql.Open();
sqlString = “SELECT HasShipped FROM Orders WHERE OrderId = ‘“ + Id + “’”;
SqlCommand cmd = new SqlCommand(sqlString, Sql);
if ((int) cmd.ExecuteScalar() != 0) {
Status = “Yes”;
else
Status = “No”;

Legitimate users will submit an Order Id such as “123” and the code set the Status variable to Yes or No if the HasShipped value in the row with that ID number is true. However, a malicious attacker could submit a value such as “1234’ drop table customers—“. The preceding C# code would then construct the SQL query as

SELECT HasShipped FROM Orders WHERE OrderId = ‘1234’

drop table customers

Assuming the table named customers exist and the application had the right to drop tables, the table would be lost.

When databases grow large, it is ideal to identify tables containing high volume of data and split them into multiple smaller sets of tables. This approach is called partitioning. Performance and manageability are the primary benefits.

Partitioning can be done in one of the two ways, viz, horizontal and vertical.

Horizontal partitioning involves creating logical groups of data within a table based on one or more columns. Values stored in a horizontal partitioning column help create mutually exclusive sets of data. An example is a table containing order data based on region. Orders pertaining to a region could form one set. Likewise, orders pertaining to a different region could form a different set.

Vertical partitioning, on the other hand, is the process of splitting columns into multiple tables. For example, if a table contains 50 columns, some of the 50 columns could be in one partitioned table, the remainder of the columns could be in another partitioned table.


Typically, in OLAP databases, it is common to adopt horizontal partitioning to store table data in multiple tables. Both SQL Server 2000 and SQL Server 2005 support partitioning. However, the way SQL Server internally implements partitioning has been greatly enhanced in SQL 2005.



An excellent article on SQL Server table partitioning is available here.

Did you know that it is possible to debug a stored procedure by tracing down the execution steps from managed code? If your answer is no, here is what you need.

1. Open a Windows application or ASP.NET project where you are invoking a stored procedure.
2. Set a breakpoint in the step preceding the SQL call.
3. Open Server explorer, drill down to the stored procedure that you want to debug, open it and set a breakpoint in the first executable statement.
4. Go to Project’s property pages (by right-clicking on the project name in Solution Explorer), navigate to Start Options category and select SQL Server debugger.
5. Run the project in debug mode.
6. When the breakpoint in managed code is reached, step through (F11) the subsequent steps. The IDE would automatically lead you to the stored procedure breakpoint.

If you find any difficulty in doing the above steps, please stop by my desk for a short demo. You can also refer to the Microsoft Support article mentioned below.

http://support.microsoft.com/kb/316549

Note: The login that you are using needs to be in sysadmin role in SQL Server.

Performance considerations have a major impact on user acceptance of an application. In view of the same, measurement of performance is critical to any application. If and when there is a performance problem reported by an end user, a process needs to be followed to diagnose and troubleshoot the problem. Though this process differs from company to company and from developer to developer, troubleshooting a performance problem must involve a step for measuring current performance. .NET framework provides a set of classes, such as PerformanceCounterCategory, PerformanceCounter, CounterCreationData, in System.Diagnostics namespace to facilitate the measurement process. The purpose of PerformanceCounterCategory class is to manage and manipulate PerformanceCounter objects and their categories. The PerformanceCounter class represents a metric that you want to capture from your application.