Asp. NET Application security Model

Asp.net| Security | Procedures Microsoft Corporation

In this section

A powerful ASP.net application relies on the successful interaction of many elements and technologies. The components of each solution provide security features that are designed to meet their needs. However, it is not enough to look at security from a single component point of view. To provide security for the overall solution, you must also consider how each component interacts with each other.

This section describes the architecture and security of. NET Web applications, and provides a framework for reference, and other chapters in this series complement other elements in this framework. This section summarizes the security features and services that exist at all levels of a typical. NET Web application. Also describes. NET Framework security, and explains which elements in this framework are most important to asp.net Web application developers.

Goal

This chapter is used to:

• Deep understanding of. NET WEB application Architecture and logical and physical application layer concepts.

• Understand what security features each implementation technology provides that can be used to build. NET Web applications and how they work together.

• Understand the. NET Framework security features and understand which elements are most important for WEB application security.

• Compare and contrast the authorization and authentication mechanisms available in the WEB application.

• Learn how to use principals and identity objects in. NET Web applications.

• Identify the gatekeeper and gateway that can be used in an application to implement a trust boundary.


Apply to:

This chapter applies to the following products and technologies:

Microsoft_ Windows_ XP or Windows Server and its future operating system

Internet Information Services (IIS)

.net Framework Version 1.0 and its future version


How to use this section

To gain more from this chapter:

• You must have development experience with ASP.net Web applications. This will help you understand where the various security elements discussed in this unit are combined with your application.

• Read the introduction to Building secure asp.net applications, which emphasizes the importance of authorization, authentication, and secure communications in creating secure, distributed Web applications. It also points out the main principles and practices used in developing secure Web applications.




Content of this page
. NET Web Applications
Implementation technology
Security architecture
Describes. NET Framework Security
Summary

. NET Web Applications
This section provides a brief introduction to. NET WEB applications and a logical and physical description of their characteristics. It also describes the various implementation technologies used to build. NET Web applications.

Logical layer
The logical application architecture treats any system as a set of mutually collaborative services divided into the following layers:

• User Service

• Business Services

• Data Services


The value of this logical architecture view is that it distinguishes between services that are ubiquitous in any system, ensures proper separation, and facilitates interface definitions between tiers. This separation allows you to build more maintainable applications by making more careful architectural and design choices as you implement each logical layer.

The logical layers are described below:

• User Service is responsible for the interaction between the client and the system and provides a common network bridge that is connected to the core business logic, encapsulated by components within the business services layer. In general, user services are associated most frequently with interactive users. However, they also initiate initial processing of programming requests from other systems, in which case no visible user interface is involved. The exact nature of authentication and authorization varies by client type and is typically performed within the User Service layer.

• The business layer provides the core functionality of the system and encapsulates the business logic. They are independent of the transport channel and back-end systems or data sources. This provides the necessary stability and flexibility to upgrade the system to support new, different channels and back-end systems. Typically, servicing a specific business request involves many collaborative components within the Business service layer.

• Data Services provide access to data (hosted within the system boundary) and other (back-end) systems through a generic interface, which can be easily used through components within the business services layer. Data Services abstract a variety of backend systems and data sources, and encapsulate specific access rules and data formats.


The logical classification of the service types within the system is related not only to the possible physical distribution of the components that implement these services, but also to their physical distribution.

You can identify the logical layer at any aggregation level, specifically, you can identify the logical layer for the entire system (in the context of the system environment and the external interaction), or you can identify the logical layer for any subsystem that is contained in the system. It is also important to remember that. For example, each remote node that hosts a WEB service consists of a user Service (processing incoming requests and messages), business services, and data services.

Physical Deployment model
The three logical service layers described above do not imply a specific number of physical layers. All three logical services may be physically located on the same computer or across multiple computers.

Web Server as Application server
The common deployment pattern for. NET Web applications is to place the business and data access components on the WEB server. This minimizes network hops and helps improve performance. This model is shown in Figure 1.



Figure 1. Web Server as Application server

