Kentico CMS allows you to specify which of the website's pages should only be accessible over the secured SSL protocol. When a user tries to open such a page with the standard HTTP protocol, they will automatically be redirected to the secured version of the same page (using the https URL scheme).
Please note: Kentico CMS does not configure your website for SSL/HTTPS. It may only be used to automatically redirect users to the appropriate URL. You need to perform the configuration itself manually using the standard IIS settings, as described in IIS documentation or in this article: http://msdn.microsoft.com/cs-cz/magazine/cc301946(en-us).aspx
In order to specify that a page should only be available through the SSL protocol, you need to go to CMS Desk -> Content and select the corresponding document in the content tree. Then you can choose one of the following options in Properties -> Security -> Requires SSL:
•Yes - users attempting to access the page will always be redirected to the HTTPS version of the page's URL.
•No - users will not be explicitly redirected to a secured URL when they access the page, but the protocol used in the current URL will remain unchanged (i.e. if a user navigates to the page from another page that is secured, this page will also use SSL).
•Inherits - the settings defined for the parent document will be used.
•Never - users trying to access the page through a secured URL will be explicitly redirected to the unsecured version of the page.
You may also configure the same functionality for all pages that belong to the administration interface (CMS Desk and Site Manager). To do this, go to Site Manager -> Settings -> Security & Membership and check the Use SSL for administration interface field in the Administration category.
Now all editors and administrators will be redirected to pages using the https URL scheme when they log in. Please note that this setting is applied to all sites in the system, so it is only available if you select the (global) option from the Site drop-down list.
In some cases, SSL decryption and encryption may not be performed directly by your application's server, but instead via a reverse proxy, such as an SSL offload device (for example an SSL accelerator in a load balanced web farm scenario). This means that requests are forwarded to the application internally using the standard HTTP protocol, even when the client accesses the page through HTTPS. If the settings described in the sections above are enabled for the website, it may result in a redirection loop.
You can solve this issue by adding custom code to the application's request handlers. It is necessary to appropriately set the IsSSL static property of the CMS.GlobalHelper.URLHelper class. If set to true, the system will treat all requests as secured, regardless of their URL format, and redirection to HTTPS page versions will not be performed by the application. Of course, it is necessary to correctly identify which requests originally used SSL, e.g. by checking the request headers.
1. Open your web project, expand the App_Code folder (or Old_App_Code if you installed the project as a web application) and add a new class called SSLRequestLoader.cs.
2. Edit the class and add the following references:
3. Delete the default class declaration and its content. Instead extend the CMSModuleLoader partial class and define a new attribute for it as shown below:
4. Enter the following code into the SSLRequestLoaderAttribute class:
The override of the Init() method (executed automatically when the application starts) is used to assign a handler that will be called before each request is processed.
This example uses the X-Forwarded-Ssl header to check if the original request was submitted via HTTPS before it was forwarded to the application by the SSL offload device or load balancer. If this is the case, the IsSSL property is set to true and the system will process the request as if it used the HTTPS protocol.
The proxy device may use a different method to identify requests that were originally secured by SSL, so you will have to write a condition that fits your specific scenario (another typical approach is to check if the value of the X-Forwarded-Proto request header is https). You may also include additional custom code to fulfill any other security requirements, such as validation of the proxy's IP address.