Products

Solutions

Resources

Partners

Community

About

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

How to ensure SSL for all authenticated sessions

Return to previous page

  • 4/7/2015
  • 21815 Views

Comments

21815 Views

How to ensure SSL for all authenticated sessions

Last updated 8 years ago

Comments

Common

(Enter the content of this article below)

Advanced

 

This a how to write up that explains how to make sure that all authenticated sessions (anything that happens after a user is logged on) are served using an SSL connection (using the HTTPS protocol)

Step 1: Enable SSL for your website in IIS

I am not really going to explain that here, since this is a very common procedure in IIS. See here for more information about how to do that.

Step 2: Enable SSL for your site in DotNetNuke

DotNetNuke offers a comprehensive way to enable and enforce SSL per website (portal). For this task, it is enough that SSL is enabled for the site. In order to do that, go to Admin > Site Settings, to the Advanced tab, and open the SSL Settings section. In this section, check the option “SSL Enabled?”, and update the settings.
NOTE: You must be logged in as a host/superuser in order to see the SSL section.


Step 3: Create a secure Login Page

By default the automatically generate login page (or popup) for DotNetNuke is not secure. In order to provide a secure login option, you will have to create a separate page, that has a Account Login module on it and that is marked as secure. While you can create this page at every level, and give it any name, most logical would be to create this page at the root level and give it the name “Logon”. Although DotNetNuke will handle everything automatically once you make every necessary adjustment, it gives me peace of mind knowing you are overwriting the automatic URL for the logon page.

NOTE: "Login" is a reserved page name in DNN so you must choose a different name for your custom Login page.

In full, the new Login page needs these properties set:

  • Page name: Logon
  • Root level (no parent page)
  • Permissions: view permissions for all users (or for unauthenticated users)
  • Secure: Secure flag must be set (this will ensure the page is only viewable using the HTTPS protocol, and DotNetNuke will automatically switch to HTTPS for this page)


  • Finally, put an Account Login module on the page.

Step 4: Use the new login page

Without “telling” DotNetNuke to use this new Login page, it will keep using the automatic login option. The Login page is a so called special page which means that the location of this page is stored per Site and can be used by any other process in any module or extension. In order to change the special Login page, go to Admin > Site settings, and open the “Advanced Settings” tab, and select the Page Management section. In this section, at “Login Page” select your newly created Login page, and update the settings.


Step 5: enable RequireSSL

Open up the web.config file for your application, and change the Forms Authentication node to look like this:

<authentication mode="Forms">
<br />  <forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" requireSSL=”true” />
<br />< /authentication>


Caveat

There is one large caveat here. Since the Forms Authentication Cookie setting is done at the application level, in web.config, this solution assumes that you either have just one site configured in DotNetNuke, or that all sites can be secured with the SSL certificate that you applied to the IIS website. This means that potentially you would have to apply multiple SSL certificates to one IIS website.

SSL certificates are usually only valid for one domain, or for one domain and all its sub domains (the latter are so called Wild Card SSL certificates). Or you may be able to obtain a certificate for multiple unrelated domains (so called (UCC or SAN Certificates). The best solution though would be to run under Windows 2012, as this supports Server Name Indication (SNI), which allows you to apply multiple SSL certificates to one website (using different host headers). That is material for another blog post though!

Contents
No sections defined
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out