EPiServer CMS Operator's Guide

The authentication mechanism you choose in IIS depends on the authentication you use in ASP.NET. If you use forms authentication, as we recommend, you should only allow Anonymous access, as IIS is not responsible for authentication then.

If you use Windows authentication in ASP.NET, you should configure IIS for Basic Authentication or Integrated Authentication. Integrated Authentication cannot normally be used over firewalls, which is why it is normally only an alternative for intranets.

Refer to the white paper, "Security in EPiServer CMS" for a more detailed description, including the advantages and disadvantages of using certain authentication mechanisms.

EPiServer CMS 4 is a pure ASP.NET application and does not require any settings other than the standard settings. It is, however, advisable to secure directories so that certain file types are not allowed in certain directories. The ground rule is to only allow Read permission in directories with downloadable files, like images, and only Script permission in directories with script files, e.g. ASP.NET files. This is so that the code can only be executed and not read. An exception is that IIS 5.0 requires Read permission to be set on a directory in order for a default document to work, e.g. default.aspx. This mainly applies to the admin, edit and root directories.

Our recommendations for directory settings can be found in the table below:

EPiServer CMS uses an adapted error page for "404 Not Found" to handle requests for directories that only exist in EPiServer CMS and not in the file structure. The page stated here is /Util/NotFound.aspx as standard. This is not a requirement and can be directed to any ASP.NET page without disturbing the EPiServer CMS functionality.

It is standard for all uploaded files to be publicly available for visitors, i.e. there is no access check or dependence on the page's publication status. This is because the files are delivered directly from IIS and not via EPiServer CMS. This is acceptable in most cases, that is to say if you do not work with sensitive information, e.g. on extranet, or information that may not be publicly available before the publication date.

It is possible to configure uploaded files to be managed by EPiServer CMS instead, where you can set the access rights on directories directly from file management in Edit mode. You can also configure so that the page's directory inherits the same access rights as the page. This is so that documents will not be available before the page is. The EPiServer CMS file functions are called Unified File System and the configuration is described in detail in the Technical note, "Unified File System".

When Unified File System is set up, all files are moved to a protected directory, publicly unavailable from Internet, in the operating environment. All links that, for example, point to upload, will continue working as EPiServer CMS takes over all file access to this directory and handles access control. It is possible, for example, to give certain editors access rights to change in certain directories, or only extranet users access to a particular directory.

ASP.NET Configuration

This chapter focuses on some important points concerning the general operation of the ASP.NET environment, some of which are related to EPiServer CMS.

Sessions

EPiServer CMS does not use sessions, neither in Edit nor Admin mode. If the templates on the Web site do not use sessions either, you can inactivate them, so as not to unnecessarily use server resources. Do this by setting the mode attribute to "off" in web.config under the sessionState part. See Microsoft KB Q306996 for more detailed instructions.

If a Web site saves information that is critical to the company in sessions, e.g. a shopping basket on a shopping site, you should consider not saving sessions in the ASP.NET process as is standard. You can choose to isolate the sessions handling to a state server, or to a database. See Microsoft KB Q311209. The advantage is that information in sessions will not be lost when ASP.NET or the IIS restarts. The disadvantage is that they negatively affect performance.

Timeout for Logout

If the Web site uses forms authentication, the users that are logged on will be automatically logged out by .NET after a certain period of inactive time. This period of time can be changed in web.config by setting the timeout attribute, which states timeout in minutes, on the forms part under authentication.

Release Mode

Make sure that the .dll files in the bin directory that belongs to the Web site are compiled in Release mode. A .dll file that is compiled in Debug mode is larger, uses more memory and is slower than the one compiled in Release mode.

Dynamic pages and user controls also have script-like code, which is compiled when needed by ASP.NET. In order for this to be compiled in Release mode, change web.config by changing the value for the debug attribute to "false". If it is a problem that pages compile when required, e.g. loss of performance, you can also state that all the pages should be compiled at once during compilation. This is done by setting the batch attribute to true.

EPiServer CMS Configuration

The EPiServer CMS installation program automatically applies a configuration template at first time installation. This, among other things, sets file access rights and certain settings in IIS. Refer to the EPiServer CMS Configuration Tool chapter for further information.

