Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

  • Article
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

 

patterns & practices Developer Center

Security Model for ASP.NET Applications

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation

Published: November 2002

Last Revised: January 2006

Applies to:

  • ASP.NET 1.1
  • .NET Framework 1.1

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Building Secure ASP.NET Applications.

Summary: This chapter describes the common characteristics of .NET Web applications from a security perspective and introduces the .NET Web application security model. It also introduces the set of core implementation technologies that you will use to build secure .NET Web applications. (16 printed pages)

Contents

.NET Web Applications
Implementation Technologies
Security Architecture
Identities and Principals
Summary

This chapter introduces .NET Web application security. It provides an overview of the security features and services that span the tiers of a typical .NET Web application.

The goal of the chapter is to:

  • Provide a frame of reference for typical .NET Web applications
  • Identify the authentication, authorization and secure communication security features provided by the various implementation technologies used to build .NET Web applications
  • Identify gatekeepers and gates that can be used in your application to enforce trust boundaries

.NET Web Applications

This section provides a brief introduction to .NET Web applications and describes their characteristics both from a logical and physical viewpoint. It also provides an introduction to the various implementation technologies used to build .NET Web applications.

Logical Tiers

Logical application architecture views any system as a set of cooperating services grouped in the following layers:

  • User Services
  • Business Services
  • Data Services

The value of this logical architecture view is to identify the generic types of services invariably present in any system, to ensure proper segmentation and to drive the definition of interfaces between tiers. This segmentation allows you to make more discreet architecture and design choices when implementing each layer, and to build a more maintainable application.

The layers can be described as follows:

  • UserServices are responsible for the client interaction with the system and provide a common bridge into the core business logic encapsulated by components within the Business Services layer. Traditionally, User Services are associated most often with interactive users. However, they also perform the initial processing of programmatic requests from other systems, where no visible user interface is involved. Authentication and authorization, the precise nature of which varies depending upon the client type, are typically performed within the User Services layer.
  • Business Services provide the core functionality of the system and encapsulate business logic. They are independent from the delivery channel and back-end systems or data sources. This provides the stability and flexibility necessary to evolve the system to support new and different channels and back-end systems. Typically, to service a particular business request involves a number of cooperating components within the Business Services layer.
  • Data Services provide access to data (hosted within the boundaries of the system), and to other (back-end) systems through generic interfaces, which are convenient to use from components within the Business Services layer. Data Services abstract the multitude of back-end systems and data sources, and encapsulate specific access rules and data formats.

The logical classification of service types within a system may correlate with, but is relatively independent from, the possible physical distribution of the components implementing the services.

It is also important to remember that the logical tiers can be identified at any level of aggregation; that is, the tiers can be identified for the system as a whole (in the context of its environment and external interactions) and for any contained subsystem. For example, each remote node that hosts a Web service consists of User Services (handling incoming requests and messages), Business Services and Data Services.

Physical Deployment Models

The three logical service layers described earlier, in no way imply specific numbers of physical tiers. All three logical services may be physically located on the same computer, or they may be spread across multiple computers.

The Web server as an application server

A common deployment pattern for .NET Web applications is to locate business and data access components on the Web server. This minimizes the network hops, which can help performance. This model is shown in Figure 2.1.

Ff649358.f02sn01(en-us,PandP.10).gif

Figure 2.1. The Web server as an application server

Remote application tier

The remote application tier is a common deployment pattern, particularly for Internet scenarios where the Web tier is self-contained within a perimeter network (also known as DMZ, demilitarized zone, and screened subnet) and is separated from end users and the remote application tier with packet filtering firewalls. The remote application tier is shown in Figure 2.2.

Ff649358.f02sn02(en-us,PandP.10).gif

Figure 2.2. The introduction of a remote application tier

Implementation Technologies

.NET Web applications typically implement one or more of the logical services by using the following technologies:

  • ASP.NET
  • Enterprise Services
  • Web services
  • .NET Remoting
  • ADO.NET and Microsoft® SQL Server™
  • Internet Protocol Security (IPSec)
  • Secure Sockets Layer (SSL)

ASP.NET

ASP.NET is typically used to implement User Services. ASP.NET provides a pluggable architecture that can be used to build Web pages. For more information about ASP.NET, see the following resources:

Enterprise Services

Enterprise Services provide infrastructure-level services to applications. These include distributed transactions and resource management services such as object pooling for .NET components. For more information about Enterprise Services, see the following resources:

Web Services

Web services enable the exchange of data and the remote invocation of application logic using SOAP-based message exchanges to move data through firewalls and between heterogeneous systems. For more information about Web services, see the following resources:

.NET Remoting

.NET Remoting provides a framework for accessing distributed objects across process and machine boundaries. For more information about .NET Remoting, see the following resources:

ADO.NET and SQL Server

ADO.NET provides data access services. It is designed from the ground up for distributed Web applications, and it has rich support for the disconnected scenarios inherently associated with Web applications. For more information about ADO.NET, see the following resources:

SQL Server provides integrated security that uses the operating system authentication mechanisms (Kerberos or NTLM). Authorization is provided by logons and granular permissions that can be applied to individual database objects. For more information about SQL Server, see the following resources:

Internet Protocol Security (IPSec)

IPSec provides point-to-point, transport-level encryption and authentication services. If you want to protect all IP traffic between the Web server and the database server, use IPSec. You can also use IPSec to restrict communications between specific computers. For more information about IPSec, see Chapter 4, Secure Communication.

Secure Sockets Layer (SSL)

  • SSL provides a point-to-point secure communication channel. Data sent over the channel is encrypted. Use SSL when you need channel protection for a particular application instead of protection for all applications and services running on a computer. For more information about SSL, see Chapter 4, Secure Communication.

Security Architecture

Figure 2.3 shows the remote application tier model together with the set of security services provided by the various technologies introduced earlier. Authentication and authorization occurs at many individual points throughout the tiers. These services are provided primarily by Internet Information Services (IIS), ASP.NET, Enterprise Services and SQL Server. Secure communication channels are also applied throughout the tiers and stretch from the client browser or device, right through to the database. Channels are secured with a combination of Secure Sockets Layer (SSL) or IPSec.

Ff649358.f02sn03(en-us,PandP.10).gif

Figure 2.3. Security architecture

Security Across the Tiers

The authentication, authorization, and secure communication features provided by the technologies discussed earlier are summarized in Table 2.1.

Table 2.1. Security features

Technology Authentication Authorization Secure Communication
IIS Anonymous
Basic
Digest
Windows Integrated (Kerberos/NTLM)
Passport
Certificate		 IP/DNS Address Restrictions
Web Permissions
NTFS Permissions; Windows Access Control Lists (ACLs) on requested files		 SSL
ASP.NET None (Custom)
Windows
Forms
Passport		 File Authorization
URL Authorization
Principal Permissions
.NET Roles		  
Web services Windows
None (Custom)
Message level authentication		 File Authorization
URL Authorization
Principal Permissions
.NET Roles		 SSL and Message level encryption
Remoting Windows File Authorization
URL Authorization
Principal Permissions
.NET Roles		 SSL and message level encryption
Enterprise Services Windows Enterprise Services (COM+) Roles
NTFS Permissions		 Remote Procedure Call (RPC) Encryption
SQL Server Windows (Kerberos/NTLM)
SQL authentication		 Server logins
Database logins
Fixed database roles
User defined roles
Application roles
Object permissions		 SSL
Windows Kerberos
NTLM		 Windows ACLs IPSec

Authentication

The .NET Framework on Windows provides the following authentication options:

  • ASP.NET Authentication Modes
  • Enterprise Services Authentication
  • SQL Server Authentication

ASP.NET authentication modes