Remote Application Layer
The remote application layer is a common deployment pattern, especially the common deployment pattern in the following Internet scenarios: The WEB layer is a stand-alone part of the perimeter network (known as the DMZ and screened subnet), separated from the end user and remote application layer by the packet filtering firewall. Figure 2 The remote application layer is shown in.



Figure 2. Introduction to the remote application layer


Implementation technology
. NET WEB applications typically use the following techniques to implement one or more logical services:

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 security, see: "ASP.net security."

• Enterprise Services

Enterprise Services provides an infrastructure-level service for applications. This includes distributed transaction and resource management services, such as object pooling for. NET components. For more information about Enterprise Services, see Enterprise service security.

Web Service

WEB services implement remote invocation of data exchange and application logic using SOAP based message exchange for firewalls to move data and move data between heterogeneous systems. For more information about Web services, see Web Service security.

.net Remoting

. NET Remoting provides a framework for accessing distributed objects across process and computer boundaries. For more information about. NET Remoting, see "Net Remoting security."

Ado.net and Microsoft_ SQL server™2000

Ado.net provides data access services. Ado. NET was designed specifically for distributed Web applications from the outset, and is ideal for discrete scenarios that are intrinsically linked to Web applications. SQL Server provides integrated security using the operating system authentication mechanism (Kerberos or NTLM). Authorization is provided by logins and fine-grained permissions that can be applied to a single database object. For a detailed discussion of data access security, see "Data access security."

Internet Protocol security (IPSEC)

IPSec provides point-to-point transport-level encryption and authentication services. For more information about IPSEC, see Secure communications.

• Secure Sockets Layer (SSL)

SSL provides a point-to-point secure communication channel. The data transmitted through this channel is encrypted. For more information about SSL, see Secure communications.



Security architecture
Figure 3 shows the remote application layer model and the security services provided by the various technologies described earlier. Authentication and authorization are distributed at many points in each layer. These services are provided primarily by Internet Information Services (IIS), ASP.net, Enterprise services, and SQL Server. At the same time, the secure communication channel is applied at all levels and extends from the client browser or device to the database. The security of the channel is guaranteed by a combination of Secure Sockets Layer (SSL) or IPSEC.



Figure 3. Security architecture

Security between the layers
Table 1 summarizes the authentication, authorization, and secure communication capabilities provided by the technologies discussed earlier.

Table 1: Security Features
Technical Authentication Authorization Secure communication
Iis
Anonymous

Basic

Digest type

Windows Integration (KERBEROS/NTLM)

Certificate
Ip/dns Address Restrictions

Web Permissions

NTFS permissions; Windows for requested files

Access Control List (ACL)
Ssl

asp.net
None (Custom)

Windows

Form

Passport
File authorization

URL Authorization

Principal permission

. NET role
-

Web Services
Windows

None (Custom)

Message Level Authentication
File authorization

URL Authorization

Principal permission

. NET role
SSL and message-level encryption

Remoting
Windows
File authorization

URL Authorization

Principal permission

. NET role
SSL and message-level encryption

Enterprise Services
Windows
Enterprise Services (COM +) role

NTFS Permissions
Remote Procedure Call (RPC) encryption

SQL Server 2000
Windows (KERBEROS/NTLM)

SQL Authentication
Server login

Database Login

Fixed database role

User-defined roles

Application role

Object permissions
Ssl

Windows 2000
Kerberos

Ntlm
Windows ACLs
Ipsec


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

ASP. NET authentication Mode

Enterprise Services Authentication

SQL Server Authentication


asp.net authentication Mode
Asp. NET authentication modes include Windows, forms, passport, and no authentication.

Windows authentication. In this authentication mode, ASP.net relies on IIS to authenticate users and create Windows access tokens to represent authenticated identities. IIIS provides the following authentication mechanisms:

