Security model for ASP.NET applications
Release Date: 9/28/2004
| Update Date: 9/28/2004
Browse all security guidance topics
Microsoft Corporation
In this section
A powerful ASP.NET application depends on the successful interaction of many elements and technology. Each solution is provided with security features that are designed to meet their needs. However, it is not enough to see security from the perspective of a single component. In order to provide security for the overall solution, it must also be considered how the components interact.
This section describes the .NET web application architecture and security, and provides a framework for reference, and other sections in this series add other content to this frame. This section reviews security features and services existing at all levels of .NET web applications. It also introduces .NET Framework security, and explains which elements in this framework is most important to ASP.NET web application developers.
aims
This chapter is used:
• Deeply understand the .NET web application architecture and logically and physical application layer concepts. • Understand which security features provided by each implementation technology can be used to build .NET web applications, and how they work together. • Understand the .NET Framework security function, and understand which elements are most important to web application security. • Compare and configures the authorization and verification mechanisms that can be used in the web application. • Learn how to use the body and identification object in the .NET web application. • Determine the gateway guards and customs of the application to implement the trust boundary.
Applicable to:
This chapter is applied to the following products and technology:
• Microsoft_ Windows_ XP or Windows 2000 Server and its future operating system • Internet Information Services (IIS) • .NET Framework 1.0 version and later version
How to use this section
In order to get more gains from this chapter:
• You must have an experience of developing ASP.NET web applications. This will help you understand where the various security elements discussed in this unit are combined with your application. • Read "Introduction to Build a Security ASP.NET Application", this article emphasizes the importance of authorization, verification, and secure communication in creating security, distributed web applications. It also points out the main principles and practices adopted when developing security web applications.
This page
.NET web application implementation technical security architecture introduction .NET Framework security summary
.NET web application
This part provides a brief introduction to the .NET web application and indicates its characteristics from logically and physically. It also introduces various implementation techniques for building a .NET web application.
Logical layer
The logical application architecture treats any system as a group of collaborative services, which are divided into the following layers:
• User Services • Business Services • Data Services
The value of this logical architecture view is to universally exist in various service distractions in any system, ensuring appropriate separation and interface definitions between layers. This separation allows you to make an architecture and design choice when implementing each logical layer, thereby building a more easy maintenance application.
The logic layers are now described below:
• The user service is responsible for interaction between clients and systems, and provides a public bridge that is connected to core business logic, which is encapsulated by components within the business service layer. Generally speaking, the user service is associated with interactive users. However, they also initially handle program requests issued by other systems, in which case no visible user interface is involved. The authentication of authentication and authorization varies depending on the client type, which is usually performed within the user service layer. • The business layer provides the core function of the system and packages business logic. They are independent of the transport channel and backend system or data sources. This provides the necessary stability and flexibility for lifting systems to support new, different channels and backend systems. Typically, a service providing service is provided for a particular service request involves many collaborative components within the business service layer. • Data Services Provide access to data (system boundaries) and other (rear end) systems through general interfaces; these interfaces can be easily used through components within the business service layer. Data services have abstracted a variety of backend systems and data sources and encapsulate specific access rules and data formats. The logical classification of each service type within the system is related to the possible physical distribution of components that implements these services, and relatively independent of their physical distribution.
The logic layer can be identified on any aggregation level. Specifically, the logic layer can be identified for the entire system (in the system environment context and external interaction), or any subsystem contained in the system can identify the logic layer. Remember this is also important. For example, each remote node that carries a web service is composed of a user service (process incoming request and message), business service and data service.
Physical deployment model
The three logical service layers described earlier do not mean there is a specific number of physical layers. All three logic services may be physically located on the same computer, or may be distributed on multiple computers.
Web server used as an application server
The usual deployment mode of the .NET web application is to place the service and data access components on the web server. This minimizes network hop and helps improve performance. This model is shown in Figure 1. .
Figure 1. Web server is used as an application server
Remote application layer
The remote application layer is a common deployment mode, especially the common deployment mode in the following Internet scenarios: The web layer is independent in the peripheral network (which is the DMZ and mask of the mask knows). Screening Firewall is separated from the end user and remote application layer to display the remote application layer.
Figure 2. Profile of remote application layer
Implementation technology
The .NET web application typically uses the following techniques to implement one or more logical services:
• ASP.NET ASP.NET is usually used to implement user services. ASP.NET provides a plug-in architecture that can be used to build a web page. For more information on ASP.NET security, see: "ASP.NET Security". • Enterprise Services Enterprise Services provides an infrastructure level service for your application. This includes distributed transactions and resource management services, such as object pools of .NET components. For more information on Enterprise Services, see "Enterprise Service Security". • Web Services Web Services uses SOAP-based messaging to firewall mobile data and mobile data between heterogeneous systems to implement remote calls of data exchange and application logic. For more information on web services, see "Web Service Security". • .NET Remoting .NET Remoting provides a framework for accessing distributed objects accessed across processes and computer boundaries. For more information on .NET Remoting, see "Net Remoting Security". • ADO.NET and Microsoft_ SQL ServerTM 2000 ADO.NET provide data access services. ADO.NET starts from the beginning of the design of distributed web applications, which is ideal for separation schemes for contact with web applications. SQL Server provides integrated security using the operating system authentication mechanism (Kerberos or NTLM). Authorization is provided by login and refinement 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 a point-to-point transmission level encryption and authentication service. For more information on IPSec, see "Secure Communication". • Safety Socket Layer (SSL) SSL provides a security communication channel for point-to-point. Data transmitted through this channel is encrypted. For more information on SSL, see "Secure Communication". Safety architecture
Figure 3 shows those safety services provided by remote application layer models and various techniques described above. Authentication and authorization are performed in a number of points distributed in each layer. These services are mainly provided by Internet Information Services (IIS), ASP.NET, Enterprise Services, and SQL Server. At the same time, the secure communication channel is applied to the layers and extends from the client browser or device to the database. The security of the channel is securely provided by the security socket layer (SSL) or IPSec.
Figure 3. Safety architecture
Safety between layers
Table 1 Abstract The authentication, authorization, and secure communication function provided by the techniques discussed above.
Table 1: Safety Function Technical Authentication Authorized Security Communication IIS Anonymous Basic Summary Windows Integration (Kerberos / NTLM) Certificate IP / DNS Address Limit Web Permissions NTFS Permissions; Windows Access Control List (ACL) SSL ASP.NET (Custom) Windows Forms Passport file authorization URL Authorized principal permission .NET Role - Web Services Windows No (Custom) Message Level Authentication File Authorization URL Authorized Main Permissions .NET Role SSL and Message Level Encryption Remoting Windows File Authorization URL Authorization Subject permission .NET Role SSL and Message Level Enter Enterprise Services Windows Enterprise Services (COM ) Role NTFS Permissions Remote Procedure Call (RPC) Encrypted SQL Server 2000 Windows (Kerberos / NTLM) SQL Authentication Server Login Database Login Fixed Database Role User Defined Role application role object authority 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
The ASP.NET authentication mode includes Windows, Forms, Passport, and Authentication.
• Windows authentication. In this authentication mode, ASP.NET relies on II to authenticate and create a Windows Access Token to represent the authenticated identity. IIIS provides the following authentication mechanism:
• Basic authentication. Basic authentication requires users to provide certificates in the form of a username and password to demonstrate their identity. It is the Internet standard proposed based on RFC 2617. Http://www.faqs.org/rfcs/rfc2617.html. Netscape Navigator and Microsoft Internet Explorer support basic authentication. The user certificate is transmitted from the browser to the web server in a non-encrypted base64 encoding format. Since the user certificate obtained by the web server is a format that is not encrypted, the web server can use the user certificate to issue remote calls (eg, access remote computers and resources). Note Basic authentication should only be used with a secure channel (usually built using SSL). Otherwise, the username and password are easy to steal by the network monitoring software. If you use basic authentication, you should use SSL on all pages (not just login pages) because all subsequent requests are issued. For more information on combining basic authentication and SSL, see "ASP.NET Security" for details. • Summary authentication. Summary authentication with IIS 5.0 is similar to basic authentication, but it does not use a hash format when transmitting user certificates from the browser to the web server, and use hash format. Therefore, it is more secure, but it requires the client and a specific server configuration using Internet Explorer 5.0 or later. • Integrated Windows authentication. Integrated Windows Authentication (Kerberos or NTLM, depending on the client and server configuration) to confirm the user ID using encryption exchange with the User Internet Explorer Web Browser. Only Internet Explorer supports this verification (Netscape Navigator does not support). So, this verification generally can only be used in the intranet scenario because you can control the client software used in the intranet. If anonymous access is disabled, or refuse to access anonymity via Windows file system permission, this verification can only be used by the web server. • Certificate authentication. Certificate authentication uses client certificates to explicitly identify users. The client certificate is passed from the user's browser (or client application) to the web server. (If it is a web service, the Web service client passes the certificate through the clientCertificates property of the HttpWebRequest object.) The web server extracts the user ID from the certificate. This method relies on the client certificate installed on the user's computer, so it is usually used in the intranet or Extranet scheme because you are familiar with and control the user group in the intranet and Extranet. After receiving the client certificate, IIS can map the certificate to the Windows account. • Anonymous authentication. If you don't need to authenticate the client (or you implement a custom authentication scheme), you can configure IIS for anonymity authentication. In this case, the web server creates a Windows Access Token to represent all anonymous users using the same anonymous (or guest) account. The default anonymous account is IUSR_MACHINENAME, where MachineName is the NetBIOS name specified by the computer at the time of installation. • Passport authentication. In this authentication mode, ASP.NET uses Microsoft Passport's centralized authentication service. ASP.NET provides convenient packaging to package the features provided by Microsoft Passport Software Development Kit (SDK), which must be installed on the web server. • Form authentication.
This method uses the client redirect to forward the authenticated user to the specified HTML form, and the user can enter a certificate in the form (usually the username and password). The system then verifies these certificates and generates an authentication ticket and returns it to the client. There is a user ID on the authentication ticket, you can also choose to list the roles you belong during the session on the authentication ticket. Sometimes the form authentication is only used for personalized processing of the Web site. In this case, you have hardly use any custom code because ASP.NET automatically handles most of this process with a simple configuration. In a personalized processing scheme, cookies only need to keep usernames. Note: Form authentication sends usernames and passwords to the web server in express form. Therefore, the form authentication should be used in combination with the channel of SSL protection. In order to protect the authentication cookies transmitted in subsequent requests, you should consider using SSL on all pages within the application, not just on the login page. • None "None" means that you don't want to authenticate the user, or use a custom authentication protocol. More information
For more details on ASP.NET authentication, see "ASP.NET Security".
Enterprise service authentication
Enterprise Services Authentication Through the Based "Remote Procedure Call" (RPC) transfer infrastructure of enterprise service, the infrastructure uses the Security Service Provider Interface (SSPI) of the operating system. Enterprise service application clients can be authenticated using Kerberos or NTLM authentication.
Service components can be loaded in library applications or server applications. The library applicator is carried by the client process, so they use the client's identity. The server application runs within a separate server process, which has its own identity. For more information on the identification, see the "Identity and Main Body" section in this chapter.
The transfer to the service component can be authenticated at the following level:
• Default: Use the default authentication level of the secure package. • None: Do not perform authentication. • Connections: Authentication only when connecting. • Call: Each time the remote procedure call is invoked. • Packet: Identify and verify that all call data has been received. • Packet Integrity: Verify that the data is modified during transmission. • Packet Confidentiality: Verify and encrypt packets, including data and senders's identity and signature.
More information
For more information on Enterprise Services authentication, see "Enterprise Service Security".
SQL Server authentication
SQL Server can authenticate users either Windows Authentication (NTLM or Kerberos), or use their built-in authentication scheme (called SQL authentication) to authenticate users. There are two available options:
• SQL Server and Windows. The client can connect to the Microsoft SQL Server instance using SQL Server authentication or Windows authentication. Sometimes this is also called a mixed mode authentication. • Use only Windows. Users must use Windows authentication to connect to the instance of Microsoft SQL Server.
More information
For the advantages of each method, see "Data Access Security".
Authorize
The .NET Framework on Windows 2000 provides the following licenses:
• ASP.NET Authorization Options • Enterprise Services Authorization • SQL Server Authorization
ASP.NET Authorization Options
The ASP.NET Authorization option is available for 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 the settings in the computer configuration file and the application configuration file. URL authorization allows you to limit access to specific files and folders in the "Unified Resource Identifier" namespace of the application. For example, you can choose to reject or allow the specified user to access a specific file or folder (by URL addressing). You can also restrict access based on the user's role member and HTTP predicate type used to issue requests (GET, POST, etc.). URL authorization needs to be identified by authentication. It can be obtained by Windows or authentication ticket based authentication scheme. • File authorization. Only one Windows authentication mechanism is authenticated using IIS to authenticate the caller and the ASP.NET is configured to use Windows authentication, file authorization is available. You can use it to restrict access to specified files on the web server. Access rights are determined by the Windows ACL associated with the file. • Main permission requirements. Main permission requirements can be used as an access control mechanism that is more refined as a declaration or programming method. This permission requirement allows you to control access to classes, methods, or individual code blocks based on the identity of a single user and group members. • .NET role ..NET role is used to set a user who has the same permissions in the application. They are conceptually similar to previous roles (eg, Windows Groups, and COM Roles). However, with these methods, .NET role does not need to be authenticated for Windows identity, can be used in authentication tickets based on authentication tickets (such as form authentication). The .NET role can be used to control access to resources and operations, and such roles can be configured with declaration, or programming. More information
For more information on ASP.NET licenses, see "ASP.NET Security".
Enterprise Services Authorization
Access to the functions contained in the service components within the Enterprise Service Application are subject to the corporate service role membership system. Unlike .NET roles, they can include a Windows group or user account. Role member is defined within the COM directory and managed by using the Component Services tool.
More information
For more information on Enterprise Services Authorization, see "Enterprise Service Security".
SQL Server Authorization
SQL Server allows detail permissions, which can be applied to a single database object. You can let the permissions based on role member identity (SQL Server provides fixed database roles, user-defined roles and application roles), or grant permissions to a single Windows user or group account.
More information
For more information on SQL Server Authorization, see "Data Access Security".
Gateway guard and the gate
In the rest of this document, the term network guards is used to refer to the responsible information. The gateway represents access control points within the application (protection resources). For example, the resource can be an action (represented by the object) or database or file system resources.
Each core technology listed above provides the gateway guard for access authorization. The request must be passed through a series of gates before they are allowed to access the requested resources or operations. The following describes each of the requests that must pass:
• IIS provides a gateway when you authenticate your user (ie, you disable an anonymity authentication). IIS web privileges can be used as access control mechanisms that limit web users access to specific files and folders. Unlike NTFS file permissions, web privileges are applied to all web users, not a single user or group. NTFS file privileges provide further restrictions on web resources (such as web pages, image files, etc.). These limits apply to a single user or group. IIS checks web privileges, then check NTFS file permissions. The user must obtain the authorization of two mechanisms to access the file or folder. If the web privilege check fails, IIS will return to HTTP 403 - Access Deny Response, if the NTFS permission check fails, IIS will return to HTTP 401 - Reject Access. • ASP.NET provides a variety of configurable programmable portals. These include URL licenses, document authorizations, subject permission requirements, and .NET roles. • Enterprise Services Gateway defensive uses Enterprise Services roles to grant access to business features. • SQL Server 2000 includes a series of gateways, including server login, database login, and database object permissions. • Windows 2000 provides the gateway with ACL-related ACLs. The bottom line is: The gateway guards the identification of the user or service of the user or service that is called to the gateway and tries to access the specific resource. The benefits of multiple gues are through multiple defense lines to provide a depth defense safety mechanism. Table 2.2 Abstract Describes the gateway guard and its responsible gateway.
Table 2. Responsibility of gateway guards and the gateway gateway guards the gateway WINDOWS operating system login permissions (affirmatively and negation, such as "reject local login") other permissions (such as "part of the operating system) to protected resources (such as" Registry and file system) for access check. Access Check Using ACLs related to secure resources, these ACLs specify who allows to access resources and not allowing to access resources and specify the type of operation allowed. TCP / IP Filter IP Security IIS Authentication (Anonymous, Basic, Summary, Integration, Certificate) IP Address and Domain Name Restrictions (they can be used to strengthen security defense, but should not rely on them, because using spoofing IP addresses is comparison Easy things). Web Permissions NTFS Permissions ASP.NET URL Authorized Document Authorized Main Permission Demand. NTLM / Kerberos Authentication Enterprise Services (COM ) Role Analog Level Web Services Using IIS and ASP.NET Provided by IS and ASP.NET Provided the gate. If it is carried in ASP.NET, it uses the gate ports provided by IIS and ASP.NET. If it is carried in a Windows service, you must develop a custom solution. ADO.NET Connection Strings You can use explicit certificates, you can also use Windows authentication (for example, when connecting to SQL Server) SQL Server server login database login database object permissions
You can filter out your backend resources by using various gates on each of the applications. Requesting In the process of reaching the backend resource through the application, the control of a series of connected gateways is getting detailed and detachably, making the access range gradually narrowed.
Consider the use of IIS's Internet-based application example, as shown in Figure 4.
Figure 4 Screening the user with the network
Figure 4 illustrates the following points:
• You can ban anonymous authentication in IIS. This will only be accessed only by IIS authentication accounts. This can reduce the number of potential users to 10,000. • Next, you can use the URL authorization in ASP.NET, which can reduce the number of users to 1,000. • File authorization may further narrow the access range and reduce the number of users to 100. • Finally, according to a particular role member, the web application code may only allow 10 users to access restricted resources. Introduction .NET Framework security
.NET Framework security above Windows security; it does not replace Windows security, but provides additional security features. The success or failure of all resource access is ultimately determined by the security system of all resource access.
For example, if an ASP.NET web application is to open a file, you can open the file depending on the Windows ACL associated with this file. The identity for resource access either is an ASP.NET application process identifier, or uses a personalized identity of the application of personalized processing.
Code Access Security
.NET Framework provides an additional security mechanism called code access security (CAS). Traditional security (such as the security provided by Windows) is based centered, and authorized based on a verified body, such as a user run code, or a user logged in a web application.
CAS adds a content to security by supporting authorization based on code identity (not the user who runs code). This is especially important for mobile code (such as controls and applications) downloaded from the Internet Explorer. This is because you may log in to your computer as an administrator, but do you really want this code to have administrator privileges? If you take into account the security of your computer, you may not allow.
Evidence and security strategy
The code is verified and its identifies the properties of the code to determine, this code is called evidence. Evidence can include a compilation public key (part of its strong name), download the URL, install the application directory, and other content. Once the code logo is established, the evidence collected passes the security policy, and the security policy finally manages the code function and what license access security resources are given.
The default policy ensures that all code installed on the local machine is fully credible, and security resources can be accessed unrestricted. So all resource access is only subject to operating system security management. Since the administrator is required to make a cautious decision when installing the software, the code installed on the local machine is fully credible.
CAS and ASP.NET web applications
The ASP.NET application is installed on the local web server, so the default policy on the server is fully trusted by the Web application. This means that CAS is limited to the server-side web application developers. In fact, the ASP.NET web application based on the .NET Framework version 1 must run as a fully trusted application.
Note The 1.1 version of NET Framework adds support for partial trust web applications, which allows CAS to be efficiently used for server-side web applications. The main benefits of introducing CAS are easy to separate the applications, and separating applications and critical system resources; this for Internet Service Providers (ISPs) and Application, which can carry multiple web applications developed by different companies. Service Provides (ASPS) is an important consideration.
Subject and identification
Although CAS is centered on code, other aspects of .NET Framework security are centered on the body. .NET Framework security plays a role in ASP.NET application security in the main body.
Windows Security User Center Concept is based on secure context provided by login sessions, while .NET security is based on iPrincipal and Iidentity objects.
In Windows programming, if you want to understand the security context of the running code, you should query the identity of the process owner or the identity of the currently executed thread. In .NET programming, if you want to query the current user's security context, you should retrieve the current iPrincipal object from Thread.currentPrincipal.
When running .NET code. NET Framework uses identifier objects and subject objects to represent users, and the two objects together constitute an authorized part of the .NET role. For the ASP.NET web application, verify the verified user by attaching the host and flag object attached to the current thread and the web request.
IPrincipal and IIDENTITY interface
Identity and subject objects must implement IIDENTITY and IPRINCIPAL interfaces, respectively. These interfaces are defined in the System.Security.Principal namespace namespace. The public interface makes the .NET Framework can handle the identity and main object in a polymorphic manner, regardless of the details of the basic implementation.
The iPrincipal interface allows you to test the role of the role through the IsinRole method, and also provide access to the associated IIDENTITY object.
Public Interface IPrIncipal
{
Bool isinrole; String Role
Iidentity Identity {Get;}
}
The IIDENTITY interface provides more details on authentication, such as names and validation types.
Public Interface IIDENTITY
{
String AuthenticationType {Get;}
Bool isauthenticated {get;}
String name {get;}
}
The .NET Framework provides multiple specific implementations of IPrincipal and IIDENTITY, as shown in Figure 5, and the rear section will be described in detail.
Figure 5. iPrincipal and IIDENTITY implementation
Windowsprincipal and WindowsIdentity
Windows security contextual .NET version is divided into two classes:
• WindowsPrincipal. This class stores the role associated with the current Windows user. WindowsPrincipal implements the Windows group as a role. The iprncipal.isinrole method returns true or false based on the user's Windows group member. • WindowsIdentity This class stores the identification section of the current user security context, which can be obtained from a static WindowsIdentity.getCurrent () method. It returns a WindowsIdentity object with the Token property that returns an intPtr that represents the Windows handle to the access token associated with the current execution thread. The token can then be passed to the unit WIN32® application programming interface (API) function such as GetTokenInformation, SetTokenInformation, and CheckTokenMembership, etc., which are used to retrieve security information related to the token. Note: The static windowsidentity.getCurrent () method returns the identity of the currently executed thread, which may be (or may not) simulate. This is similar to Win32 GetUserName API.
GenericPrincipal and Associated Identity objects
These implementations are very simple, and applications that do not use Windows authentication are used when applications do not require complex representation of the body. You can create these implementations very easily in your code, so you must have some degree of trust when your application handles GenericPrincipal. If you rely on the Isinrole method on GenericPrincipal, you must trust the application of GenericPrincipal to you. This is compared to the WindowsPrincipal object: When using the WindowsPrincipal object, the operating system must be entrusted to provide a valid WindowsPrincipal object, and an authorization representation and a valid group / role name.
The following types of identification objects can be associated with the GenericPrincipal class:
• FormSidentity This class represents an identifier that has been verified by the form. It contains information related to the user's authentication session in the FormSAuthenticationalTicket. • PassportIndentity This class indicates an identifier that has passed the Passport authentication, which contains the Passport configuration file information. • GenericIdentity This class represents a logical user associated with any particular operating system technology, usually used in a custom authentication and authorization mechanism.
ASP.NET and HTTPCONTEXT.USER
Usually, before any authorization decision, first check Thread.currentPrincipal in .NET code. However, ASP.NET uses HttpContext.user to provide authenticated security context.
This property accepts and returns the iprincipal interface. This property contains a authenticated user associated with the current request. ASP.NET will retrieve httpContext.user when making an authorization decision.
When using Windows authentication, the Windows Authentication module automatically constructs a WindowsPrincipal object and stores it in httpContext.user. If other authentication mechanisms (such as forms or Passports) must be used, the genericprincipal object must be constructed and store it in httpContext.user.
ASP.NET logo
There may be multiple identities in any given time during the ASP.NET application execution process. They 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 security context ID of the currently executed Win32 thread. By default, the identity is an ASPNET; this is the default account for running the ASP.NET web application. However, if a web application is configured to simulate, the identity indicates authenticated users (if IIS anonymity authentication is valid, the identifier is IUSR_MACHINE). • Thread.currentPrincipal returns the main body of the currently executed .NET thread (which is located above the Win32 thread).
More information
• For detailed analysis of ASP.NET identity for web application configuration combinations (including using simulation and unused simulations), see "ASP.NET Identity Matrix". • For more information on creating your own iPrincipal implementation, see "ASP.NET Security" and "How to Implement IprIncipal".
Remoting and Web Services
In the latest version of .NET Framework, Remoting does not have its own security model with Web services. They all inherit IIS and ASP.NET security features. Although there is no built-in security function in the remote processing architecture, security is considered in design. Developers and / or administrators can determine their own security in remote processing applications. Whether to transfer the main object between the remote processing boundaries depends on the location of the client and the remote object, for example:
• Remote processing in the same process. When using remote processing between objects within the same application domain or in different application domains, the remote processing infrastructure copies the reference to the IPrincipal object related to the calling party context to the context of the recipient. • Remote processing between processes. In this case, IPRINCIPAL objects are not transmitted between the processes. Certificates for constructing raw iprincipal must be transferred to remote processes, which may be on another computer. This allows the remote computer to construct the corresponding IPRINCIPAL object according to the supplied certificate.
summary
This chapter describes all authentication and authorization options provided with .NET related techniques. It also introduces .NET Framework security, and body and identification objects, which are the core content of ASP.NET verification. .
You will be able to achieve a depth defense security policy by using multiple gateways in the entire .NET application. Summary, have the following points:
• ASP.NET applications can use existing security features provided by Windows and IIS. • SSL and IPSec can be used to provide secure communication in all layers of .NET applications (eg, from browser to database). • When using basic or form authentication, SSL protection can be used to protect the express document passed through the network. • The ASP.NET application based on the .NET Framework version 1 must be run as a fully credible application, which means that code access security is limited to server-side web application developers. The .NET Framework 1.1 version will provide part of the trusted web application, which is more important in this CAS. • .NET uses a combination of WindowsPrincipal and WindowsIdentity classes to represent users who have passed Windows authentication. • GenericPrincipal and GenericIdentity or FormTITITY class are used to indicate users who have been verified by non-Windows authentication scenarios such as form authentication. • You can create your own body and identity implementation by creating classes that implement iPrincipal and IIDENTITY. • In the ASP.NET application, IPRINCIPAL objects that represent authenticated users are associated with the current HTTP web request with the current HTTP web request. • The gateport is the access control point within the application, and the authorized user can access resources or services through these access control points. The gateway guards the access to the gateway. • Use multiple gateway guards to provide depth defense security policies. • Web services and .NET Remoting that rely on ASP.NET and IIS to provide underlying security services.
The next chapter, "Authentication and Authorization Design" will provide additional information to help you select the most suitable authentication and authorization strategy for a particular application solution.
