Designing a Security Strategy

Designing robust and impenetrable strategy for your portal is one of the most important and often overlooked design goals. While no one can predict all possible attacks and security risks for your site, the security options are well understood and rather straightforward to implement.

There is a widespread misconception that establishing solid security is extremely complicated. This idea stems from the fact that many security requirements are fairly new, and there is a certain latency in the way designers and developers accept and act upon changing requirements. Very often security is treated as an add-on feature of an application, to be applied after core functionality is in place. This approach is very dangerous and leads to potential security holes or delivery slides when your business logic has to be uprooted to incorporate security features.

By carefully choosing appropriate security options on the physical and application levels, you can mitigate almost all security risks. The security features of the .NET Framework combined with the security features of IIS, SQL Server, and other backend products provide many desirable security characteristics out of the box. Every time you plan the security strategy for a site, you should answer these key questions:

• What is the application scope?

• Where does authentication occur?

• What mechanism provides authentication implementation?

• How and where are authorization rules stored and how are they applied?

• What resources should be protected?

• How do user identities relate to protected resources?

Determining Application Scope

Most applications have a well-defined scope and are deployed and used on the Internet or on an extranet or intranet. Internet scenarios assume a wide and disparate user base. Typically you cannot make any assumptions concerning the type of browser or operating system that your users have installed.

In an intranet or extranet scenario, you typically have greater control over your user base and the types of operating systems installed on both client computers and servers. In this scenario, browsers and transport channels are known and well defined. The tighter administrative control over the environment allows you to reduce development costs by relying on out-of-the-box security features.

Selecting Authentication Implementation

Your goal should be to select the most secure authentication possible for a given scenario. Windows authentication using Windows users is very secure but requires a domain account for each user of your system. A lot of work is done for you if you choose this authentication mechanism because Windows manages credentials automatically.

If you choose to identify and manage credentials outside of Windows, you can use a custom security implementation using SQL Server or choose to use the personalization and user management features of Commerce Server.

It's important to evaluate the types of browsers used by your clients. Some authentication features are available only for clients using Internet Explorer. If you need to support Internet users, you should steer clear of relying on the browser-specific security techniques.

After resolving these issues, consider where the authentication will occur. Based on the degree to which you want to use impersonation and flow user credentials into the lower levels of the system, you can choose one or a combination of several authentication methods . If you need to have access to user credentials at the level of method execution, you should turn impersonation and .NET authentication on so user context flows downstream.

Authorization, Resources Protection, and Identities

You have to have a clear idea concerning which resources you want to secure and the desired protection granularity. By using impersonation and flowing each user identity down, you can have different permission sets for different users. On the other hand, you can use the same identity to access all resources: By default, it is the ASPNET account, though you can specify your own account instead of this account.

If you choose to use impersonation, you will have caller identity at your fingertips at all times. You can use Windows access control lists (ACLs) to specify various levels of access for each of the users to each protected resource. On the other hand, you can define a set of application roles. As a part of your authentication process, users will be mapped to a particular role. This role membership determines the types of operations a user can perform and the code access resources using the same trusted account and therefore is referred to as a trusted model.

In some cases these two modes can be mixed: You can protect access to files stored on your server using ACLs and protect database access using roles. Generally, you would choose the trusted model over the impersonation model because the former is usually easier to implement and naturally results in higher performance. The impersonation model might be required if you need extremely granular access and to allow users to access resources directly.

Selecting Types of Roles to Use

If you have ever worked with SQL Server or COM+, you know that both of these products let you define roles and group various entities into roles. While you can use both COM+ and/or SQL Server roles in your portal implementation, a discussion of these options is beyond the scope of this book. .NET roles are a new and very powerful concept and deserve a brief overview.

If you select Windows authentication, .NET automatically creates a WindowsPrincipal object representing the .NET role. You use WindowsPrincipal in your code to gain access to a protected resource. .NET principals are flexible and let you protect both "physical" resources such as files and also code. If you have ever dealt with authentication and authorization issues using previous versions of Microsoft development tools (such as Visual C++ 6.0 and earlier), you will appreciate the tremendous amount of work the framework objects do for you out of the box.

The code snippet in Listing 6.2 shows how easily .NET roles can be used to authorize resource access. Let's assume that we have turned on both Windows authentication and impersonation. We have to make sure that only the users Bob and Alice can access our protected resource. The user must belong to the Manager role to be able to modify the resource or to the User role to be able to view it.

Listing 6.2. Using the WindowsPrincipal Object to Authorize Resource Access

 Imports System.Threading Imports System.Security ...  '  get principal object from the current thread Dim CurrentPrincipal As Principal.IPrincipal = Thread.CurrentPrincipal  If CurrentPrincipal.Identity.Name <> "Alice" And _  CurrentPrincipal.Identity.Name <> "Bob" Then   ' only Alice or Bob can access this resource    Throw New SecurityException(String.Format("User {0} cannot access _    protected resource", _                         CurrentPrincipal.Identity.Name))  End If  If CurrentPrincipal.IsInRole("Manager") Then    ReturnModifyableResource()  ElseIf CurrentPrincipal.IsInRole("User") Then   ReturnReadOnlyResource()  Else   Throw New SecurityException(String.Format("User {0} cannot access _   protected resource", _                         CurrentPrincipal.Identity.Name))  End If 

There are many different scenarios describing the best approach for designing the optimal security strategy based on a combination of the various factors described in this section. To review these options, consider using Microsoft's Building Secure ASP.NET Applications Guide . This bible- sized manual carefully explores various permutations of factors and suggests an ideal solution for each situation. To get this guide, go to MSDN at msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp?frame=true&_r=1.