Authenticate and authorize

The Optimizely Content Management System (CMS) supports several different authentication and authorization systems, see Security. For details about the provider model, see the Introduction to Membership section at Microsoft MSDN.

Terminology

The system uses Authentication and authorization to identify users and user groups and determine what they are allowed to do.

• Authentication – The process of identifying a user, usually with a username and a password.
• Authorization – The process of determining the specific actions a user is allowed to perform.
• Provider – A module ASP.NET calls to provide an underlying service.
• Membership provider – This module handles authentication in the security model in ASP.NET.
• Role provider – The module that gives the base data for authorization in the security model in ASP.NET.
• Personalization – The process of adapting a web page to a specific user, such as showing targeted ads or displaying the user's 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 CMS has the following advantages:

• Conforming to a standard API – The provider model for membership and roles lets you plug in a provider for any type of user database, even using third-party providers.
• Separation of authentication and authorization – Authentication and authorization occur in two separate operations, increasing flexibility.
• Increased scalability – Because you call out to a provider, you can delegate security operations to a separate machine so 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 CMS.
• Support standard ASP.NET controls – Using the built-in provider model, you can use the built-in controls such as System.Web.UI.WebControls.Login and LoginView.
• Leverage existing knowledge and documentation – If you already know how to work with ASP.NET, you do not need to. There is no need to learn a new security system.

Configure membership and role providers

Configure membership and role providers in web.config. If you change providers, you might revise the security settings (ACLs) for your entire site because it is likely that user names and role names change when you switch providers. The Windows Role and Membership provider is the default when you install CMS.

The following example shows the role and membership configuration section in web.config:

<roleManager enabled="true" defaultProvider="WindowsRoleProvider"> 
  <providers>
    <clear />
    <add name="MultiplexingRoleProvider"
         type="EPiServer.Security.MultiplexingRoleProvider, 
           EPiServer.Framework.AspNet"
         provider1="SqlServerRoleProvider"
         provider2="WindowsRoleProvider"
         providerMap1="SqlServermembershipProvider"
         providerMap2="WindowsMembershipProvider" />
    <add name="WindowsRoleProvider"
         applicationName="EPiServerSample"
         type="EPiServer.Security.WindowsRoleProvider, 
           EPiServer.Cms.AspNet" />
    <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.Framework.AspNet"
         provider1="SqlServerMembershipProvider"
         provider2="WindowsMembershipProvider" />
    <add name="WindowsMembershipProvider"
         type="EPiServer.Security.WindowsMembershipProvider, 
           EPiServer.Cms.AspNet"
         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. Although there are three providers listed in the <providers> section, only the WindowsMembershipProvider is active,(controlled by the defaultProvider attribute of the <membership> tag). For example, you can remove the <add ...> lines for MultiplexingMembershipProvider and SqlServerMembershipProvider without affecting the functionality, unless you have selected the MultiplexingMembershipProvider as the default provider, which makes use of additional providers as defined by the provider\<n> attributes.

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

When you select the provider to use, you decide which user database that CMS authenticates its users against. You can change the provider at any time, but this may force you to revise the security settings in CMS.

📘

Note

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.

Administer security and access rights

When you administer access rights to pages in CMS, you will use some distinct components that are loosely connected, which causes 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 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. When you have a security entity in an ACL, it is not affected by membership or role provider changes. 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, it still displays the role in the ACL.

Membership providers have APIs for creating, editing, and deleting users, but not all providers support updating the user database. The SQL membership provider lets you modify the user database, but the Windows membership provider does not. This is reflected in the UI when you browse users.

If you use the Multiplexing membership provider and want to create users, then the first provider in the multiplexing list (provider1) must support it. The same applies to role providers.

Recommended access rights settings

See the Optimizely User Guide for recommended access rights settings.

Enterprise configuration issues

You cannot configure the membership and role provider definitions per site if you run in an Enterprise configuration with multiple-site definitions. If you must have separate provider definitions for each site, a restriction in the Microsoft implementation of ASP.NET (and not in CMS) is that you cannot share the web.config file.