Authentication and Authorization (CMS 7)

Introduction
Membership and Role Provider Model
Configuring Membership and Role Providers
Administering Security and Access Rights
Recommended Access Rights Settings
Enterprise Configuration Issues
See Also

Introduction

This document describes the authentication and authorization model in EPiServer CMS. The authentication and authorization system uses the default membership and role system as introduced in ASP.NET. For more details on the provider model, see the “Introduction to Membership” section at Microsoft MSDN.

Terminology

Authentication and authorization is used by the system to identify users and user groups, and determining what they are allowed to do. These are some common terms used in this context:

Authentication. The process of identifying a user. The usual way of doing this is with a username and a password.
Authorization. The process of determining the specific actions a user is allowed to perform.
Provider. A module that is called by ASP.NET to provide an underlying service.
Membership provider. The module that handles authentication in the security model in ASP.NET.
Role provider. The module that gives the base data for authorization in the new security model in ASP.NET.
Personalization. The process of adapting a web page to a specific user. For example showing targeted ads or simply displaying the name of the user.
Profile provider. The module that stores and retrieves personalized data in ASP.NET.

Membership and Role Provider Model

The ASP.NET membership and role provider model used for authentication and authorization in EPiServer CMS has the following advantages:

Conforming to a standard API. The provider model for membership and roles makes it possible to plug in a provider for any type of user database, even using third-party providers.
Separation of authentication and authorization. Authentication and authorization are done in two separate operations, thereby increasing flexibility.
Increased scalability. Since we call out to a provider it is possible to delegate security operations to a separate machine, which means that if you have to support millions of users, you can use any type of system suitable for that volume and call out to that system from EPiServer CMS.
Support standard ASP.NET controls. By using the built-in provider model it is possible to use the built-in controls such as System.Web.UI.WebControls.Login and LoginView.
Leverage existing knowledge and documentation. No need to relearn a new security system if you already know how to work with ASP.NET.

Configuring Membership and Role Providers

Configuration of membership and role providers is done in web.config. If you change providers, you may have to revise the security settings (ACLs) for your entire site, since it is highly likely that user names and role names changes when you switch providers. When installing EPiServer CMS, the Windows Role and Membership provider will be default.

This is an example of the role and membership configuration section in web.config:

XML

<roleManager enabled="true" defaultProvider="WindowsRoleProvider"> 
   <providers>
      <clear />
      <add name="MultiplexingRoleProvider"
         type="EPiServer.Security.MultiplexingRoleProvider, EPiServer"
         provider1="SqlServerRoleProvider"
         provider2="WindowsRoleProvider"
         providerMap1="SqlServermembershipProvider"
         providerMap2="WindowsMembershipProvider" />
      <add name="WindowsRoleProvider"
         applicationName="EPiServerSample"
         type="EPiServer.Security.WindowsRoleProvider, EPiServer" />
      <add name="SqlServerRoleProvider"
         connectionStringName="EPiServerDB"
         applicationName="EPiServerSample"
         type="System.Web.Security.SqlRoleProvider, System.Web, 
            Version=4.0.0.0, Culture=neutral, 
            PublicKeyToken=b03f5f7f11d50a3a" />
   </providers>
</roleManager>

<membership defaultProvider="WindowsMembershipProvider"
   userIsOnlineTimeWindow="10">
   <providers>
      <clear />
      <add name="MultiplexingMembershipProvider"
         type="EPiServer.Security.MultiplexingMembershipProvider, EPiServer"
         provider1="SqlServerMembershipProvider"
         provider2="WindowsMembershipProvider" />
      <add name="WindowsMembershipProvider"
         type="EPiServer.Security.WindowsMembershipProvider, EPiServer"
         deletePrefix="BUILTIN\" />
      <add name="SqlServerMembershipProvider"
         type="System.Web.Security.SqlMembershipProvider, System.Web, 
             Version=4.0.0.0, Culture=neutral,
            PublicKeyToken=b03f5f7f11d50a3a"
         connectionStringName="EPiServerDB"
         requiresQuestionAndAnswer="false"
         applicationName="EPiServerSample"
         requiresUniqueEmail="true"
         passwordFormat="Hashed"
         maxInvalidPasswordAttempts="5"
         minRequiredPasswordLength="7"
         minRequiredNonalphanumericCharacters="0"
         passwordAttemptWindow="10"
         passwordStrengthRegularExpression="" />
   </providers>