All settings configured by an administrator are saved in the web.config file. Some of these settings are also available in Admin mode under System settings and can also be displayed for all installed EPiServer CMS sites in EPiServer CMS Manager.

Roles and Authority

In web.config, you can define which roles will have access to which parts of EPiServer CMS. There are mainly two parts that need to be secured: Edit and Admin. These are limited to the roles WebEditors and WebAdmins as standard, but these settings can be changed as you wish. A role is normally the same as a group, if you log on with Windows or an EPiServer CMS user.

Encrypt web.config

EPiServer CMS has built-in support for encryption of sensitive information in web.config. From System Settings in Admin mode, select the Encrypt the web.config file check box to encrypt the information for the database connection, which also has a database login and password, and the user information to connect to the LDAP server. These settings will be saved in encrypted format.

You can also enforce encryption of approved settings in web.config under the <appSettings> section, by editing web.config in a text editor. To activate encryption for a setting, add the text ENCRYPT in the value attribute before the value in question, e.g. to encrypt the Upload directory (EPsUploadDir), change

to

Go to System Settings and save the settings. If you now look in web.config, you will see that the line has changed to

Note that, for security reasons, EPiServer CMS will never save settings that have been encrypted once as decrypted. That is to say that if you have encrypted settings once, you can only view them in plain text in web.config by editing the file by hand and entering the required values.

If you encrypt information in web.config, it will only be available in plain text via the EPiServer CMS configuration object and not via ASP.NET's built-in configuration object. We recommend that developers always use the built-in object in EPiServer CMS.

Cache

EPiServer CMS has several built-in cache functions, some of which are activated as standard and others, which must be activated manually. A correctly setup cache is extremely important for good performance.

Pages and page listings are cached internally, so that an API call from a dynamic page will not result in unnecessary database calls. If access to a page does not take place during a 12-hour time period, the page will be removed from the cache. At the next access, it will be read from the database again.

The length of this time period can be changed in web.config via the EpnPageCacheTimeout setting. If this value is changed to "0", the cache will be turned off. This may be useful when searching for errors, but is not recommended for operation. The performance is considerably affected if this cache is turned off.

If several users request the same page information at the same time, and this information is not already in the page cache, there may be several parallel reads from the database whilst the cache is being populated. This can negatively affect performance, if there are a lot of pages to be read, e.g. listings and tree structures. Parts or all of the cache are repopulated when changes occur, or if the application has just started.

To avoid this happening, EPiServer CMS uses optimistic locking management. This means that if a page is already being read to the cache, the next request for the same page will wait for the previous read to be completed. Two configurable parameters in web.config are used for the wait function: EPnCacheSpinlockCount and EPnCacheSpinlockTimeout. If nothing is stated in web.config, SpinlockCount will be 10 and SpinlockTimeout 1000 — timeout is stated in milliseconds — which is optimal in most cases.

An indication that these parameters may need trimming is if you listen to the traffic to the database server and see a large amount of calls to stored procedures netPageDataLoad and/or netPageListLoad with exactly the same ID parameters. Note that this may also be a sign that the cache is turned off. If this is not the case, try increasing SpinlockCount and decreasing SpinlockTimeout. Make sure that SpinlockCount * SpinlockTimeout is not more than 10 seconds, as the product of this is the maximum time for reading to the cache to be completed.

A dynamic page can be cached as a static HTML file on the server. These functions in EPiServer CMS are built around the output caching concept in ASP.NET. Output caching is only suitable for Web sites with many anonymous visitors, and is not standard for this reason. EPiServer CMS has its own functions that ensure that output cache is not activated for users that are logged on, as different users see different content depending on access rights and personalized information. Output cache is only activated by EPiServer CMS for common page requests of type "GET", and not for postings ("POST").

A page is normally built up with information from several other pages in EPiServer CMS, e.g. news listings and tree structures. All changes (publications) from Edit mode will, for that reason, delete all the information that EPiServer CMS has placed in the output cache. That is to say that the cache will be reloaded the next time a page is accessed. If templates contain data that vary over time, e.g. a server-generated clock, you must state how long the page can be cached as HTML, so that the information, in this case the time, will not be incorrect.