ASP.NET authentication modes include Windows, Forms, Passport and None.

  • Windows authentication. With this authentication mode, ASP.NET relies on IIS to authenticate users and create a Windows access token to represent the authenticated identity. IIS provides the following authentication mechanisms:

    • Basic authentication. Basic authentication requires the user to supply credentials in the form of a user name and password to prove their identity. It is a proposed Internet standard based on RFC 2617. Both Netscape Navigator and Microsoft Internet Explorer support Basic authentication. The user's credentials are transmitted from the browser to the Web server in an unencrypted Base64 encoded format. Because the Web server obtains the user's credentials unencrypted, the Web server can issue remote calls (for example, to access remote computers and resources) using the user's credentials.

      Note   Basic authentication should only be used in conjunction with a secure channel (typically established by using SSL). Otherwise, user names and passwords can be easily stolen with network monitoring software. If you use Basic authentication you should use SSL on all pages (not just a logon page), because credentials are passed on all subsequent requests. For more information about using Basic authentication with SSL, see Chapter 8, "ASP.NET Security."

    • Digest authentication. Digest authentication, introduced with IIS 5.0, is similar to Basic authentication except that instead of transmitting the user's credentials unencrypted from the browser to the Web server, it transmits a hash of the credentials. As a result it is more secure, although it requires an Internet Explorer 5.0 or later client and specific server configuration. Digest authentication also has disadvantages; for example, passwords need to be stored in reversible encrypted format, which exposes a security vulnerability.

    • Integrated Windows authentication. Integrated Windows Authentication (Kerberos or NTLM depending upon the client and server configuration) uses a cryptographic exchange with the user's Internet Explorer Web browser to confirm the identity of the user. It is supported only by Internet Explorer (and not by Netscape Navigator), and as a result tends to be used only in intranet scenarios, where the client software can be controlled. It is used only by the Web server if either anonymous access is disabled or if anonymous access is denied through Windows file system permissions.

    • Certificate authentication. Certificate authentication uses client certificates to positively identify users. The client certificate is passed by the user's browser (or client application) to the Web server. (In the case of Web services, the Web services client passes the certificate by means of the ClientCertificates property of the HttpWebRequest object). The Web server then extracts the user's identity from the certificate. This approach relies on a client certificate being installed on the user's computer and as a result tends to be used mostly in intranet or extranet scenarios where the user population is well known and controlled. IIS, upon receipt of a client certificate, can map the certificate to a Windows account.

    • Anonymous authentication. If you do not need to authenticate your clients (or you implement a custom authentication scheme), IIS can be configured for Anonymous authentication. In this event, the Web server creates a Windows access token to represent all anonymous users with the same anonymous (or guest) account. The default anonymous account is IUSR_MACHINENAME, where MACHINENAME is the NetBIOS name of your computer specified at install time.

  • Passport authentication. With this authentication mode, ASP.NET uses the centralized authentication services of Microsoft Passport. ASP.NET provides a convenient wrapper around functionality exposed by the Microsoft Passport Software Development Kit (SDK), which must be installed on the Web server.

  • Forms authentication. This approach uses client-side redirection to forward unauthenticated users to a specified HTML form that allows them to enter their credentials (typically user name and password). These credentials are then validated and an authentication ticket is generated and returned to the client. The authentication ticket maintains the user identity and optionally a list of roles that the user is a member of for the duration of the user's session.

    Note   Forms authentication sends the user name and password to the Web server in plain text. As a result, you should use Forms authentication in conjunction with a channel secured by SSL. For continued protection of the authentication cookie transmitted on subsequent requests, you should consider using SSL for all pages within your application and not just the logon page.

  • None. None indicates that you either don't want to authenticate users or that you are using a custom authentication protocol.

More information

For more details about ASP.NET authentication, see Chapter 8, ASP.NET Security.

Enterprise Services authentication

Enterprise Services authentication is performed by using the underlying Remote Procedure Call (RPC) transport infrastructure, which in turn uses the operating system Security Service Provider Interface (SSPI). Clients of Enterprise Services applications may be authenticated using Kerberos or NTLM authentication.

A serviced component can be hosted in a Library application or Server application. Library applications are hosted within client processes and as a result assume the client's identity. Server applications run in separate server processes under their own identity. For more information about identity, see the "Identities and Principals" section later in this chapter.

The incoming calls to a serviced component can be authenticated at the following levels:

  • Default: The default authentication level for the security package is used.
  • None: No authentication occurs.
  • Connect: Authentication occurs only when the connection is made.
  • Call: Authenticates at the start of each remote procedure call.
  • Packet: Authenticates and verifies that all call data is received.
  • Packet Integrity: Authenticates and verifies that none of the data has been modified in transit.
  • Packet Privacy: Authenticates and encrypts the packet, including the data and the sender's identity and signature.

More information

For more information about Enterprise Services authentication, see Chapter 9, Enterprise Services Security.

SQL Server authentication

SQL Server can authenticate users by using Windows authentication (NTLM or Kerberos) or can use its own built-in authentication scheme referred to as SQL authentication. The following two options are available:

  • SQL Server and Windows. Clients can connect to an instance of Microsoft SQL Server by using either SQL Server authentication or Windows authentication. This is sometimes referred to as mixed mode authentication.
  • Windows Only. The user must connect to the instance of Microsoft SQL Server by using Windows authentication.

More information

The relative merits of each approach are discussed in Chapter 12, "Data Access Security."

Authorization