• Basic authentication. Basic authentication requires the user to provide a certificate in the form of a user name and password to prove its identity. It is an Internet standard based on RFC 2617. Http://www.faqs.org/rfcs/rfc2617.html. Netscape Navigator and Microsoft Internet Explorer support Basic authentication. The user certificate is routed from the browser to the WEB server in an unencrypted Base64 encoding format. Because the Web server gets a user certificate that is not encrypted, the Web server can use a user certificate to issue remote calls (for example, to access remote computers and resources).

Note Basic authentication should only be used with secure channels, which are usually established using SSL. Otherwise, user names and passwords can easily be stolen by network monitoring software. If you use Basic authentication, you should use SSL on all pages, not just the login page, because the certificate is passed when all subsequent requests are issued. For more information on federated use of Basic authentication and SSL, see "asp.net security."

• Digest authentication. Digest authentication with IIS 5.0 is similar to Basic authentication, but it does not use an unencrypted format when transferring user certificates from the browser to the WEB server, but hashing format. Therefore, it is more secure, but it requires Internet Explorer 5.0 or later clients and a specific server configuration.

• Integrated Windows authentication. Integrated Windows authentication (Kerberos or NTLM, depending on the client and server configuration) verifies the user identity by using an encrypted exchange with the user's Internet Explorer Web browser. Only Internet Explorer supports this authentication (not supported by Netscape Navigator). Therefore, this validation is generally only used in intranet scenarios, because you can control the client software used in your intranet. If anonymous access is disabled or anonymous access is denied through Windows file system permissions, this authentication can only be used by the WEB server.

• Certificate authentication. Certificate authentication uses client certificates to explicitly identify users. The client certificate is passed to the WEB server by the user's browser (or client application). (in the case of a Web service, the Web service client passes the certificate through the HttpWebRequest object's ClientCertificates property.) The WEB server extracts the user identity from the certificate. This method relies on the client certificate installed on the user's computer, so it is typically used in an intranet or extranet scenario because you are familiar with and able to control the user base in your intranet and extranet. After the client certificate is received by IIS, you can map the certificate to a Windows account.

• Anonymous authentication. If you do not need to authenticate the client (or you implement a custom authentication scheme), you can configure IIS for anonymous authentication. In this case, the WEB server creates a Windows access token to represent all anonymous users who use the same anonymous (or guest) account. The default anonymous account is IUSR_machinename, where MachineName is the NetBIOS name that is specified for the computer at installation time.


Passport authentication. In this authentication mode, ASP. NET uses the Microsoft Passport centralized authentication service. Asp. NET provides a convenient wrapper for packaging the functionality provided by the Microsoft Passport Software Development Kit (SDK), which must be installed on a WEB server.

• Forms authentication. This method uses client redirection to forward unauthenticated users to the specified HTML form, where the user can enter a certificate (typically a user name and password). The certificates are then validated and the authentication ticket is generated and returned to the client. There is a user ID on the authentication ticket, and you can optionally list the roles that the user belongs to during the session on the authentication ticket.

Forms authentication is sometimes used only for personalization of Web sites. In this case, you hardly have to write any custom code, because the ASP. NET handles most of this process automatically with a simple configuration. In a personalization scheme, cookies only need to retain the user name.

Note: Form authentication sends a user name and password to the WEB server in clear text. Therefore, forms authentication should be used in conjunction with SSL-protected channels. To provide uninterrupted protection for the authentication cookies transmitted in subsequent requests, you should consider using SSL on all pages in your application, not just on the logon page.

• No "None" means that you do not want to authenticate the user or that you are using a custom authentication protocol.


More information

For more information about ASP.net authentication, see "asp.net security."

Enterprise Service authentication
Enterprise service authentication is performed through the underlying remote procedure call (RPC) transport infrastructure, which uses the operating system's Security Service Provider Interface (SSPI). You can authenticate an enterprise Service application client using Kerberos or NTLM authentication.

You can host service components in a library application or in a server application. Library applications are hosted within the client process, so they take the identity of the client. Server applications run in separate server processes, and they have their own identities. For more information about identities, see the "Identification and Principals" section later in this chapter.

Incoming calls to serviced components can be authenticated at the following levels:

• Default: Use the default authentication level of the security package.

• None: No authentication is performed.

• Connection: Authentication only on connection.

• Call: Authenticate every time a remote procedure call is started.

• Packet: Authenticate and verify that all call data has been received.

• Packet Integrity: Verifies that data was modified during transmission.

• Packet confidentiality: Verifies and encrypts data packets, including data and sender identification and signature.


More information

For more information about Enterprise services authentication, see Enterprise service security.

SQL Server Authentication
SQL Server can authenticate users either by using Windows authentication (NTLM or Kerberos) or by using its built-in authentication scheme, known as SQL authentication. There are two available options:

SQL Server and Windows. Clients can connect to instances of Microsoft SQL Server using SQL Server Authentication or Windows authentication. Sometimes this is also known as mixed-mode authentication.

• Use Windows only. Users must connect to instances of Microsoft SQL Server using Windows authentication.


More information

See "Data access Security" for the benefits of each method.

Authorized
The. NET Framework on Windows 2000 provides the following licensing options:

asp.net licensing options

Enterprise Services Licensing

SQL Server Licensing


asp.net licensing options
Asp. NET licensing options are available for use by ASP.net Web applications, Web services, and remote components. ASP.net provides the following licensing options:

URL authorization. This is the authorization mechanism configured through the settings in the Computer configuration file and the application configuration file. URL authorization allows you to restrict access to specific files and folders in the application's Uniform Resource Identifier (URI) namespace. For example, you can choose to deny or allow specified users access to a specific file or folder (addressed by URL). You can also restrict access based on the user's role membership and the HTTP predicate type used to issue requests (get, POST, and so on).

URL authorization requires an authenticated identity. It can be obtained by Windows or authentication ticket based authentication schemes.

• File authorization. File authorization applies only if you are authenticating the caller with a Windows authentication mechanism provided by IIS and ASP.net is configured to use Windows authentication.

You can use it to restrict access to the specified files on the WEB server. Access permissions are determined by the file-related Windows ACL.

• Principal permission requirements. The subject permission requirement can be used as a more granular access control mechanism (declaratively or programmatically). This permission requirement allows you to control access to classes, methods, or individual blocks of code based on the identity and group memberships of individual users.

.net role ... NET role is used to bring together users with the same permissions within an application. They are conceptually similar to previous role-based implementations (for example, Windows groups and COM + roles). However, unlike these methods, the. NET role does not require an authenticated Windows identity and can be used in an authentication scheme that is based on authentication tickets, such as forms authentication.

The. NET role can be used to control access to resources and operations, and such roles can be configured either declaratively or programmatically.


More information

For more information about ASP.net licensing, see "asp.net security."

Enterprise Services Licensing
Access to the functionality contained in the service components within an enterprise service application is restricted by the Enterprise Service role membership. Unlike. NET roles, they can contain Windows groups or user accounts. Role membership is defined within the COM + catalog and managed by using the Component Services tool.

More information

For more information about Enterprise services Licensing, see Enterprise Service security.

SQL Server Licensing
SQL Server allows you to set fine-grained permissions that can be applied to a single database object. You can make permissions based on role membership (SQL Server provides fixed database roles, user-defined roles, and application roles), or you can grant permissions to a single Windows user or group account.

More information

For more information about SQL Server licensing, see Data Access security.

Gateway Guards and Gates
In the remainder of this document, the term gatekeeper is used to refer to the technology responsible for the gateway. A gateway represents an access control point within an application (protecting a resource). For example, a resource can be an action (represented by the method of the object) or a database or file system resource.

Each of the core technologies listed above provides a gatekeeper for access authorization. The request must pass through a series of gates before it is allowed to access the requested resource or operation. Here is a description of the various gateways that the request must pass:

IIS provides a gateway when you authenticate users (that is, you disable anonymous authentication). IIS Web permissions can be used as an access control mechanism that restricts the ability of web users to access specific files and folders. Unlike NTFS file permissions, Web permissions apply to all Web users, not to individual users or groups. NTFS file permissions provide further restrictions on web resources such as Web pages, image files, and so on. These restrictions apply to individual users or groups.

