Security is a major concern for both application architects and developers. Applications that store sensitive information need to be protected from malicious attacks and from competitors attempting to steal information or intellectual property. When designing a security model for your application, you need to be aware of security requirements from a business perspective and the implications that a chosen security model can have on performance, scalability, and deployment.
Security Considerations
If you are designing a server application, your design specification should contain a section that addresses security issues. You should consider and possibly address the following items in the application's functional specification:
* Security goals. Understand what you are securing and make sure that you can describe it.
* Security risks. Understand your application's vulnerabilities. You must also understand the significance of potential threats as they relate to your business.
* Authentication. This is the process of accepting credentials from a user and validating those credentials against a designated authority. The user's (or potentially an application's or computer's) identity is referred to as a security principal. The client must provide credentials to allow the server to verify the identity of the principal. After the identity is known, the application can authorize the principal to access resources on the system. Various criteria, which help you choose the appropriate authentication mechanism, are presented in the next section of this document.
* Authorization. This is the process of determining whether the proven identity is allowed to access a specific resource.
* Securing data transmission. By encrypting your data as it crosses the network, you can ensure that it cannot be viewed or tampered with while in transit. You must consider the degree to which your data needs to be secured while in transit.
* Impersonation. This mechanism allows a server process to run using the security credentials of the client. When the server is impersonating the client, any operations performed by the server are performed using the client's credentials. Impersonation does not allow the server to access remote resources on behalf of the client. This requires delegation.
* Delegation. Like impersonation, delegation allows a server process to run using the security credentials of the client. However, delegation is more powerful and allows the server process to make calls to other computers while acting as the client.
* Operating system security. This refers to the establishment of appropriate Access Control Lists (ACLs), and network security to prevent intruders from accessing secured resources. You must set the appropriate ACLs on the appropriate resources to allow access by only the relevant principals.
* Securing physical access. This refers to locating your server computer in a secure room. You should not overlook this fundamental issue.
* Code access security. This allows code to be trusted to varying degrees depending upon where it has come from and from other aspects of the code's identity. You should be aware of how to create your own access permissions.
Relationship Between IIS and ASP.NET
You should understand the relationship between Internet Information Services (IIS) authentication and the Microsoft® ASP.NET security architecture when designing your application. This will allow you to authenticate your users appropriately and obtain the correct security context within your application. You should note that ASP.NET application security configuration and IIS security configuration are completely independent and can be used independently or in conjunction with each other.
IIS maintains security related configuration settings in the IIS metabase. However, ASP.NET maintains security (and other) configuration settings in XML configuration files. While this generally simplifies the deployment of your application from a security standpoint, the security model adopted by your application will necessitate the correct configuration of both the IIS metabase and your ASP.NET application via its configuration file (Web.config).
Figure 1 illustrates the relationship between IIS and ASP.NET.
ms978378.authaspdotnet01(en-us,MSDN.10).gif
Figure 1. The security relationship between IIS and ASP.NET
ASP.NET Authentication Providers and IIS Security
ASP.NET implements authentication using authentication providers, which are code modules that verify credentials and implement other security functionality such as cookie generation. ASP.NET supports the following three authentication providers:
* Forms Authentication. Using this provider causes unauthenticated requests to be redirected to a specified HTML form using client side redirection. The user can then supply logon credentials, and post the form back to the server. If the application authenticates the request (using application-specific logic), ASP.NET issues a cookie that contains the credentials or a key for reacquiring the client identity. Subsequent requests are issued with the cookie in the request headers, which means that subsequent authentications are unnecessary.
* Passport Authentication. This is a centralized authentication service provided by Microsoft that offers a single logon facility and membership services for participating sites. ASP.NET, in conjunction with the Microsoft® Passport software development kit (SDK), provides similar functionality as Forms Authentication to Passport users.
* Windows Authentication. This provider utilizes the authentication capabilities of IIS. After IIS completes its authentication, ASP.NET uses the authenticated identity's token to authorize access.
To enable a specified authentication provider for an ASP.NET application, you must create an entry in the application's configuration file as follows:
Copy Code
// web.config file
In addition to authentication, ASP.NET provides an impersonation mechanism to establish the application thread's security token. Obtaining the correct token relies upon you configuring IIS authentication, ASP.NET authentication providers, and ASP.NET impersonation settings appropriately. Figure 2 shows the most likely combinations between IIS authentication and ASP.NET providers.
ms978378.authaspdotnet02(en-us,MSDN.10).gif
Figure 2. ASP.NET and IIS security settings matrix
Authentication using Windows accounts
If you plan to authenticate users using accounts maintained by a Microsoft Windows NT® domain controller or within Microsoft Windows® 2000 Active Directory™, you should use IIS Authentication coupled with the Windows Provider for ASP.NET, as illustrated in Figure 2. By using this approach, you do not need to write any specific authentication code. When authentication happens using this method, ASP.NET constructs and attaches a Windows Principal object to the application context based on the authenticated user. As a result, the ASP.NET thread can run as the authenticated user and can obtain the user's group membership.
In some cases, you may want to bypass IIS authentication and implement a custom solution. This is also possible with ASP.NET. For example, you can write a custom ISAPI filter that checks the user's credentials against Active Directory and the creation of the Windows Principal object would be performed manually. There are other methods besides this one that will work, but they all require more code than using the .NET provider directly.
Authentication using non-Windows accounts
If you are planning to authenticate users at the application level, and the users do not have Windows accounts, you will typically configure IIS to use Anonymous authentication. In this configuration, consider the following .NET authentication modules:
* None: Use when you are not authenticating users at all, or developing custom authentication code.
* Forms: Use when you want to provide users with a logon page.
* Passport: Use when you are using Passport services.
Impersonation and delegation
With impersonation, ASP.NET applications can optionally execute with the identity of the client on whose behalf they're operating. Impersonation is usually performed for resource access control. You should carefully consider whether or not impersonation is required, as it consumes additional server resources. Delegation is a more powerful form of impersonation and allows remote resources to be accessed by the server process while acting as the client.
If impersonation is enabled, ASP.NET will receive the token to impersonate from IIS. You have more granular control of impersonation in a Web application when using ASP.NET in comparison to traditional Active Server Pages (ASP). This is controlled by specifying a value in the application's Web.config file.
You have the following three options when specifying the required impersonation setting:
* Impersonation enabled. In this instance, ASP.NET will impersonate the token passed to it by IIS, which will either be an authenticated user or the anonymous Internet user account.
Copy Code
* Impersonation enabled, with a specific impersonation identity specified. In this instance, ASP.NET will impersonate the token generated using the configured identity. In this case the client token, if applicable, is not used.
Copy Code
* Impersonation is disabled. This is the default setting for backward compatibility with ASP. In this instance, the ASP.NET thread will run using the process token of the application worker process, which by default is the IIS system account, regardless of which combination of IIS and ASP.NET authentication have been used.
Copy Code
If the application resides on a UNC share, ASP.NET will always impersonate the IIS UNC token to access that share unless a configured account is used. If an explicitly configured account is provided, ASP.NET will use that account in preference to the IIS UNC token.
Table 1 shows the thread token ASP.NET uses to execute the request based on three different Web.config configuration settings. Note that the IUSR_SERVER account indicates the account configured for anonymous access for the current URL (that is, this doesn't have to be an IUSR_ account). The process account is the account the application worker process is running as: by default this is the System Account, unless specifically configured.
Table 1. ASP Thread Token for ASP and IIS Configurations
ASP.NET Impersonation IIS is using Anonymous IIS is not using Anonymous Application resides on UNC Share
Disabled Process Account Process Account IIS UNC Token
Enabled IUSR_SERVER Authenticated user IIS UNC Token
Enabled with a specified user "Jeff" "Jeff" "Jeff" "Jeff"
Application identities
You are advised to run the ASP.NET application worker process (aspnet_wp.exe) using a specifically configured account, with weaker privileges than the default System account. This is for two main reasons. Firstly, if security is breached, the intruder does not have administrative access. Secondly, it allows Application Service Providers (ASPs) to run applications using weaker accounts, so hosted applications cannot compromise the integrity of the server computer or perform actions that require administrative privileges.
To run the ASP worker process using a specified account, add a
Copy Code
In addition to specifying a particular user account, you can also set the username attribute to one of two specially recognized values, "SYSTEM" and "MACHINE". In both cases, the password attribute must be set to "AutoGenerate", as specific credentials are not required. The "SYSTEM" setting runs the worker process using the System account, while "MACHINE" (which is the default) causes the worker process to run with a special account named with an ASPNET prefix. This account is similar to the IWAM_MACHINENAME account, used by IIS for running instances of dllhost.exe when hosting regular ASP applications. The ASPNET account is created during .NET installation.
If you use a custom account, that account must have the necessary access rights to the following directories.
* Read/write access is required to the %installroot%\ASP.NET Temporary Files directory. Sub-directories beneath this root are used for dynamically compiled output.
* Read/write access is required to the %temp% directory. This is used by the compilers during dynamic compilation.
* Read access is required to the application directory.
* Read access is required to the %installroot% hierarchy to allow access to system assemblies.
Note that the relevant ACEs are defined during the installation process for the ASPNET account.
If you use a specifically configured process account, you should be aware of a restriction that this places on the use of impersonation. While you can still impersonate the identity of the client, you can't use the extended form of impersonation where a specified impersonation account is defined within the application's Web.config file. This is because this option requires that the worker process has the SE_TCB_NAME ("Act as part of the operating system") privilege, which the weaker process identity generally won't have. Per request impersonation still works, because IIS creates the logon session and passes the impersonation token directly to the worker process. Note that this restriction only applies to Windows 2000 and Windows NT 4. Microsoft Windows XP contains enhancements that allow specific logon sessions to be generated without requiring this privilege.
For more information, read the following chapters from the .NET Framework Developers Guide:
* "How ASP.NET Security Works"
* "ASP.NET Authentication"
* "ASP.NET Configuration Concepts"
* "Using IIS Authentication With ASP.NET Impersonation"
For information about authentication in IIS 5.0, see the article Internet Information Services 5.0 Authentication Methods.
Authentication Methods
You have a variety of options for authentication within your .NET Web applications. For example, you may choose to utilize one of the supported IIS authentication mechanisms, or you may instead decide to perform authentication within your application code. You should consider some or all of the following factors when choosing an authentication method:
* Server and client operating systems
* The client browser type
* The number of users, and the location and type of the user name and password database
* Deployment considerations, such as whether your application is Internet or intranet based and whether it is located behind a firewall
* The application type; for example, is it an interactive Web site or a non-interactive Web service
* Sensitivity of the data you are protecting
* Performance and scalability factors
* Application authorization requirements; for example, you may want your application to be available to all users, or you may need to restrict certain areas to registered users, and other areas to "administrators only."
Determining an Authentication Method
You can use the flow chart shown in Appendix A to help determine the most appropriate authentication method, based on the requirements of your individual application. To use the chart, answer the questions concerning the nature of the user base and the deployment model. The chart endpoints contain the appropriate candidate authentication methods.
After you examine the flow chart, you should study the following subsections, each of which provide more detailed information about the various authentication methods and provide further guidance that will help you fine tune your decision-making process. At the end of this section, you should be able to select a candidate authentication method.
Explanation of flowchart decision points
1. Do users have to log in? Is a user name and password required to access the site or service?
2. Is personalization required? Will the site provide personalized content, without requiring the users to log on?
3. User Accounts? Are user accounts stored in Windows NT domain accounts, Active Directory, or are they stored in some other data store, for example a relational database, an alternate LDAP (Lightweight Directory Access Protocol) directory service, or an XML file?
4. Is single sign-on or seamless logon required? Do you want the users to log on from a logon page, or do you need authentication to happen automatically? For example, you may require automatic authentication for an automated Business-to-Business (B2B) transaction.
5. Do you need a secure logon? Do you need to make the system extremely hard for hackers to steal user names and passwords over the network? This decision is typically made based on the sensitivity of the data available on the site.
6. Will the application run on the Internet? Will the application be behind a firewall, where users are not authenticated to a domain, or will the application be intranet-based where the end users may already be authenticated to a domain?
7. Do you need to delegate security context? Do you need business components to run with the caller's identity? If so, impersonation is required. Furthermore, if you need to access system resources such as message queues, databases, or file systems on remote computers, delegate-level impersonation will be required.
8. Are servers and clients running only Windows 2000? Are you running a homogeneous environment of computers running Windows 2000, or are there clients running other operating systems, such as Windows 9x and Windows NT 4.0?
Anonymous Authentication
With Anonymous authentication, the server does not request the client to send user credentials. It is a good choice when your site or service is publicly available and you do not need to know the identity of the caller. Additionally, there are typically no browser restrictions which stem from incompatibilities with supported authentication mechanisms. When a site is configured for Anonymous authentication, all users are allowed access. It is important to note that although you may have IIS configured for Anonymous authentication, you may be authenticating at the ASP.NET layer, which is not true Anonymous authentication. This section assumes that both IIS and the application do not require a login.
Typical usage scenarios
You should consider Anonymous authentication when:
* You do not need to know the name and/or password of the caller for either login or business logic components.
* The information you are protecting is considered "public."
You should not consider Anonymous authentication when:
* You are restricting your user base to require a login name and password.
Other considerations
You should also consider the following when choosing Anonymous authentication.
Sites containing personalized content only
If you are designing a site that is providing personalized content only, Anonymous authentication may be a good choice. An example of this is a news site that provides local information based on a user's zip code but does not require the user to explicitly log on. The personalization functionality can be performed using cookies separately from authentication. For further information about cookies, see the Cookies section later in this document.
Impersonation
When using Anonymous authentication, the application thread will run as either:
* The built-in anonymous Internet account, IUSR_MACHINENAME.
* The account configured in IIS for the anonymous user.
* The IIS system account.
If your application is using other resources, such as COM+ components, databases, message queues, or UNC file shares, you will need to enable the appropriate permissions for the anonymous user. If this is the case, consider the following options:
* Set up a domain controller that includes all of your Web and application servers. Configure the anonymous user to run as a domain user with the appropriate permissions for resource access. This method will give you easier manageability because your account management is centralized.
* If you are not running in a domain, you can create a user with the same name and password on each of the Web and application servers. This is not recommended due to the complexities with duplicate account management.
Performance
Having an anonymous Web site and not using ASP.NET impersonation will give you the highest performing, but the least secure, application configuration.
Implementation
To implement Anonymous authentication, configure IIS for Anonymous authentication and configure the appropriate anonymous user account. Configure ASP.NET using the Web.config file to use no authentication.
Copy Code
// web.config file
Basic Authentication
When IIS is configured for Basic authentication, it instructs the browser to send the user's credentials over HTTP. Passwords and user names are encoded using Base64 encoding. Although the password is encoded, it is considered insecure due its ability to be deciphered relatively easily. The browser prompts the user with a dialog box, and then reissues the original anonymous request with the supplied credentials, including the user name and password. A pop-up logon dialog box may or may not be appropriate, depending upon your user interface design requirements. Most Internet browsers support Basic authentication.
Typical usage scenarios
You should consider Basic authentication when:
* Your users have Windows NT Domain or Active Directory accounts.
* You need to support multiple browser types, including Netscape Navigator and all versions of Internet Explorer (including the Pocket PC and Windows CE platforms).
* You need to support authentication over the Internet.
* You need to access the clear text password in your application code.
* You need to support delegation.
You should not consider Basic authentication when:
* You require a secure login and are not using a secure channel, such as that provided by Secure Sockets Layer (SSL).
* Your users are stored in a custom database, and do not have Windows accounts.
* You require a customized form presented to the user as a login page.
RSS Feed (xml)
No comments:
Post a Comment