Set EPnCachePolicyTimeout in web.config to activate output cache. This states how many seconds a caching is valid. To achieve the best performance, you should have, on average, more than one hit per unique page during the period of time (EPnCachePolicyTimeout). Otherwise it is just an unnecessary load for the server, as the cached variant will probably never be read. The recommended setting is at least 3600 seconds or 1 hour.

The output cache varies based on the Web browser type and the page ID. These values can, however, be customised in EPsCacheVaryByCustom and EPsCacheVaryByParams. If an installation has, for example, a query string parameter "print" that controls how the page is adapted for printout, EPsCacheVaryByParams must be changed to "id,print".

Information concerning the roles that a user belongs to, along with personalized information, is read when a user logs on. This data is cached, so that the information does not need to be re-read for each new page viewing. User information that is not read for 5 minutes is removed from the cache. The length of this period of time can be changed in web.config via the EPnUserCacheTimeout setting. If this value is changed to "0", the cache will be turned off. This may be useful for troubleshooting, but is not recommended for operation. The main advantage of this cache, from a performance point of view, is obtained when the group membership is read from Active Directory, or another external source that requires more resources than a local database lookup.

Shared Hosting

Shared hosting is when several EPiServer CMS installations or other ASP.NET applications are operated for several customers on the same server.

Roles and Users

In order to cut down on administration, we recommend that each installation/site only has one superuser account created in Windows, and that the customers themselves set up EPiServer CMS users for editors and administrators. The superuser account can then be used for, e.g. FTP access.

The disadvantage of using Windows users, and therefore Windows groups, for role membership is that these apply to the entire server and all sites. That is to say that if two sites use the same groups or roles by mistake, the users can access each other's sites. If you use EPiServer CMS users and EPiServer CMS groups, these will only work per site.

A simple rule of thumb is that, in a hotel environment, the standard groups WebEditors and WebAdmins should never exist in the Windows account database. If the general groups exist, you cannot add users to them. Only operators, for example, who need to access several sites can add users.

It is possible to remove the Write access rights for the ASP.NET account and only allow the superuser account to write to the web.config file. This will result in only the superuser account being able to save new System settings and not common EPiServer CMS users.

Limitations in Windows 2000

ASP.NET uses a general account that the ASP.NET processes run under. This cannot be changed per site in Windows 2000. This causes a security problem, as a site could, code-wise, be able to access information from another site. Unfortunately there is no good solution for this, as it depends on Windows 2000 architecture. Microsoft Windows 2003 Server, which has a new process model in Internet Information Server 6.0, solves this problem. Windows 2003 Server is, therefore, recommended for all types of ASP.NET shared hosting. Make sure first that your EPiServer CMS version supports this platform.

EPiServer CMS Configuration Tool

The installation program automatically applies a configuration template at first time installation. This, among other things, sets file access rights and certain settings in IIS. There is a tool that is used to be able to run this template and other templates manually. A template is defined in XML format, which contains file access rights, IIS settings and web.config settings. This template can then be run by EPiServer CMS Configuration Tool to apply its access rights and settings on an EPiServer CMS installation. There is currently a base template, which is used at installation. It is, of course, possible to customize this template or build your own templates according to the organization's wishes and security requirements.

Template Syntax

General

The template with settings for a configuration is built up as an XML file containing 3 main parts: file access rights (XML tag acl), Internet Information Server settings (XML tag metabase), and ASP.NET configuration (XML tag web.config). Each main part is placed under the respective location in the structure, when the settings are to be applied (XML tag location). This chapter describes these parts in further detail.

The example above states the path to the admin directory. If you do not state a path by removing the path attribute, the configuration will apply to the root directory. State a new location element for each part that needs to be configured.

The section modifies settings in web.config. There is no limitation to the elements that can be entered here. All elements will be transferred to web.config under the location in question. This function has been tested with the authentication and authorization elements, but should work with all elements.

This section sets access rights (ACL or Access Control List) on files and directories. See the example below:

metabase

Constants