IIS checks Web permissions, and then checks NTFS file permissions. Users must obtain authorization from both mechanisms before they can access a file or folder. If the Web permissions check fails, IIS returns an HTTP 403-access rejection response, and if the NTFS permission check fails, IIS returns HTTP 401-Deny access.

asp.net provides a variety of configurable programming gateways. These include URL authorization, file authorization, principal permission requirements, and. NET roles.

The Enterprise Services Gatekeeper uses the Enterprise Services role to grant access to business functions.

SQL Server 2000 includes a range of gateways, including server logins, database logins, and database object permissions.

Windows 2000 uses ACLs associated with security resources to provide a gateway.


The bottom line is that the gatekeeper is authorized based on the identity of the user or service calling to the gateway and attempting to access a particular resource. The advantage of multiple gateways is to provide defense-in-depth security through multiple defensive lines. Table 2.2 summarizes the various gateways and their responsible checkpoints.

Table 2. Gatekeeper responsibilities and the gateway to provide
Gateway Guard Checkpoint
Windows Operating System
Logon rights (positive and negative, such as "Deny logon locally")

Other permissions (for example, "act as part of the operating system")

Access checks on protected resources, such as the registry and file system. Access checks use ACLs that are related to security resources, which specify who is allowed access to resources and who is not allowed to access them, and specify the types of operations that are allowed to be performed.

TCP/IP Filtering

IP Security

Iis
Authentication (anonymous, Basic, Digest, integration, certificate)

IP address and Domain name restrictions (they can be used to enforce security defenses, but should not depend on them because it is easier to use deceptive IP addresses).

Web Permissions

NTFS Permissions

asp.net
URL authorization

File authorization

Principal permission Requirements

. NET role

Enterprise Services
Windows (Ntlm/kerberos) authentication

Enterprise Services (COM +) role

Impersonation Level

WEB Services
Using the gateways provided by IIS and ASP.net

Remote processing
Use the gateway provided by the host. If it is in ASP. NET, which uses the gateway provided by IIS and ASP.net. If you are hosting in a Windows service, you must develop a custom solution.

Ado.net
Connection strings can use explicit certificates, or you can use Windows authentication (for example, when connecting to SQL Server)

SQL Server
Server login

Database Login

Database object Permissions


By using a variety of gateways across the layers of your application, you can filter out which users should be allowed access to your back-end resources. Requests in the process of reaching back-end resources through the application, the control of a series of connected gates is becoming more and more refined, so that the scope of access is gradually reduced.

Consider an internet-based application example that uses IIS, as shown in Figure 4.



Figure 4 Filtering users with gatekeeper

Figure 4 illustrates the following points:

• You can disable anonymous authentication in IIS. This allows access only to an account that is authenticated by IIS. This can reduce the number of potential users to 10,000.

• Next, you can go to the ASP. NET using URL authorization, which can reduce the number of users to 1,000.

• File authorization may further reduce the scope of access, reducing the number of users to 100.

• Finally, depending on the role membership, the WEB application code may allow only 10 users to access restricted resources.



Describes. NET Framework Security
The. NET Framework security is above Windows security; it does not replace Windows security, but rather provides additional security features. The success or failure of a. NET application to access all resources is ultimately determined by the security of the operating system.

For example, if an asp.net Web application opens a file, the ability to open the file depends on the Windows ACL associated with the file. The identity used for resource access is either the ASP.net application process identity or the personalization identity of the application that uses personalization.

Code Access security
The. NET Framework provides an additional security mechanism called Code Access Security (CAS). Traditional security, such as the security provided by Windows, is subject-centered, and authorization is based on a validated body, such as the user running code, or a user logging on to a WEB application.

CAS adds a content to security by supporting authorization based on code identity rather than users running code. This is especially important for mobile code that is downloaded from the Internet using Internet Explorer, such as controls and applications. This is because you may be logged on to your computer as an administrator, but do you really want this code to have administrator privileges? If you consider the security of your computer, you may not allow it.

