What to Do

To avoid the performance overhead of using SSL across your entire site, consider using a separate folder to help protect pages that require authenticated access. Configure that folder in IIS to require SSL access. Those pages that support anonymous access can safely be accessed over HTTP connections.

Why

Using SSL across an entire site can incur a significant performance penalty. For sites that have pages which may be viewed without encryption or authentication, it will improve performance to separate out restricted from non-restricted pages.

When

This technique should be employed whenever an application has a mix of pages - some of which require authentication while others don't.

How

To avoid having to use SSL across your entire site, structure your Web site so that the secure pages that require authenticated access are placed in a subdirectory that is separate from the anonymously accessible pages. Perform the following actions to secure pages in a separate subfolder:

1. Enable SSL. In Microsoft Internet Information Services (IIS), configure the secure folder to require SSL. This sets the AccessSSL=true attribute for the folder in the IIS Metabase. Requests for pages in the secured folders are successful only if HTTPS is used for the request URL.

2. Require authentication. Use an <authorization> element to ensure that only authenticated users can access secure pages. Place this element beneath the closing </system.web> tag, as shown here.

   <!-- The secure folder is for authenticated and SSL access only. -->
   <location path="Secure" >
     <system.web>
       <authorization>
         <deny users="?" />
       </authorization>
     </system.web>
   </location>  

   Additionally, the following configuration ensures that unauthenticated users are allowed to access pages in the application's root directory. Place this configuration in the main <system.web> element.

   <system.web>
     <!-- The virtual directory root folder contains general pages.
          Unauthenticated users can view them and they do not need
           to be secured with SSL. -->
     <authorization>
       <allow users="*" />
     </authorization>
   </system.web>  

   Note: If you use this type of site structure, your application must not rely on the user's identity on the non-SSL pages. In the preceding configuration, no forms authentication ticket is sent for requests for non-SSL pages. As a result, the user is considered anonymous. This has implications for related features, such as personalization, that require the user name.  

Adapted from Microsoft patterns & practices guidance.