</membership>

The <membership> section controls the membership provider to use. Note that even though there are three providers listed in the <providers> section, only one is active at this time, the WindowsMembershipProvider (controlled by the defaultProvider attribute of the <membership> tag). For example, the <add ...> lines for MultiplexingMembershipProvider and SqlServerMembershipProvider could be removed without affecting the functionality. There is one exception to this statement - if you have selected the MultiplexingMembershipProvider as the default provider, it will make use of additional providers as defined by the provider<n> attributes.

Similarily the <roleManager> section controls the role provider to use. The same basic principles of defaultProvider / Multiplexing provider as for membership applies here as well.

When you select the provider to use you are deciding which user database that EPiServer authenticates its users against. As previously stated it is possible to change the provider at any time but this may cause problems, forcing you to revise the security settings in EPiServer CMS.

Also note that the membership and role providers are configured separately, but a specific membership provider may require a certain role provider and vice versa. For the current set of providers you must have matching role and membership providers, for example, if you decide to use WindowsMembershipProvider you must use the WindowsRoleProvider.

Administering Security and Access Rights

When you administer access rights to pages in EPiServer you will use some distinct components that are tied very loosely together. This will cause the UI to show information that may appear confusing. The components are as follows:

Users (delivered by the current membership provider).
Roles (delivered by the current role provider and the virtual roles).
Access control lists (ACLs).

An ACL is simply a list of SecurityEntities and an access level. The security entity is a name and information stating if the name represents a role or a user. Once you have a security entity in an ACL, it will not be affected by changes in the membership or role provider. One aspect of this is that when you delete a role and then look at an ACL that had an access entry for this role, the role will still be displayed in the ACL.

Membership providers have APIs for creating, editing and deleting users, but not all providers support updates of the user database. The SQL membership provider allows you to modify the user database, but the Windows membership provider does not. This will be reflected in the UI when you browse users.

Note that if you are using the Multiplexing membership provider and want to create users, then the first provider in the multiplexing list (provider1) must support it. The same applies for role providers.

Recommended Access Rights Settings

The following access rights settings are recommended for users who are editing in the system:

Read. Can read published content but have no access rights to view unpublished page versions or the version list.
Read and change. Can edit existing content but not publish it. The user can view the version list and unpublished content.
Read, change and publish. Can edit existing content and publish it.
Read, create and change. Can create new content and edit existing content but not publish it.
Read, create, change and delete. Can create, edit and delete content but not publish it.
Read, create, change, delete and publish. Can create, edit and delete content and publish it as well.
Read, create, change and publish. Can create, edit and publish content but not delete it.
Read, create, change, delete, publish and administer. Have full access rights to do everything.
Read and administer. The user are allowed to view published content as well as set dynamic properties, language settings and access rights for a single page.

A valid site scenario could also be Read, create and publish, which means that a user can contribute with content, for instance to a forum. However, a user with these access rights cannot edit content in the EPiServer CMS user interface since that action requires Change rights.

Enterprise Configuration Issues

If you are running in an Enterprise configuration with multiple-site definitions, there are some security-related issues you should be aware of.

The membership and role provider definitions cannot be configured on a per-site basis. If you must have separate provider definitions for each site, you cannot share the web.config file. This is a restriction in the Microsoft implementation of ASP.NET and not in EPiServer CMS.

If you are using the SQL Server membership / role provider and want to use the same set of users / roles for all sites using the same web.config files (probably the most common scenario), you need to use a separate database for the user / role information.

Create a new database with the SQL Server management tools.
Prepare the new database with the aspnet_regsql tool (part of the Microsoft .NET Framework) to set up the schema needed for the SQL providers.
Add a new connection string to the <connectionStrings> section in web.config (it may be placed in a separate connectionStrings.config file) that points to the newly created database.
Change the connectionStringName attributes of the SqlMembershipProvider and SqlRoleProvider to point to the connection string added in step 3.

See Also

Authentication and Authorization

Table of Contents