Evidence and security Policy
The code is validated and its identity is determined by using the properties of the code, which is called evidence. Evidence can contain a public key to the Assembly (which is part of its strong name), download URL, install application directory, and other content. Once the code flags are established, the evidence collected is passed through security policy, and the security policy ultimately manages the functionality of the code and what permissions are granted to access security resources.

The default policy ensures that all code installed on the local machine is fully trusted and has unrestricted access to security resources. Therefore, all resource access is managed only by operating system security. The code installed on the local machine is completely trustworthy because the administrator is first required to make a careful decision when installing the software.

CAS and asp.net Web applications
Asp. NET application to the local Web server, so the default policy on the server gives the Web application full trust. This means that CAS is limited in scope for server-side WEB application developers. In fact, a asp.net Web application built on the. NET Framework version 1 must run as a fully trusted application.

Note The version 1.1 of the. NET Framework adds support for partial trust Web applications so that CAS can be used effectively on server-side Web applications. The main benefits of introducing CAS are easy to separate applications from each other, and to separate applications from critical system resources, for Internet Service Providers (ISPs) and application developed by different companies that can host multiple WEB applications Service provides (ASPs) is an important factor to consider.

Principals and identities
Although CAS is code-centric, other aspects of the. NET Framework security are subject-centered.. NET Framework security dominates the ASP.net application security with the principal focus.

The user-centric concept of Windows security is based on the security context provided by the logon session, while. NET security is based on IPrincipal and IIdentity objects.

In Windows programming, if you want to understand the security context on which code is running, you should query the identity of the process owner or the currently executing thread. In. NET programming, if you want to query the security context for the current user, you should retrieve the current IPrincipal object from Thread.CurrentPrincipal.

When you run. NET code. NET Framework uses identity objects and principal objects to represent users, which together form the backbone of the. NET role's authorization. For ASP.net Web applications, users are represented by the principal and flag objects attached to the current thread and Web request.

IPrincipal and IIdentity interfaces
Identity and principal objects must implement IIdentity and IPrincipal interfaces, respectively. These interfaces are defined within the System.Security.Principal namespace. The public interface enables the. NET Framework to handle identity and principal objects in a polymorphic manner, regardless of the details of the underlying implementation.

The IPrincipal interface allows you to test the membership of a role through the IsInRole method, while also providing access to the associated IIdentity object.

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

The IIdentity interface provides more details about authentication, such as name and authentication type.

public interface IIdentity
{
String AuthenticationType {get;}
BOOL IsAuthenticated {get;}
String Name {get;}
}

The. NET Framework provides several concrete implementations of IPrincipal and IIdentity, as shown in Figure 5, and these implementations are described in detail in the following sections.



Figure 5. IPrincipal and IIdentity implementation classes

WindowsPrincipal and WindowsIdentity
The. NET version of the Windows security context is divided into 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 stores the identity portion of the current user's security context, which can be obtained from the static WindowsIdentity.GetCurrent () method. It returns a WindowsIdentity object with the Token property that returns a IntPtr that represents a Windows handle to the access token associated with the current execution thread. The token can then be passed to native win32® application programming Interface (API) functions, such as GetTokenInformation, Settokeninformation, and checktokenmembership, etc. Used 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 emulated. This is similar to the Win32 GetUserName API.


GenericPrincipal and associated Identity objects
These implementations are simple enough for applications that do not use Windows authentication to be used when the application does not require a complex representation of the principal. You can create these implementations very easily in your code, so there must be some level of trust when your application processes GenericPrincipal.

If you rely on the IsInRole method on GenericPrincipal to make authorization decisions, you must trust the application that sent you genericprincipal. This contrasts with the use of the WindowsPrincipal object: When using the WindowsPrincipal object, the operating system must be entrusted with a valid WindowsPrincipal object, and an authorization specifier and a valid group/role name.

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

