Asp.net| Security | program | Access SUMMARY: This paper mainly introduces the types of security models of ASP.net Web applications, compares their advantages and disadvantages, and puts forward the selection mechanism.
Keywords: security model trusted Child model simulation/delegate model ASP.net Web application
1. Foreword
asp.net Web applications usually belong to multilayer architecture, which can be divided into presentation layer, business logic layer and data access layer from logical structure, and the authentication and authorization of the client to access the application resources must span multiple levels. This paper mainly discusses the resource access security model of sp.net application.
2. Resource access identification
Typical resources that Web applications provide externally to clients include:
Web server resources, such as Web pages, Web services, and static resources (HTML pages and images).
Database resources, such as data for each user or application-level data.
network resources, such as remote file system resources.
system resources, such as the registry, event logs, and configuration files.
Clients access these resources across the layers of the application, with an identity that flows through each layer. This identification for resource access includes:
The identity of the original caller identifies the original caller and then flows through each layer of the system.
Process identity Local resource access and downstream calls are made using the current process identity. The viability of this approach depends on the boundaries to be crossed, because the process identifier must be recognized by the target system. This needs to be invoked in one of the following two ways:
In the same Windows security domain
Cross Windows security Domain-use trust and domain accounts, or use duplicate user names and passwords without a trust relationship.
Service account This method uses a (fixed) service account. For example
For database access, the service account may represent a fixed SQL user name and password by a component connected to the database.
You should use the Enterprise Services server application when you need a fixed Windows identity.
Custom identity when no Windows account is available, you can use the IPrincipal and IIdentity implementations to construct your own identity, which can contain detailed information about the security context.
3. Resource access model
3.1 Trusted Subsystem Model
As shown in Figure 1, in this model, the original caller's security context does not flow through the service at the operating system level, but instead uses a fixed identity at the intermediary service layer to access downstream services and resources. The trusted subsystem model derives its name from the fact that the downstream service (possibly a database) trusts the upstream service to authorize its callers. The example in Figure 1, the database trusts that the middle tier authorizes the caller and allows only authorized callers to access the database using the trusted identity.
3.1.1 Resource access Mode
In the trusted subsystem model, the resource access mode is as follows:
Validating the user
Mapping a user to a role
Authorization based on Role membership
Access downstream resources using a fixed, trusted identity
3.1.2 Fixed logo
A fixed identity used to access the downstream system and resource manager, either by using the process identity or by using a preset Windows account-service account. For SQL Server Resource Manager, this means Windows authentication for SQL Server.
The ASP.net process identity is typically used when using process identities (tacit knowledge of the ASPNET account). In practical applications, it is often necessary to change the ASPNET account to a more secure password and to mirror the SQL Server computer to create a Windows account that matches the ASP.net process account. The specific methods are as follows:
Edit the Machine.config file located in the%windr%\microsoft.net\framework\v1.1.4322\config directory to reconfigure the password properties on the <processModel> element. Change its default value <!-username= "Machine" password= "AutoGenerate"--> to <!-username= "machine" password= "NewPassword" >; or through the Aspnet_setreg.exe tool, save username and password to the registry, configure to: <!-enable= "true" Username= registry:hklm\software\yourapp\ Processsmodel\aspnet_setreg,username "password=" Registry:hklm\software\yourapp\processsmodel\aspnet_setreg, Password "-->
Other applications access SQL Server using the specified SQL account (specified by user name and password in the connection string). In this case, the database must be configured to be SQL authenticated. The connection string saved in the configuration file requires encryption protection.
3.2 Simulation/delegation Model
As shown in Figure 2, when using the mock/delegate model, a service or component (usually in the logical business Services layer) uses the operating system emulation feature to simulate the client identity before accessing the next downstream service. If the service is on the same computer, using impersonation is sufficient, and if the downstream service is located on a remote computer, a delegate is also required, and the security context for downstream resource access is the client's context.
3.3 Select Resource access model
The comparison of the two resource access models is shown in table one.
Trusted Subsystem Model simulation/delegation Model
Audit function back-end trust Upper service, if the middle layer is violated, the back-end resources vulnerable to attack. The backend service can authenticate, authorize, and secure each caller.
Scalable support for connection pooling, good scalability. Connection pooling is not supported, and scalability is poor.
The back-end ACL management ACL is configured for a single entity with little administrative effort. Each user is given the appropriate level of access, and management is cumbersome when the backend resources and the number of users increase.
Technical issues need not be delegated. A delegate is required. Most security service providers do not support delegates.
The trusted subsystem model is used in most Internet applications, as well as in large intranet applications, mainly because of the good support for scalability of this model. The simulation/delegate model tends to be used in small systems. Scalability is not a major consideration for these applications, and its main consideration is auditing.
3. Related articles
The ASP. NET application security Scheme (i)-authentication.
The ASP. NET application security Scheme (ii)-authorization.
The ASP. NET application security Scheme (ii)-Secure communications.
