Skip to main content
Logo

Website authentication and security

This article will take you through some of the ways in which you can set up authentication and secure your website.

Prerequisites

  • The server carrying out authentication must be able to communicate back to the CMS database and the CMS config setting Contensis_Data_HasContensisDatabaseAccess needs to be set to true.
  • If you want to authenticate using Active Directory (AD) then the server carrying out authentication must be part of the domain.

General setup

The setup of the website authentication is limited to 3 or 4 settings that are specified for a publishing server. These settings tell the server how to deal with authentication. Authentication needs to be handled in many different ways, and depending upon the way depends upon how these settings need to be set.

Assign permissions

For a user to view a piece of content on the delivery server with authentication enabled for that piece of content, you must add permissions for them to view the piece of content against the user they are using to authenticate. Folder permissions are not used for authentication, content type and template permissions against a folder are used.

It is also worth noting that if you have configured permissions, any anonymous user is called Public User. This means that any user who visits your site will in effect be logged in as the Public User.

Typical scenarios

The solutions to both of the scenarios below require you to change CMS Config settings, these can be found in the Management Console > Project Setup > Publishing Servers. Each publishing server has a link next to it to edit the CMS Config. We suggest that you open this screen when running through these examples.

I want to authenticate a small section of my site

In this scenario we have a general purpose informational website with 3000 web pages. All of the information held in the informational sections is publicly available but the site requires two small areas to be authenticated for accessing order information and for accessing a backend extranet.

The first thing we would identify is that if we have 3000 pages of information that are publicly available, we are going to need to enable Anonymous access this can be done by simply setting Contensis_authentication_allowAnonymous to true .

The next thing we would note is that we certainly don’t want to ignore permissions as we have a section that is enabled for permission checking so we will set Contensis_authentication_ignorePermissions to false. This setting is only normally useful if you are running a secure site and you want to temporarily turn off permissions without changing all your other configurations, or if you have specifically added some code to force permissions checking outside of the configuration settings.

We do not want to turn on authentication everywhere on the site so we are going to set Contensis_authentication_ForceAuthentication to false.

We do want to authenticate the extranet directory and the customers directory so we will modify the Contensis_authentication_inclusions setting and set the value to /extranet/*,/customers/*. The asterisk is required here as it will include the named directories as well as all sub directories.

We don't want to authenticate any of the resources within the customers or extranet directory so we need to check the permissions on these directories and add the public user to have permissions to these resources. You may think, why not simply change Contensis_authentication_exceptions and set it to *.axd,*.css,*.gif,*.png,*.flv,*.swf,*.js. The problem with this is that an inclusion overrides an exclusion so this would not be possible. In this example /customers/test.jpg would be authenticated whether you set it in the exceptions of not because the whole of /customers/ is already included and an include outweighs an exclude.

I want to authenticate my entire site

In this scenario we have an Intranet consisting of 2000 web pages. All of the content requires authentication as the information is sensitive and only for internal use. The only exception to this is the login and access denied screens.

The first we would identify is that none of our content will be accessible by users who aren't logged in, this can be achieved by setting Contensis_authentication_allowAnonymous to false.

We do want to turn on authentication for every part of the site so we are going to set Contensis_authentication_ForceAuthentication to true.

As above, the next thing we would note is that we certainly don’t want to ignore permissions as the entire site requires authentication so we will set Contensis_authentication_ignorePermissions to false.

There are 2 pages in the entire site that we need people to be able to view without being prompted for authentication, these are the login page and the access denied page. The access denied page automatically gets added to the exceptions, therefore the only exception we need to add is the login page, to set this you need to update Contensis_authentication_exceptions and set it to /account/login.aspx.

Set up AD logins for your published sites

Assuming you have followed the steps above and you have Active Directory Synchronisation configured correctly then AD users who are synchronised with Contensis will be able to log in to the site using the standard log on controls. By default Contensis is configured to allow mixed authentication i.e. Contensis Users and AD Users.

Note: the web server carrying out the authentication needs to be part of the domain.

Access denied and login pages

Handling the access denied page and login page is fairly straight-forward, all you need do is configure the Contensis_authentication_AccessDeniedUrl and  Contensis_authentication_DefaultLoginUrl settings to point to the relevant pages.

The login page would have the Contensis log on control on the page and the access denied page would have some text explaining that the user doesn't have permissions to access the content they are trying to access.