November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
Views: | 23195 |
Number of votes: | 3 |
Average rating: |
This article describes some basic concepts regarding how to configure access rights, users and groups in an EPiServer CMS 6 website. The article is based on the Public Templates demo website which can be downloaded from EPiServer World.
When you install a new website, based on the Public Templates module in Deployment Center, you will only be able to log on by using a local Windows Account that is a member of the Windows Administrators Group (Local Admin). This is the default behavior for websites based on the Public Templates. You will not be able to create any new users or groups, because the selected membership provider does not allow this.
If you take a look in the web.config file (located in the web root for the current website) and search for the words "membership" or "roleManager" you will find that the chosen providers are set to WindowsMembershipProvider and WindowsRoleProvider. Although there are definitions for other providers in the configuration found in web.config, it is the defaultProvider attribute that decides which providers will be used.
The Windows providers don’t allow you to create new users and groups for the following reason. Imagine that you deploy your website on your ISP's web server and then want to create new users and groups. If it was possible to create users and groups by using the Windows providers, this would mean that you created local windows accounts and groups on the ISP's server which is absolutely not acceptable.
More information regarding providers used by EPiServer CMS and the Membership system can be found in the SDK and the WebHelp.
In order to be able to create users and groups in EPiServer CMS 6 you need to change providers for the ASP.NET membership system to SqlServerMembership and SqlRoleProvider (or to your own custom membership providers).
You can easily do this by changing the defaultProvider attribute for membership and roleManager to use the SqlServer providers instead. When this is done you will be able to create users and groups.
<system.web>
...
<roleManager enabled="true"
defaultProvider="SqlServerRoleProvider"
cacheRolesInCookie="true">
<providers>
<clear />
<add name="SqlServerRoleProvider"
connectionStringName="EPiServerDB"
applicationName="EPiServerSample"
type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>
<membership defaultProvider="SqlServerMembershipProvider"
userIsOnlineTimeWindow="10">
<providers>
<clear />
<add name="SqlServerMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.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>
...
</system.web>
The user and group information, when using the SqlServer providers, will be stored in the same database as the EPiServer CMS content (depending on configuration, it can also be separated). If you take a look in the tables prefixed with aspnet_XXXXXXX, you can see the data for the membership system. There are tables for users, groups, profiles, etc.
If you wish to combine two or more membership providers you can do this by using the multiplexing membership providers developed by EPiServer.
The MultiplexingMembershipProvider and MultiplexingRoleProvider are configured to use two or more membership and role providers when the authentication and authorization process occur. If the first configured provider can’t authenticate the user, the request will be passed to the next configured provider. The same procedure will be performed when the user is authenticated in the authorization process.
<system.web>
...
<roleManager enabled="true"
defaultProvider="MultiplexingRoleProvider"
cacheRolesInCookie="true">
<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=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>
<membership defaultProvider="MultiplexingMembershipProvider"
userIsOnlineTimeWindow="10">
...
</membership>
...
</system.web>
Note! It is important to type the correct information in the providerMap attribute so that the system knows which providers belong together.
In a standard installation of Public Templates there are two predefined roles, WebAdmins and WebEditors, which can be used to secure the website regarding access to Edit Mode and Admin Mode. You can see the predefined roles being used in web.config if you look for the location nodes.
The location nodes in web.config is used to create a mapping between a string, e.g. ‘WebAdmins’, and a relative path in the web application and relies solely on standard ASP.NET configuration.
This is a thing that the developers have to consider when creating and configuring the website.
If you take a look in the web.config file, you will see the following configuration for access to the files in Admin Mode for the website.
<system.web>
...
<location path="CMS/UI/CMS/admin">
<system.web>
<authorization>
<allow roles="WebAdmins, Administrators" />
<deny users="*" />
</authorization>
</system.web>
</location>
...
</system.web>
Virtual roles is a concept invented by EPiServer that makes it possible to authorize users based on predefined criteria. You can never be added to a virtual role since it is responsible to decide whether you belong to it or not based on its implementation.
The code below displays the configuration in episerver.config for virtual roles in Public Templates.
<episerver>
...
<virtualRoles replacePrincipal="true">
<providers>
<add name="Administrators"
type="EPiServer.Security.WindowsAdministratorsRole, EPiServer" />
<add name="Everyone"
type="EPiServer.Security.EveryoneRole, EPiServer" />
<add name="Authenticated"
type="EPiServer.Security.AuthenticatedRole, EPiServer" />
<add name="Anonymous"
type="EPiServer.Security.AnonymousRole, EPiServer" />
<add name="Creator"
type="EPiServer.Security.CreatorRole, EPiServer" />
<add roles="WebAdmins, Administrators"
mode="Any"
name="CmsAdmins"
type="EPiServer.Security.MappedRole, EPiServer" />
<add roles="WebEditors"
mode="Any"
name="CmsEditors"
type="EPiServer.Security.MappedRole, EPiServer" />
</providers>
</virtualRoles>
...
<episerver>
EPiServer CMS 6 uses virtual roles to give access to parts of the website structure, or to the gadgets in EPiServer OnlineCenter.
Virtual roles are created to answer the question ‘Is the user in your role?’ when the system needs to authenticate a user. A brief description of their purpose and how the predefined virtual roles work can be found below.
CmsAdmins and CmsEditors are virtual roles that are based on MappedRole and are used by EPiServer CMS to for example check for access in gadgets based on Microsoft MVC.
If you take a look in Episerver.config you will find that the CmsAdmins virtual role is of type EPiServer.Security.MappedRole and has one attribute named “roles” that is set to “WebAdmins, Administrator”. The same goes with the CmsEditors virtual role that uses the same type and is mapped to the WebEditors role.
If you use .NET Reflector (www.red-gate.com) to browse the EPiServer.Shell.UI.Controllers. SearchController class, you can take a look at the Settings method. The method is adorned with an attribute, [Authorize(Roles = “CmsAdmins”)], and the reason for this is because this functionality should only be invoked by logged in users that belong to the Administrators or WebAdmins role.
So how does the MappedRole virtual role make it possible to limit access to this method? Well, the MappedRole does exactly what it says, maps roles, so when this method is executed the system will check the settings for the CmsAdmins virtual role in Episerver.config and will grant or deny access to the method (the authorization is being done by ASP.NET MVC).
Assume that you have configured the membership system to use the SqlServer providers.
When you are securing and configuring a website, consider the following:
The information above covers the authorization and authentication process that occur when you log in to EPiServer CMS.
If you create a user and add the user to the WebEditors role, the user will be able to enter Edit mode, but will not be able to change anything. The user will see all the pages that require the Read Access Level. In the same way if you create a user and add that user to the WebAdmins role, that user will be able to enter Admin Mode.
To make it possible to add users and groups to the system in Admin mode you need to make sure that you are using the correct MembershipProvider and RoleProvider.
Fun fact: The reason for the Administrators virtual role is to allow the name "Administrators" in allow/deny attributes in web.config. If you have a localized windows installation, Administrators might not be called that. It is "Administratörer" in Swedish for an example. With this virtual role, the name is mapped to whatever name the OS uses.
Just a small note to the new developers. Switching to SQLMembershipProvider will enable you to create new users yes, but only if you already have an admin account on that provider. To create your first admin account use the multiplexing provider instead and make sure that the sqlprovider is the first provider (like the settings above). This means that you can log in with your windows account but still create users with the sqlprovider. Create WebAdmins group if it doesn't exist. Create a new user and assign it to WebAdmins. Log out your windows account and log in with your new admin account...
Voila! You are up and running with access rights
One thing i've noticed is that if you are using the Windows Providers and logs on to the system with a local admin account a user will be created in the membership system. The reason for this is bacause even tough you are using the Windows Providers, the profile information need to be added and stored somewhere and EPiServer uses the Membership system to do this. So after the first login with your Windows account you will have one row in the aspnet_Users table that contain the the logged on user. This row is then linked to the aspnet_Profile table where the profile information is stored.