The .NET Framework on Windows provides of the following authorization options:

  • ASP.NET Authorization Options
  • Enterprise Services Authorization
  • SQL Server Authorization

ASP.NET authorization options

ASP.NET authorization options can be used by ASP.NET Web applications, Web services and remote components. ASP.NET provides the following authorization options:

  • URL Authorization. This is an authorization mechanism, configured by settings within machine-level and application configuration files. URL Authorization allows you to restrict access to specific files and folders within your application's Uniform Resource Identifier (URI) namespace. For example, you can selectively deny or allow access to specific files or folders (addressed by means of a URL) to nominated users. You can also restrict access based on the user's role membership and the type of HTTP verb used to issue a request (GET, POST, and so on).

    URL Authorization requires an authenticated identity. This can be obtained by a Windows or ticket-based authentication scheme.

  • File Authorization. File authorization applies only if you use one of the IIS-supplied Windows authentication mechanisms to authenticate callers and ASP.NET is configured for Windows authentication.

    You can use it to restrict access to specified files on a Web server. Access permissions are determined by Windows ACLs attached to the files.

  • Principal Permission Demands. Principal permission demands can be used (declaratively or programmatically) as an additional fine-grained access control mechanism. They allow you to control access to classes, methods or individual code blocks based on the identity and group membership of individual users.

  • NET Roles. .NET roles are used to group together users who have the same permissions within your application. They are conceptually similar to previous role-based implementations, for example Windows groups and COM+ roles. However, unlike these earlier approaches, .NET roles do not require authenticated Windows identities and can be used with ticket-based authentication schemes such as Forms authentication.

    .NET roles can be used to control access to resources and operations and they can be configured both declaratively and programmatically.

More information

For more information about ASP.NET authorization, see Chapter 8, ASP.NET Security.

Enterprise Services authorization

Access to functionality contained in serviced components within Enterprise Services applications is governed by Enterprise Services role membership. These are different from .NET roles and can contain Windows group or user accounts. Role membership is defined within the COM+ catalog and is administered by using the Component Services tool.

More information

For more information about Enterprise Services authorization, see Chapter 9, Enterprise Services Security.

SQL Server authorization

SQL Server allows fine-grained permissions that can be applied to individual database objects. Permissions may be based on role membership (SQL Server provides fixed database roles, user defined roles and application roles), or permission may be granted to individual Windows user or group accounts.

More information

For more information about SQL Server authorization, see Chapter 12, Data Access Security.

Gatekeepers and Gates

Throughout the remainder of this document, the term gatekeeper is used to identify the technology that is responsible for a gate. A gate represents an access control point (guarding a resource) within an application. For example, a resource might be an operation (represented by a method on an object) or a database or file system resource.

Each of the core technologies listed earlier provide gatekeepers for access authorization. Requests must pass through a series of gates before being allowed to access the requested resource or operation. The following describes the gates the requests must pass through:

  • IIS provides a gate when you authenticate users (that is, you disable Anonymous authentication). IIS Web permissions can be used as an access control mechanism to restrict the capabilities of Web users to access specific files and folders. Unlike NTFS file permissions, Web permissions apply to all Web users, as opposed to individual users or groups. NTFS file permissions provide further restrictions on Web resources such as Web pages, images files, and so on. These restrictions apply to individual users or groups.

    IIS checks Web permissions, followed by NTFS file permissions. A user must be authorized by both mechanisms for them to be able to access the file or folder. A failed Web permission check results in IIS returning an HTTP 403–Access Forbidden response, whereas a failed NTFS permission check results in IIS returning an HTTP 401–Access Denied.

  • ASP.NET provides various configurable and programmatic gates. These include URL Authorization, File Authorization, Principal Permission demands, and .NET Roles.

  • The Enterprise Services gatekeeper uses Enterprise Services roles to authorize access to business functionality.

  • SQL Server includes a series of gates that include server logins, database logins, and database object permissions.

  • Windows provides gates using ACLs attached to secure resources.

The bottom line is that gatekeepers perform authorization based on the identity of the user or service calling into the gate and attempting to access a specific resource. The value of multiple gates is in-depth security with multiple lines of defense. Table 2.2 summaries the set of gatekeepers and identifies for each one the gates that they are responsible for.

Table 2.2. Gatekeepers responsibilities and the gates they provide

