Building Secure ASP.NET Applications phần 4 doc

Building Secure ASP.NET Applications142 Table 8.1: Windows authentication and impersonation requirements Authorization Option Requires Windows Requires Impersonation Authentication FileAuthorizationModule Yes No UrlAuthorizationModule No No Principal Permission Demands No No .NET Roles No No Enterprise Services Roles Yes Yes (within the ASP.NET Web application) NTFS Permissions (for directly N/A – These files are not No (IIS performs the access requested static files types; not handled by ASP.NET. check.) mapped to an ISAPI extension) With any (non-Anonymous) IIS authentication mecha- nism, permissions should be configured for individual authenticated users. With Anonymous authenti- cation, permissions should be configured for IUSR_MACHINE. NTFS Permissions (for files No No accessed by Web application If impersonating, configure code) ACLs against the imperson- ated Windows identity, which is either the original caller or the identity specified on the <identity> element in Web.config*. * The impersonated identity may be the original caller or the identity specified on the <identity> element in Web.config. Consider the following two <identity> elements. <identity impersonate="true" /> <identity impersonate="true" userName="Bob" password="pwd" /> The first configuration results in the impersonation of the original caller (as authen- ticated by IIS), while the second results in the identity Bob. The second configura- tion is not recommended for two reasons: ● It requires that you grant the ASP.NET process identity the “Act as part of the operating system” privilege on the Microsoft Windows® 2000 operating system. ● It also requires you to include a plain text password in Web.config. Both of these restrictions will be lifted in the next release of the .NET Framework. Chapter 8: ASP.NET Security 143 Windows Authentication with Impersonation The following configuration elements show you how to enable Windows (IIS) authentication and impersonation declaratively in Web.config or Machine.config. Note: You should configure authentication on a per-application basis in each application’s Web.config file. <authentication mode="Windows" /> <identity impersonate="true" /> With this configuration, your ASP.NET application code impersonates the IIS- authenticated caller. Configurable Security When you use Windows authentication together with impersonation, the following authorization options are available to you: ● Windows ACLs ● Client Requested Resources. The ASP.NET FileAuthorizationModule performs access checks for requested file types that are mapped to the ASP.NET ISAPI. It uses the original caller’s access token and ACL attached to requested resources in order to perform access checks. For static files types (not mapped to an ISAPI extension), IIS performs access checks using the caller’s access token and ACL attached to the file. ● Resources Accessed by Your Application. You can configure Windows ACLs on resources accessed by your application (files, folders, registry keys, Active Directory objects, and so on) against the original caller. ● URL Authorization. Configure URL authorization in Web.config. With Windows authentication, user names take the form DomainName\UserName and roles map one-to-one with Windows groups. <authorization> <deny user="DomainName\UserName" /> <allow roles="DomainName\WindowsGroup" /> </authorization> ● Enterprise Services (COM+) Roles. Roles are maintained in the COM+ catalog. You can configure roles with the Component Services administration tool or script. Building Secure ASP.NET Applications144 Programmatic Security Programmatic security refers to security checks located within your Web applica- tion code. The following programmatic security options are available when you use Windows authentication and impersonation: ● PrincipalPermission Demands ● Imperative (in-line within a method’s code) PrincipalPermission permCheck = new PrincipalPermission( null, @"DomainName\WindowsGroup"); permCheck.Demand(); ● Declarative (attributes preceding interfaces, classes and methods) [PrincipalPermission(SecurityAction.Demand, Role=@"DomainName\WindowsGroup)] ● Explicit Role Checks. You can perform role checking using the IPrincipal interface. IPrincipal.IsInRole(@"DomainName\WindowsGroup"); ● Enterprise Services (COM+) Roles. You can perform role checking program- matically using the ContextUtil class. ContextUtil.IsCallerInRole("Manager") When to Use Use Windows authentication and impersonation when: ● Your application’s users have Windows accounts that can be authenticated by the server. ● You need to flow the original caller’s security context to the middle tier and/or data tier of your Web application to support fine-grained (per-user) authoriza- tion. ● You need to flow the original caller’s security context to the downstream tiers to support operating system level auditing. Before using impersonation within your application, make sure you understand the relative trade-offs of this approach in comparison to using the trusted subsystem model. These were elaborated upon in “Choosing a Resource Access Model” in Chapter 3, “Authentication and Authorization.” Chapter 8: ASP.NET Security 145 The disadvantages of impersonation include: ● Reduced application scalability due to the inability to effectively pool database connections. ● Increased administration effort as ACLs on back-end resources need to be config- ured for individual users. ● Delegation requires Kerberos authentication and a suitably configured environ- ment. More Information ● For more information about Windows authentication, see “Windows Authentica- tion” later in this chapter. ● For more information about impersonation, see “Impersonation” later in this chapter. ● For more information about URL authorization, see “URL Authorization Notes” later in this chapter. ● For more information about Enterprise Services (COM+) roles, see Chapter 9, “Enterprise Services Security.” ● For more information about PrincipalPermission demands, see “Identities and Principals” in Chapter 2, “Security Model for ASP.NET Application.” Windows Authentication without Impersonation The following configuration elements show how you enable Windows (IIS) authen- tication with no impersonation declaratively in Web.config. <authentication mode="Windows" /> <! The following setting is equivalent to having no identity element > <identity impersonate="false" /> Configurable Security When you use Windows authentication without impersonation, the following authorization options are available to you: ● Windows ACLs ● Client Requested Resources. The ASP.NET FileAuthorizationModule performs access checks for requested file types that are mapped to the ASP.NET ISAPI. It uses the original caller’s access token and ACL attached to requested resources in order to perform access checks. Impersonation is not required. For static files types (not mapped to an ISAPI extension) IIS performs access checks using the caller’s access token and ACL attached to the file. Building Secure ASP.NET Applications146 ● Resources accessed by your application. Configure Windows ACLs on resources accessed by your application (files, folders, registry keys, Active Directory objects) against the ASP.NET process identity. ● URL Authorization. Configure URL Authorization in Web.config. With Windows authentication, user names take the form DomainName\UserName and roles map one-to-one with Windows groups. <authorization> <deny user="DomainName\UserName" /> <allow roles="DomainName\WindowsGroup" /> </authorization> Programmatic Security The following programmatic security options are available: ● Principal Permission Demands ● Imperative PrincipalPermission permCheck = new PrincipalPermission( null, @"DomainName\WindowsGroup"); permCheck.Demand(); ● Declarative [PrincipalPermission(SecurityAction.Demand, Role=@"DomainName\WindowsGroup")] ● Explicit Role Checks. You can perform role checking using the IPrincipal interface. IPrincipal.IsInRole(@"DomainName\WindowsGroup"); When to Use Use Windows authentication without impersonation when: ● Your application’s users have Windows accounts that can be authenticated by the server. ● You want to use a fixed identity to access downstream resources (for example, databases) in order to support connection pooling. Chapter 8: ASP.NET Security 147 More Information ● For more information about Windows authentication, see “Windows Authentica- tion” later in this chapter. ● For more information about URL authorization, see “URL Authorization Notes”, later in this chapter. ● For more information about PrincipalPermission demands, see “Principals” within the “Getting Started” section of this guide. Windows Authentication Using a Fixed Identity The <identity> element in Web.config supports optional user name and password attributes, which allows you to configure a specific fixed identity for your applica- tion to impersonate. This is shown in the following configuration file fragment. <identity impersonate="true" userName="DomainName\UserName" password="ClearTextPassword" /> When to Use This approach is not recommended for the current version (version 1) of the .NET Framework in secure environments for two reasons: ● User names and passwords should not be stored in plain text in configuration files, particularly configuration files stored in virtual directories. ● On Windows 2000, this approach forces you to grant the ASP.NET process account the “Act as part of the operating system” privilege. This reduces the security of your Web application and increases the threat should an attacker compromise the Web application process. The .NET Framework version 1.1 will provide an enhancement for this scenario on Windows 2000: ● The credentials will be encrypted. ● The log on will be performed by the IIS process, so that ASP.NET does not required the “Act as part of the operating system” privilege. Forms Authentication The following configuration elements show how you enable Forms authentication declaratively in Web.config. <authentication mode="Forms"> <forms loginUrl="logon.aspx" name="AuthCookie" timeout="60" path="/"> </forms> </authentication> Building Secure ASP.NET Applications148 Configurable Security When you use Forms authentication, the following authorization options are avail- able to you: ● Windows ACLs ● Client Requested Resources. Requested resources require ACLs that allow read access to the anonymous Internet user account. (IIS should be configured to allow anonymous access when you use Forms authentication). ASP.NET File authorization is not available because it requires Windows authentication. ● Resources Accessed by Your Application. Configure Windows ACLs on resources accessed by your application (files, folders, registry keys, and Active Directory objects) against the ASP.NET process identity. ● URL Authorization Configure URL Authorization in Web.config. With Forms authentication, the format of user names is determined by your custom data store; a SQL Server database, or Active Directory. ● If you are using a SQL Server data store: <authorization> <deny users="?" /> <allow users="Mary,Bob,Joe" roles="Manager,Sales" /> </authorization> ● If you are using Active Directory as your data store, user names, and group names appear in X.500 format: <authorization> <deny users="someAccount@domain.corp.yourCompany.com" /> <allow roles ="CN=Smith James,CN=FTE_northamerica,CN=Users, DC=domain,DC=corp,DC=yourCompany,DC=com" /> </authorization> Programmatic Security The following programmatic security options are available: ● Principal Permission Demands ● Imperative PrincipalPermission permCheck = new PrincipalPermission( null, "Manager"); permCheck.Demand(); Chapter 8: ASP.NET Security 149 ● Declarative [PrincipalPermission(SecurityAction.Demand, Role="Manager")] ● Explicit Role Checks. You can perform role checking using the IPrincipal interface. IPrincipal.IsInRole("Manager"); When to Use Forms authentication is most ideally suited to Internet applications. Use Forms authentication when: ● Your application’s users do not have Windows accounts. ● You want users to log on to your application by entering credentials using an HTML form. More Information ● For more information about Forms authentication, see “Forms Authentication” later in this chapter. ● For more information about URL authorization, see “URL Authorization Notes” later in this chapter. Passport Authentication The following configuration elements show how you enable Passport authentication declaratively in Web.config. <authentication mode="Passport" /> When to Use Passport authentication is used on the Internet when application users do not have Windows accounts and you want to implement a single-sign-on solution. Users who have previously logged on with a Passport account at a participating Passport site will not have to log on to your site configured with Passport authentication. Building Secure ASP.NET Applications150 Configuring Security This section shows you the practical steps required to configure security for an ASP.NET Web application. These are summarized in Figure 8.3. 1. Configure IIS (IIS Metabase) Install server certificate (SSL) Set ISS Authentication Configure client certificate mapping (Optional) 2. Configure ASP.NET (web.config, machine.config) Set authentication mode Set impersonation Configure URL authorization 3. Secure Resources (wWindows ACLs) Secure files, folders, registry keys Secure web and machine.config Log web.config settings 4. Secure Communication (IPSec/SSL) Secure communication links using a combination of IPSec and SSL Internet Services Manager XML Editor (or Notepad) Windows Explorer + Regedt32 Security Policy and Configuration Tools Figure 8.3 Configuring ASP.NET application security Chapter 8: ASP.NET Security 151 Configure IIS Settings To configure IIS security, you must perform the following steps: 1. Optionally install a Web server certificate (if you need SSL). For more information, see “How To: Set Up SSL on a Web Server” in the Refer- ence section of this guide. 2. Configure IIS authentication. 3. Optionally configure client certificate mapping (if using certificate authentica- tion). For more information about client certificate mapping, see article Q313070, “How to Configure Client Certificate Mappings in Internet Information Services (IIS) 5.0” in the Microsoft Knowledge Base. 4. Set NTFS permissions on files and folders. Between them, IIS and the ASP.NET FileAuthorizationModule check that the authenticated user (or the anonymous Internet user account) has the necessary access rights (based on ACL settings) to access the requested file. Configure ASP.NET Settings Application level configuration settings are maintained in Web.config files, which are located in your application’s virtual root directory and optionally within addi- tional subfolders (these settings can sometimes override the parent folder settings). 1. Configure authentication. This should be set on a per-application basis (not in Machine.config) in the Web.config file located in the application’s virtual root directory. <authentication mode="Windows|Forms|Passport|None" /> 2. Configure Impersonation. By default, ASP.NET applications do not imperson- ate. The applications runs using the configured ASP.NET process identity (usu- ally ASPNET) and all resource access performed by your application uses this identity. You only need impersonation in the following circumstances: ● You are using Enterprise Services and you want to use Enterprise Services (COM+) roles to authorize access to functionality provided by serviced components. ● IIS is configured for Anonymous authentication and you want to use the anonymous Internet user account for resource access. For details about this approach, see “Accessing Network Resources” later in this chapter. ● You need to flow the authenticated user’s security context to the next tier (for example, the database). ● You have ported a classic ASP application to ASP.NET and want the same impersonation behavior. Classic ASP impersonates the caller by default. [...]... Multithreaded Apartment (MTA) thread pool This has implications for ASP.NET Web applications that call Apartment model objects 176 Building Secure ASP.NET Applications Apartment Model Objects When an ASP.NET Web application calls an Apartment model object (such as a Visual Basic 6 COM object) there are two issues to note: q You must mark your ASP.NET page with the AspCompat directive, as shown below . classic ASP application to ASP. NET and want the same impersonation behavior. Classic ASP impersonates the caller by default. Building Secure ASP. NET Applications1 52 To configure ASP. NET impersonation. Configure Impersonation. By default, ASP. NET applications do not imperson- ate. The applications runs using the configured ASP. NET process identity (usu- ally ASPNET) and all resource access performed. Passport authentication. Building Secure ASP. NET Applications1 50 Configuring Security This section shows you the practical steps required to configure security for an ASP. NET Web application. These