This document was copied from MSDN here.
Jeff Kercher, Author
Summary: This article discusses the importance of security considerations when designing a server application. Both Microsoft Internet Information Services (IIS) and ASP.NET provide security models that will allow you to authenticate your users appropriately and obtain the correct security context within your application. (29 printed pages)
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.
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:
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.
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:
To enable a specified authentication provider for an ASP.NET application, you must create an entry in the application's configuration file as follows:
// web.config file <authentication mode = "[Windows/Forms/Passport/None]"> </authentication>
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.
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:
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:
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
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 <processModel> element to the root configuration file (machine.config), located in the \WINNT\Microsoft.NET\Framework\Version\Config folder, as shown below:
<system.web> <processModel enable="true" username="domain\user" password="pwd"/> </system.web>
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.
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:
For information about authentication in IIS 5.0, see the article Internet Information Services 5.0 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:
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
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 should not consider Anonymous authentication when:
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.
When using Anonymous authentication, the application thread will run as either:
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:
Having an anonymous Web site and not using ASP.NET impersonation will give you the highest performing, but the least secure, application configuration.
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.
// web.config file <system.web> <authentication mode="None" /> </system.web>
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:
You should not consider Basic authentication when:
You should also consider the following when choosing Basic authentication.
Delegation using Basic authentication
You can delegate from one computer to another (but not beyond) using Basic authentication. Delegation happens because the IIS server will log on the user locally via a call to the Win32 API LogonUser. Because IIS has the clear text password of the user, it can respond to challenges from remote computers, allowing the Web server to act on behalf of the client. If you need to delegate security context to other computers (beyond a single hop), you will have to log on locally to the other computers in the call chain. It is possible to do this using Basic authentication because you have access to the user name and clear text password, which you can pass to other applications such as those based on ISAPI or CGI.
Making Basic authentication secure
It is important to remember that the password can be deciphered relatively easily, so you should limit the use of Basic authentication to non-secure, or at most, semi-secure applications when used by itself.
You can secure Basic authentication by combining it with SSL. This will prevent passwords from being deciphered. This combination of Basic authentication coupled with SSL is used by many Internet applications in production today.
To implement Basic authentication, configure it within IIS and make sure that your users have the "log on locally" privilege on the Web server. If your ASP.NET application needs to run as the user authenticated by Basic authentication, use the following Web.config file configuration.
// web.config file <system.web> <authentication mode="Windows" /> </system.web>
Digest authentication is new to Windows 2000 and IIS 5.0. This form of authentication encrypts the user's password information and provides a mechanism that helps prevent some common server attacks (such as a replay attack). Digest authentication does not send the credentials over the network using clear text as Basic authentication does. Instead, it uses a hashing mechanism called MD5 developed by RSA. (For details, see "The MD5 Message-Digest Algorithm" at http://www.ietf.org/rfc/rfc1321.txt.) Although it is a viable authentication option for Internet scenarios, the client and server requirements limit its widespread use. Unlike Basic authentication, and in a similar fashion to NTLM and Kerberos, IIS does not log on the user locally to the Web server so you cannot perform delegation.
Typical usage scenarios
You should consider Digest authentication when:
You should not consider Digest authentication when:
You should also consider the following when choosing Digest authentication.
Making Digest authentication secure
The intent of Digest authentication is to provide a more secure means of logging on than that provided by Basic authentication. However, it is not as secure as Basic authentication coupled with SSL, NTLM, Kerberos, or Certificate authentication.
The use of Digest authentication over SSL is a secure solution; however, its deployment requirements currently limit its widespread usage.
Specific platform requirements for Digest authentication
Digest authentication requires that clients run using .NET or Internet Explorer 5.x. User accounts must be stored in Active Directory, which must be configured for Digest authentication.
You must configure IIS for Digest authentication. For more information see the Microsoft Knowledge Base article Q222028, Setting Up Digest Authentication for Use with Internet Information Services 5.0.
If your ASP.NET application needs to run as the user authenticated by IIS Digest authentication, use the following Web.config configuration:
// web.config file <system.web> <authentication mode="Windows" /> </system.web>
To use Digest authentication in Windows 2000, the server must have access to an Active Directory server that is set up for Digest authentication.
For more information about Digest authentication, see the specification RFC 2069 at http://www.ietf.org/rfc/rfc2069.txt.
Integrated Windows Authentication
Integrated Windows authentication (using either NTLM challenge/response or Kerberos) involves authenticating a user with a Windows NT Domain or Active Directory account. Unlike Basic and Digest authentication, the encrypted password is not sent across the network, which makes this method very secure. If Active Directory Services is installed on the server and the browser is compatible with the Kerberos V5 authentication protocol, both the Kerberos V5 protocol and the challenge/response protocol are used; otherwise only the challenge/response protocol is used. It is best suited for an intranet environment, where both user and Web server computers are in the same domain and where administrators can ensure that every computer is running Microsoft Internet Explorer version 3.01 or later.
Typical usage scenarios
You should consider Integrated Windows authentication when:
You should not consider Integrated Windows authentication when:
You should also consider the following when choosing Integrated Windows authentication.
Security level of NTLM and Kerberos
Both of these protocols are considered highly secure. With NTLM and Kerberos, the password is not transmitted over the network. NTLM uses a challenge/response mechanism. Kerberos is considered even more secure because it supports mutual authentication (that is, clients can verify the server with which they are communicating).
The NTLM protocol does not support delegation. After the client's credentials are passed to the IIS server, they cannot be passed to a back-end server for authentication. However, Kerberos supports delegation, which allows the client credentials to be delegated to other processes on multiple downstream computers. For example, you can use Kerberos to present a Web user's credentials to a COM+ middle tier and through to a Microsoft SQL Server™ database, configured with Windows Integrated Security. Kerberos authentication is not enabled in a default Active Directory configuration. You must ensure your environment will support Kerberos before depending on it as a delegation solution.
Neither the NTLM nor Kerberos protocols are commonly used over the Internet. The key issue with using Kerberos over the Internet is that the security authority needs to be centralized and available to all users. The infrastructure needs to be in place to do this. Another issue with Internet deployment is that these protocols are not supported by non-Microsoft browsers, which may be a limiting factor depending on your particular client base.
Performance and scalability
Kerberos is faster than NTLM. However, both of these protocols are not as fast as Basic authentication or certain custom authentication methods. If you are expecting large numbers of users to log on concurrently, you need to carefully design your Active Directory configuration. Where you have potentially millions of users, you may consider using a high-performance database such as SQL Server to store your user names and passwords. If you are delegating security context in a multi-tier application, it is likely that you will run into scalability issues. Specifically, middle-tier solutions such as database connection pooling cannot be used.
To implement Kerberos or NTLM, you will need to configure IIS to use Integrated Windows authentication. If you need to support clients other than those running Internet Explorer, you may want to enable Basic authentication in conjunction with NTLM or Kerberos.
You need to consider these specific details when configuring Kerberos:
If your ASP.NET application needs to run as the user authenticated by IIS using Integrated Windows authentication, use the following Web.config configuration:
// web.config file <system.web> <authentication mode="Windows" /> </system.web>
For more information about using Kerberos, see:
A certificate is a digital "key" installed on a computer. When the computer tries to access a server, the key will be automatically presented to authenticate the user. Client certificates can be mapped to Windows accounts in either a Domain or Active Directory. If you use the Windows Authentication Provider in ASP.NET, the application thread will run as the user to which the certificate is mapped. You may also implement custom authentication in ASP.NET where, for example, you could use the e-mail address (or a similarly unique field) contained within the certificate. From the client's perspective, security is seamless as the client is not required to log in using a logon page. This makes certificates an attractive option for automated business processes.
Typical usage scenarios
You should consider Certificate authentication when:
You should not consider Certificate authentication when:
You should also consider the following when choosing Certificate authentication.
You will need to physically deploy the client certificate to the client workstation. There are different methods of doing this, ranging from a Web deployment to installing the certificate from a CD-ROM. The deployment issues are generally the reason why certificates are not as common as other authentication modes that are used in conjunction with SSL.
Mapping to Windows accounts
It is possible to map certificates to Domain or Active Directory accounts. If you need to authenticate individual users, you can use a technique known as one-to-one mapping where a certificate is mapped to an individual account. There is no limit on one-to-one mapping if you use Active Directory mapping.
If you need to authenticate all of the users from a particular group or organization, you can use many-to-one mapping where, for example, any certificate containing a common company name is mapped to a single account.
For example, consider the following B2B scenario:
For more in-depth information about certificates, see the book Designing Secure Web-Based Applications for Microsoft Windows 2000 by Michael Howard.
You must configure IIS for Certificate authentication. For information about mapping public key certificates to Windows 2000 user accounts, see the Step-by-Step Guide to Mapping Certificates to User Accounts.
Passport authentication is a centralized authentication service provided by Microsoft. When you use Passport, you do not need to implement your own authentication code, logon page, and user table in some cases. Passport works using a cookie mechanism. If clients have previously authenticated to Passport, they are allowed access to your site. If not, they are automatically re-directed to the Passport site for authentication.
Passport is a good choice if you require single sign-on capability across multiple domains that also support Passport. Passport provides additional services beyond its role as an authentication service, including profile management and purchasing services.
On the Windows 2000 platform, there is no direct integration of Passport to any authentication and authorization mechanisms built into the operating system. While the .NET Framework does check for Passport cookies, if you maintain your own user database, you must implement your own code to map the Passport user to your own user, as well as implement your own authorization mechanism.
Typical usage scenarios
You should consider Passport authentication when:
You should not consider Passport authentication when:
You should also consider the following when choosing Passport authentication.
Using Passport authentication requires site registration with the Passport service and installation of the Passport SDK on the server.
On Windows 2000, it is not possible to delegate a user's Passport security credentials from one server to another.
Mapping to user accounts
The Passport User ID (PUID) is an identity only. If your user accounts are defined within Active Directory or any custom database, and you need to map the PUID to a user, you will need to implement your own custom code. Future versions of Windows may provide native support of mapping PUIDs to Windows accounts.
Making Passport secure
The nature of the encrypted cookie makes Passport secure when used as a stand-alone authentication method. However, to avoid replay attacks and to maintain the highest-security level, Passport needs to be used in combination with SSL.
To implement Passport, you need to install the Passport SDK on the server. You also need to register with Passport to use the service. You must configure your web.config file as follows:
// web.config file <system.web> <authentication mode="Passport" /> </system.web>
For more information about the Passport service, see:
Forms authentication refers to a custom user interface component that accepts user credentials; for example, a user name and password. Many Internet applications used today present such forms for users to log on. It is important to note that the form itself does not perform the authentication and is provided solely as a way of obtaining the user credentials. The authentication is performed by accessing the user name and password database using custom code.
When the user is authenticated, the server typically gives the client some means to indicate that it has already been authenticated for subsequent requests. If required, you can force the client to authenticate upon every request, although this impacts performance and scalability. There are two basic approaches that you should consider to identify a client who has previously logged on:
Cookies are widely utilized by Web sites that implement Forms authentication. The initial release of .NET will support only Forms authentication using cookies.
Typical usage scenarios
You should consider Forms authentication when:
You should not consider Forms authentication when:
You should also consider the following when choosing Forms authentication.
Making Forms authentication secure
If users are submitting passwords via the logon page, you can secure the channel using SSL to prevent passwords from being stolen. If you are using cookies to maintain the identity of the user between requests, you should be aware of the potential security risk of a hacker "stealing" the user's cookie using a network-monitoring program. The only true way to make the site completely secure when using cookies is to use SSL for all communications with the site. For most commerce sites, this will be impractical due to the significant performance overhead. With ASP.NET you can have the server regenerate cookies at timed intervals. This policy of cookie expiration is designed to prevent another user from accessing the site with a stolen cookie.
Performance and scalability
You need to consider the performance implications of authenticating users when designing a high-volume Web site. If you expect large numbers of users to log on concurrently, you need to make the credential verification as fast as possible.
If you are using SSL, there is a noticeable performance hit due to the additional encryption steps that must be performed. You may need to separate your servers that are performing the secure logon from the content servers in a Web farm to achieve your performance requirements.
Checking the cookie exists
If you are using .NET, the process to check that a cookie exists is performed automatically. However, without .NET, you have two basic approaches:
If you are using ASP.NET, you can take advantage of the built-in functionality provided by Forms authentication.
Using Forms authentication with Windows accounts
If you are deploying an Internet application and your users have Windows accounts on the server, it is possible to use Forms authentication or Forms authentication over SSL as an alternative to using Basic authentication or Digest authentication.
This may not be a good solution if your application is intranet-based and can already take advantage of Integrated Windows authentication. Your corporate security policy also may not approve of users entering their passwords into an HTML form.
To implement Forms authentication you must create your own logon page and redirect URL for unauthenticated clients. You must also create your own scheme for account lookup. Using ASP.NET, you can use the following Web.config configuration:
// web.config file <system.web> <authentication mode="Forms" /> </system.web>
Because you are implementing your own authentication, you will typically configure IIS for Anonymous authentication.
For information about implementing SSL, see the following articles.
ASP.NET provides a mechanism to create cookies and automatically checks for their existence on client requests. The cookies created by ASP.NET can optionally be encrypted using a triple DES scheme supported by the .NET Framework. You can also implement your own implementation of a cookie provider and use it with Forms authentication.
For more information about cookies, see Information About Cookies.
There are possible size limitations on cookies depending on the browser type. The RFC 2019 specifies a 4 KB limit. Internet Explorer 5 does not impose a size limit. Browsers must have their security settings configured to accept cookies for them to work correctly.
Security for Web Services
A Web service is an application based on the ASP.NET infrastructure that can be invoked programmatically across the Internet. From a security standpoint, you have similar issues as you do when developing an interactive Web site. You also use the same mechanisms to secure a Web service as you do any other ASP.NET resource (such as IIS and ASP.NET authentication providers). However, you should consider these additional factors in your design:
Web Service Authentication
Web services will need to accept user credentials in some manner. If the service is non-interactive, it will need to either obtain the security token of the caller, or it will need to expose the appropriate methods to allow credentials to be supplied. The following authentication methods can be easily used and do not require users to input credentials, making them good choices for programmable Web services:
Potentially, you could also use:
Using Windows accounts and IIS authentication
You need to consider the same issues as described in the Authentication Methods section of this document. This implementation requires the least amount of custom coding and you will be able to authorize access to other resources using Windows ACLs.
Using certificates and Certificate Mapping
When using Certificate authentication, the interaction between the client and server can be seamless; that is, the client will not have to programmatically supply the user name and password. Additionally, this is a highly-secure mechanism. B2B transactions, such as purchase order submissions, provide an ideal scenario for using certificates. If you use Certificate Mapping to obtain Windows user accounts, you can also use Windows ACLs to authorize access to resources.
You can implement Custom authentication solutions. The advantages of these solutions over the Integrated Windows authentication approach are that applications are no longer required to maintain separate Windows accounts for each user. You can also bypass IIS authentication altogether and use your own custom method in your Web service code and optimize it based on application-specific needs.
Possible Custom authentication solutions for Web services include:
Internet Protocol Security
If you know the IP address of the client computer, for example if the client is a Web server invoking business logic encapsulated in Web services on the middle tier, Internet Protocol Security (IPSec) may be a viable option. This method allows you to restrict computers connecting to your Web service based on their IP address.
This is not a viable approach in Internet scenarios, where you do not know your client's IP addresses in advance.
Using Passport with Web services
In some cases, Passport authentication may by used by a Web service for authentication. However, its usage can be limited due to the requirement to redirect non-authenticated clients to the Passport site. Redirection could cause problems for non-interactive clients unless they are programmed specifically to handle the case of being redirected to the Passport server.
After you authenticate the user, you may need to authorize them to access the Web service. The following are several authorization options:
Using Windows ACLs
Using Windows ACLs, you can create file system permissions on specific application files. This solution works if your Web service is authenticating users to Windows accounts and uses impersonation.
Using URL authorization
The URLAuthorizationModule maps users and roles to elements within the URI namespace. This module implements both positive and negative authorization assertions. That is, the module can either be used to selectively allow or deny specific users access to arbitrary elements of the URI namespace, based, for example, on their role membership. The following example grants access to several domain users, while denying it to everyone else.
<configuration> <system.web> <authentication mode="Windows" /> <authorization> <allow users="domain1\user, domain2\user2, domain1\user3 /> <deny users="*" /> </authorization> </system.web> </configuration>
Windows Principal object
The System.Security.Principal namespace within the .NET Framework Class Library (BCL) provides a WindowsPrincipal object to represent the security context under which the code is running. This object is created for you automatically when you use Windows authentication in IIS. It allows you to check the Windows group membership of a Windows user and restrict access accordingly.
Generic Principal object
A Generic Principal object can be created based on your own custom roles. You will use this when you have your own user/role database. The Principal object is populated in the OnAuthenticate event. You may have a custom table mapped to Windows accounts that you map in this event. In any case, you can create a custom Principal object for that particular user.
For returning users who have already been authenticated, you could use a cookie to recreate the Principal object for the returning user.
Roles and method level security
You may need to use method level security to restrict particular methods being called by particular client principals. There are several approaches to this problem.
If you are using Windows accounts, create roles for your users in the form of Windows Groups. Because the ASP thread will be impersonating the client and you will have a Windows Principal object available; use the following approaches:
If you are using a Generic Principal object created from users and roles contained in a custom database:
If you are not using a Principal object, you have other options:
The same delegation issues exist for Web services as for ASP.NET Web sites. To delegate security context to a Web service, you will need to use Kerberos authentication, or you will have to pass the credentials so that Web services running on other computers can call LogonUser if they are Windows servers, or the equivalent authentication API if they are non-Windows servers.
If you connect to a Web service programmatically, you can take advantage of the .NET classes for client connectivity. The supported authentication protocols from .NET clients are:
Code Access Security
To protect computer systems from malicious code and to provide a way to allow mobile code to run safely, the .NET Framework provides a security mechanism called Code Access Security (CAS). While CAS is a .NET security feature, it applies to all .NET managed code such as ASP.NET Web applications. While CAS applies to all managed code, you may need to specifically code with it in mind when:
CAS allows code to be trusted to varying degrees, as determined by security policy, depending on where the code comes from and on other aspects of the code's identity, such as its strong assembly name. CAS reduces the likelihood of your code being misused by other malicious code. It allows you to specifically set the operations your code should be allowed to perform as well as the operations your code should never be allowed to perform. Specifically, CAS supports a permission support mechanism by which code can explicitly request particular permissions and explicitly refuse others that it knows it never needs.
Code access permissions
Code access security relies upon the notion of code access permissions. Each permission represents the right for code to access a protected resource such as a file, directory, or registry entry, or the right for it to perform a protected operation such as calling into unmanaged code. Permissions can be demanded by code and the runtime security policy determines which permissions to grant. For a complete list, see Code Access Permissions.
.NET allows administrators to assign a pre-defined set of permissions to an application. These permission sets vary based on the level of trust accorded to the application. By default, applications receive a level of trust dependent upon the evidence presented about the code's digital signature, origin, and the location of the application.
For example, applications running on a UNC share (running in the Intranet security zone) receive the LocalIntranet permission set. Applications running on the local machine (running in the MyComputer security zone) receive the FullTrust permission set.
ASP.NET Web applications can be further configured by assigning them trust levels. Trust levels are configured using the <trust> element within the configuration file.
<trust level="Full | High | Low | None" originUrl="url" />
Each level determines the application's permissions, the details of which are specified by an XML security policy file. Each level maps to a specific file. The default mappings for ASP.NET are:
Note that Full trust has no associated configuration file as Full trust allows applications to use all resources (subject to operating system permissions), which is just like running without code access security (although CAS cannot be switched off for managed code). You can override these mappings within the <securityPolicy> element of the configuration file and can customize and extend each level. You can also create your own levels that define arbitrary permission sets. The default <securityPolicy> mapping set is shown below.
<securityPolicy> <trustLevel name="Full" policyFile="internal" /> <trustLevel name="High" policyFile="web_hightrust.config" /> <trustLevel name="Low" policyFile="web_lowtrust.config" /> <trustLevel name="None" policyFile="web_notrust.config" /> </securityPolicy>
Locking configuration settings
ASP.NET configuration is hierarchical in nature, with configuration files optionally at the machine, application, and sub-application levels. Sub-level configuration files can be used to override settings made at a higher level or can be used to add additional configuration information. While this provides a high degree of flexibility, administrators may sometimes want to enforce the configuration settings and not allow them to be overridden by specific applications. For example, an administrator of a hosted Web site may wish to specify the code access security level and not allow it to be changed by individual applications. This can be achieved using the <location> element coupled with the allowOverride attribute.
For example, an administrator of a hosted Web site may wish to ensure that no applications are allowed to call into unmanaged code. The following configuration file fragment shows how an administrator could lock down the code access configuration settings for a whole site and restrict applications with the High trust level (which does not allow calls into unmanaged code):
<location path="somesitepath" allowOverride="false"> <trust level="high" originUrl="http://somesite.com" /> </location>
The path attribute may refer to a site or a virtual directory and it applies to the nominated directory and all sub-directories. In the example above, if you set allowOverride to "false", you can prevent any application within the site from overriding the configuration settings specified within the <location> element. Note that the ability to lock configuration settings applies to all settings, and not just security settings such as trust levels.
For more information, see:
Channels transport messages across remoting boundaries, such as AppDomains, processes, and computers. The .NET Framework provides two remoting channels, HTTP and TCP.
You need to consider using a secure channel when you want to protect confidential or sensitive information that is transmitted with these protocols. Using network monitoring software, this information can be easily intercepted and read unless the information is protected using encryption.
The following are some key points of channel security:
For more information, see:
For additional information about the security topics discussed in this document, see the following references.
For more information on securing Web services, see the following references.
For general information on security, see:
Figure 3. Flow chart for determining most appropriate authentication method (Click on image to see larger picture.)
Many thanks to the following contributors and reviewers:
Rob Howard, Erik Olson, Venkat Chilakala, Michael Monteiro (Sapient), Suresh Kandula (Sapient), Chris Brooks, Edward Jezierski, Alex Mackman, Mike Jenne, David Mowers, Amitabh Srivastava, Steve Busby, Kenny Jones.
To learn more about .NET best practices, you can work side-by-side with technology experts at the Microsoft Technology Center in your area. For more information please visit the Microsoft Technology Centers Web page.