Gatekeeper Gates
Windows Operating System Logon rights (positive and negative, for example "Deny logon locally")
Other privileges (for example "Act as part of the operating system")
Access checks against secured resources such as the registry and file system. Access checks use ACLs attached to the secure resources, which specify who is and who is not allowed to access the resource and also the types of operation that may be permitted.
TCP/IP filtering
IP Security
IIS Authentication (Anonymous, Basic, Digest, Integrated, Certificate)
IP address and domain name restrictions (these can be used as an additional line of defense, but should not be relied upon due to the relative ease of spoofing IP addresses).
Web permissions
NTFS permissions
ASP.NET URL Authorization
File Authorization
Principal Permission Demands
.NET Roles
Enterprise Services Windows (NTLM / Kerberos) authentication
Enterprise Services (COM+) roles
Impersonation levels
Web services Uses gates provided by IIS and ASP.NET
Remoting Uses gates provided by the host. If hosted in ASP.NET it uses the gates provided by IIS and ASP.NET. If hosted in a Windows service, then you must develop a custom solution.
ADO.NET Connection strings. Credentials may be explicit or you may use Windows authentication (for example, if you connect to SQL Server)
SQL Server Server logins
Database logins
Database object permissions

By using the various gates throughout the tiers of your application, you can filter out users that should be allowed access to your back-end resources. The scope of access is narrowed by successive gates that become more and more granular as the request proceeds through the application to the back-end resources.

Consider the Internet-based application example using IIS that is shown in Figure 2.4.

Ff649358.f02sn04(en-us,PandP.10).gif

Figure 2.4. Filtering users with gatekeepers

Figure 2.4 illustrates the following:

  • You can disable Anonymous authentication in IIS. As a result, only accounts that IIS is able to authenticate are allowed access. This might reduce the potential number of users to 10,000.
  • Next, in ASP.NET you use URL Authorization, which might reduce the user count to 1,000 users.
  • File authorization might further narrow access down to 100 users.
  • Finally, your Web application code might allow only 10 users to access your restricted resource, based on specific role membership.

Identities and Principals

.NET security is layered on top of Windows security. The user centric concept of Windows security is based on security context provided by a logon session while .NET security is based on IPrincipal and IIdentity objects.

In Windows programming when you want to know the security context code is running under, the identity of the process owner or currently executing thread is consulted. With .NET programming, if you want to query the security context of the current user, you retrieve the current IPrincipal object from Thread.CurrentPrincipal.

The .NET Framework uses identity and principal objects to represent users when .NET code is running and together they provide the backbone of .NET role-based authorization.

Identity and principal objects must implement the IIdentity and IPrincipal interfaces respectively. These interfaces are defined within the System.Security.Principal namespace. Common interfaces allow the .NET Framework to treat identity and principal objects in a polymorphic fashion, regardless of the underlying implementation details.

The IPrincipal interface allows you to test role membership through an IsInRole method and also provides access to an associated IIdentity object.

public interface IPrincipal
{
  bool IsInRole( string role );
  IIdentity Identity {get;}
}

The IIdentity interface provides additional authentication details such as the name and authentication type.

public interface IIdentity
{
  string authenticationType {get;}
  bool IsAuthenticated {get;}
  string Name {get;}
}

The .NET Framework supplies a number of concrete implementations of IPrincipal and IIdentity as shown in Figure 2.5 and described in the following sections.

Ff649358.f02sn05(en-us,PandP.10).gif

Figure 2.5. IPrincipal and IIdentity implementation classes

WindowsPrincipal and WindowsIdentity

The .NET version of a Windows security context is divided between two classes:

  • WindowsPrincipal. This class stores the roles associated with the current Windows user. The WindowsPrincipal implementation treats Windows groups as roles. The IPrncipal.IsInRole method returns true or false based on the user's Windows group membership.

  • WindowsIdentity. This class holds the identity part of the current user's security context and can be obtained from the static **WindowsIdentity.GetCurrent()**method. This returns a WindowsIdentity object that has a Token property that returns an IntPtr that represents a Windows handle to the access token associated with the current execution thread. This token can then be passed to native Win32® application programming interface (API) functions such as GetTokenInformation, SetTokenInformation, CheckTokenMembership and so on, to retrieve security information about the token.

    Note   The static **WindowsIdentity.GetCurrent()**method returns the identity of the currently executing thread, which may or may not be impersonating. This is similar to the Win32 GetUserName API.

GenericPrincipal and Associated Identity Objects

