Abstract: This article mainly introduces the types of security models for ASP.NET WEB applications, compares their advantages and disadvantages, and proposes a selection mechanism.
Keywords: security model trusted submodel simulation/delegation submodel ASP.NET WEB application
1.Preface
ASP.NET WEB applications usually belong to a multi-layer architecture. Generally, the logical structure can be divided into presentation layer, business logic layer and data access layer. To access application resources, the client's identity authentication and authorization must span multiple layers. level. This article mainly discusses the resource access security model of SP.NET applications
2. Resource access identification
Typical resources externally provided by WEB applications to clients include:
Web server resources, such as Web pages, Web services, and static resources (HTML pages and images).
Database resources, such as per-user data or application-level data.
Network resources, such as remote file system resources, etc.
System resources, such as the registry, event logs, and configuration files, etc.
Clients access these resources across application layers, with an identity flowing through each layer. This identity used for resource access consists of:
The identity of the original caller The identity of the original caller is obtained and subsequently flows through each layer of the system.
Process ID Local resource access and downstream calls are made using the current process ID. The feasibility of this approach depends on the boundary to be crossed, since the process identity must be recognized by the target system. This needs to be called in one of two ways:
Cross Windows security domains within the same Windows security domain - use trusts and domain accounts, or use duplicate usernames and passwords where no trust relationship exists.
Service Account This approach uses a (fixed) service account. For example, for database access, the service account might be represented by a fixed SQL username and password by a component connected to the database.
When a fixed Windows identity is required, the Enterprise Services server application should be used.
Custom Identity When no Windows account is available, you can use Iprincipal and Iidentity to construct your own identity, which can include details about the security context.
3. Resource access model
3.1 Trusted subsystem model
As shown in Figure 1, in this model, the security context of the original caller does not flow through the service at the operating system level, but a fixed identity is used in the intermediate service layer to access downstream services and resources. The trusted subsystem model gets its name from the fact that a downstream service (perhaps a database) trusts an upstream service to authorize its callers. In the example in Figure 1, the database trusts the authorization of the caller by the middle layer, and only allows authorized callers to access the database using trusted identities.
3.1.1 Resource access mode
In the trusted subsystem model, the resource access model is as follows:
Authenticate users Map users to roles Authorize based on role membership Use a fixed trusted identity to access downstream resources
3.1.2 Fixed identification
A fixed identity used to access downstream systems and resource managers, which can be provided using a process identity or a preset Windows account-service account. For SQL Server Explorer, this means Windows Authentication to SQL Server.
When using the process identity, you usually use the ASP.NET process identity (the default is the ASPNET account). In practical applications, it is often necessary to change the ASPNET account to a more secure password and create a Windows account on the SQL Server computer that matches the ASP.NET process account. The specific method is as follows:
Edit the Machine.config file located in the %windr%Microsoft.NETFrameworkv1.1.4322CONFIG directory and reconfigure the password attribute on the <processModel> element to its default value <!-UserName="machine" password ="AutoGenerate" -->Change to <!-UserName="machine" password="NewPassword" -->; or use the ASPNET_setreg.exe tool to save the user name and password to the registry, and change the configuration to: <!- enable="true" UserName="Registry:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,userName" password=" Registry:HKLMSOFTWAREYourAPPprocesssModelASPNET_SETREG,password " -->
Other applications use a designated SQL account (specified by the username and password in the connection string) to access SQL Server. In this case, the database must be configured for SQL authentication. The connection string saved in the configuration file needs to be protected by encryption.
3.2 Simulation/Delegation Model
As shown in Figure 2, when using the impersonation/deletion model, a service or component (usually located in the logical business services layer) uses operating system impersonation capabilities to impersonate the client identity before accessing the next downstream service. If the service is on the same machine, using impersonation is enough, if the downstream service is on a remote machine you also need to use delegation, the security context of the downstream resource access is the context of the client.
3.3 Select resource access model
The comparison of the two resource access models is shown in Table 1.
The backend of the trusted subsystem model simulation/delegated model audit function trusts the upper-layer services. If the middle layer is compromised, the back-end resources are vulnerable to attack. The back-end service can authenticate and authorize each caller with good security.
Scalability supports connection pooling and has good scalability. Does not support connection pooling and has poor scalability.
Back-end ACL management ACL is configured for a single entity, requiring less management work. Each user must be granted the corresponding access level. When the number of back-end resources and users increases, the management work becomes cumbersome.
No need to delegate technical issues. Delegation is required. Most security service providers do not support delegation.
The trusted subsystem model is used in most Internet applications as well as large intranet applications, mainly because this model can support scalability well. The simulation/delegate model tends to be used in smaller systems. For these applications, scalability is not the primary consideration; the primary consideration is auditing.