AI OnAI Off
| Views: | 23247 |
| Number of votes: | 3 |
| Average rating: |
Authentication and Authorization in EPiServer CMS 6
Nov 12, 2010
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.
Default Authentication and Authorization for Public Templates
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.
Changing the Authentication and Authorization Model for EPiServer CMS
SqlServer Providers
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.
Multiplexing Providers
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.
Predefined Roles in web.config
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.
Use the “location” Node in web.config and EPiServer CMS Groups to Secure the Website
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 in EPiServer CMS
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.
- EveryoneRole always tells the system that you belong to the role since it is implemented to always return true.
- CreatorRole first checks that you are authenticated and then checks if you are the user that created the current page that is about to be displayed.
- AnonymousRole simply checks if you are an authenticated user in the system in contrast to the AuthenticatedRole that does the opposite.
- AdministratorsRole is used mainly when the membership providers are set to use the Windows providers. It checks if the Windows user account that are being used for logging in to the system belongs to the Local Administrators group.
- MappedRole is used to map the virtual role to other roles in the system, e.g. WebAdmins, Administrators, CreatorRole, etc.
Where Does MappedRole Fit in?
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.
For the Brave Developers Out There – Behind the Scenes
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).
Example of How to Give Users Access Rights in EPiServer CMS
Assume that you have configured the membership system to use the SqlServer providers.
- Enter EPiServer CMS Admin Mode.
- Create a new user, Kalle, and add the user to the WebAdmins group.
- This user will be able to log into Admin Mode and Edit mode.
- Create a new user, Lisa, and add the user to the group WebEditors.
- This user will be able to enter Edit Mode, but will not be able to do anything except from browsing around. They will not automatically have access to edit all the pages on the website.
- The user will have access to EPiServer OnlineCenter and will be able to see the gadgets that don’t demand any specific group, e.g. the CmsAdmins role.
- Create a new user, Laban, and add the user to the group WebEditors.
- Create a new group named ‘News_Editors’.
- Set Access Rights for the News_Editors group to have Access: Read, Create, Change, Delete and Publish for the page named ‘News’ and its descendants
- Add the user to the News_Editors group.
- The user will be able to add and change pages to the News branch in Edit Mode and will only be able to make changes to these pages.
- If you want Lisa to also be able to edit the same pages, then you must add Lisa to the group News_Editors.
Recommendations
When you are securing and configuring a website, consider the following:
- Never give WebAdmins and WebEditors access rights in the website structure.
- Only use the role WebAdmins to give access to Admin Mode.
- Only use the role WebEditors to give access to Edit Mode.
Conclusion
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.
More information
Comments
Please login to comment.
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.