These implementations are very simple and are used by applications that do not use Windows authentication and where the application does not need complex representations of a principal. They can be created in code very easily and as a result a certain degree of trust must exist when an application deals with a GenericPrincipal.

If you are relying upon using the IsInRole method on the GenericPrincipal in order to make authorization decisions, you must trust the application that sends you the GenericPrincipal. This is in contrast to using WindowsPrincipal objects, where you must trust the operating system to provide a valid WindowsPrincipal object with an authenticated identity and valid group/role names.

The following types of identity object can be associated with the GenericPrincipal class:

  • FormsIdentity. This class represents an identity that has been authenticated with Forms authentication. It contains a FormsAuthenticationTicket, which contains information about the user's authentication session.
  • PassportIdentity. This class represents an identity that has been authenticated with Passport authentication and contains Passport profile information.
  • GenericIdentity. This class represents a logical user that is not tied to any particular operating system technology and is typically used in association with custom authentication and authorization mechanisms.

ASP.NET and HttpContext.User

ASP.NET provides the authenticated user's security context by using HttpContext.User.

This property accepts and returns an IPrincipal interface. The property contains an authenticated user for the current request. ASP.NET retrieves HttpContext.User when it makes authorization decisions.

When you use Windows authentication, the Windows authentication module automatically constructs a WindowsPrincipal object and stores it in HttpContext.User. If you use other authentication mechanisms such as Forms or Passport, you must construct a GenericPrincipal object and store it in HttpContext.User.

ASP.NET identities

At any given time during the execution of an ASP.NET Web application, there may be multiple identities present during a single request. These identities include:

  • HttpContext.User returns an IPrincipal object that contains security information for the current Web request. This is the authenticated Web client.
  • **WindowsIdentity.GetCurrent()**returns the identity of the security context of the currently executing Win32 thread. By default, this identity is ASPNET with IIS 5.0 on Windows Server 2000 and Network Service with IIS 6.0 on Windows Server 2003; the default account used to run ASP.NET Web applications. However, if the Web application has been configured for impersonation, the identity represents the authenticated user (which if IIS Anonymous authentication is in effect, is IUSR_MACHINE).
  • Thread.CurrentPrincipal returns the principal of the currently executing .NET thread, which rides on top of the Win32 thread.

More information

Remoting and Web Services

In the current version of the .NET Framework, Remoting and Web services do not have their own security model. They both inherit the security feature of IIS and ASP.NET.

Although there is no security built into the Remoting architecture, it was designed with security in mind. It is left up to the developer and/or administrator to incorporate certain levels of security in Remoting applications. Whether or not principal objects are passed across Remoting boundaries depends on the location of the client and remote object, for example:

  • Remoting within the same process. When remoting is used between objects in the same or separate application domain(s), the remoting infrastructure copies a reference to the IPrincipal object associated with the caller's context to the receiver's context.
  • Remoting across processes. In this case, IPrincipal objects are not transmitted between processes. The credentials used to construct the original IPrincipal must be transmitted to the remote process, which may be located on a separate computer. This allows the remote computer to construct an appropriate IPrincipal object based on the supplied credentials.

Summary

This chapter has introduced the full set of authentication and authorization options provided by the various .NET related technologies. By using multiple gatekeepers throughout your .NET Web application, you will be able to implement a defense-in-depth security strategy. To summarize:

  • ASP.NET applications can use the existing security features provided by Windows and IIS.
  • A combination of SSL and IPSec can be used to provide secure communications across the layers of a .NET Web application; for example, from browser to database.
  • Use SSL to protect the clear text credentials passed across the network when you use Basic or Forms authentication.
  • .NET represents users who have been identified with Windows authentication using a combination of the WindowsPrincipal and WindowsIdentity classes.
  • The GenericPrincipal and GenericIdentity or FormsIdentity classes are used to represent users who have been identified with non-Windows authentication schemes, such as Forms authentication.
  • You can create your own principal and identity implementations by creating classes that implement IPrincipal and IIdentity.
  • Within ASP.NET Web applications, the IPrincipal object that represents the authenticated user is associated with the current HTTP Web request using the HttpContext.User property.
  • Gates are access control points within your application through which authorized users can access resources or services. Gatekeepers are responsible for controlling access to gates.
  • Use multiple gatekeepers to provide a defense-in-depth strategy.

The next chapter, Chapter 3, Authentication and Authorization, provides additional information to help you choose the most appropriate authentication and authorization strategy for your particular application scenario.

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.