FormsIdentity This class represents an identity that has been authenticated by forms. It contains information about the user's authentication session stored in the FormsAuthenticationTicket.

PassportIdentity This class represents a passport-authenticated identity that contains Passport profile information.

GenericIdentity This class represents a logical user that is not associated with any particular operating system technology, and is typically used in custom authentication and authorization mechanisms.


asp.net and HttpContext.User
In general, before making any authorization decision, check Thread.CurrentPrincipal in. NET code. However, ASP.net uses HttpContext.User to provide the security context for authenticated users.

This property accepts and returns the IPrincipal interface. that contains an authenticated user that is associated with the current request. ASP.net will retrieve HttpContext.User when making the authorization decision.

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

asp.net identification
There may be multiple identities in a single request at any given time during the execution of an asp.net application. They include:

HttpContext.User Returns the IPrincipal object that contains the security information for the current WEB request. This is an authenticated Web client.

windowsidentity.getcurrent () returns the security context identity of the currently executing WIN32 thread. By default, this identity is ASPNET; This is the default account that is used to run the ASP.net Web application. However, if the WEB application is configured for impersonation, the identity represents an authenticated user (if IIS Anonymous authentication is valid, the identity is IUSR_ MACHINE).

Thread.CurrentPrincipal returns the body of the currently executing. NET thread (which is on the WIN32 thread).


More information

• For a detailed analysis of the asp.net identity of the WEB application configuration mix, including the use of impersonation and impersonation, see "asp.net identity Matrix."

• For more information about creating your own IPrincipal implementation, see "asp.net security" and "How to implement IPrincipal".


Remoting and Web Services
In the latest version of the. NET Framework, Remoting and Web services do not have their own security model. They all inherit the security features of IIS and asp.net.

Although there are no built-in security features in the remoting architecture, security is considered at design time. Developers and/or administrators can decide for themselves to integrate some degree of security into remoting applications. Whether the principal object is passed between remoting boundaries depends on the location of the client and the remote object, for example:

• Remoting within the same process. When remoting is used between objects in the same application domain or in different application domains, the remoting infrastructure copies the reference of the IPrincipal object associated with the caller context to the recipient's context.

• Remote processing between processes. In this case, the IPrincipal object is not transferred between processes. The certificate used to construct the original IPrincipal must be routed to the remote process, which may be located on another computer. This allows the remote computer to construct the corresponding IPrincipal object based on the certificate provided.



Summary
This chapter describes all the authentication and authorization options provided by the various technologies associated with. NET. Also describes. NET Framework security, as well as principals and identity objects, which are the core of asp.net validation.

By using multiple gatekeeper in the entire. NET application, you will be able to implement a defense-in-depth security policy. To sum up, there are the following points:

asp.net applications can use the existing security features provided by Windows and IIS.

SSL and IPSEC can be used to jointly provide secure communications on all layers of a. NET application, such as from a browser to a database.

• When using basic or form authentication, you can use SSL to protect plaintext certificates that are passed over the network.

• ASP.net applications built on the. NET Framework version 1 must run as fully trusted applications, which means that code access security is limited in scope for server-side Web application developers.. NET Framework 1.1 Version will provide a partially trusted Web application, which becomes more important in this CAS.

.net uses a combination of WindowsPrincipal and WindowsIdentity classes to represent users who have been authenticated by Windows.

GenericPrincipal and GenericIdentity or formsidentity classes are used to represent users who have been authenticated by a non-Windows authentication scheme such as form authentication.

• You can create your own body and identity implementations by creating classes that implement IPrincipal and IIdentity.

• Within the ASP.net application, the IPrincipal object that represents the authenticated user is associated with the current HTTP Web request using the HttpContext.User property.

• Gateway is an access control point within an application where authorized users can access resources or services through these access points. The gatekeeper is responsible for controlling access to the gateway.

• Use multiple gatekeeper guards to provide defense-in-depth security policy.

Web Services and. NET remoting that rely on ASP.net and IIS to provide the underlying security services.