Setting up user permissions in EPiServer CMS, part 1
This post provides a basic introduction to how user permissions are configured in EPiServer CMS. Part one deals with the authentication and authorization model in IIS and ASP.NET 2.0 and how it relates to EPiServer CMS. Part two is about how administrators create a well-defined and natural permission structure in EPiServer CMS to manage changes with minimal effort and impact on the site by use of an existing permission model.
Intranet or public website?
It’s a very basic question that needs to be asked. Take a step back and analyze the type of user that will access the site. Will it only be users on their network? Are there external partners? Or is it a combination? Often the site will be either an intranet or an external website. This will be the basis when we make our choice of identification and authentication technologies to implement for the website!
Assuming that the site will be included in a version of IIS we’ll be able to allow anonymous access or integration with Windows’ own identification and authentication model. The former should not be used together with a public website because users will not be authenticated using a Windows account. If the website is a intranet it is recommended that user accounts and groups are defined in the Active Directory.
Authentication and authorization model
Let’s take a look at what options we have in the choice of identification and authentication model in EPiServer CMS. EPiServer CMS uses the functionality of ASP.NET 2.0 to detect and determine what permissions a user has when he/she visits a page. In sort this means that EPiServer CMS implements the ASP.NET 2.0 Provider model, which is an abstraction layer to the data source that contains information about user accounts.
How is a user authenticated?
We can in the IIS define if we want to allow anonymous access or if the users must be authenticated when accessing the website. We do this in the property settings of the website. A website that will integrate with user accounts in an active directory should look like the image below. If the website will be public then it should be configured to allow anonymous access without integrated windows authentication.
In a website that uses ASP.NET 2.0 users can be authenticated using forms authentication or windows authentication. This is defined in the website’s web.config as shown below.
With windows authentication enabled the website attempts to authenticate the user with the user’s windows account.
Worth mentioning is that if the website is added as a website in either the Trusted Sites or Intranet security zones in Internet Explorer then the user will be logged on automatically with their current credentials. If not the website will challenge the user and the user is required to manually login.
The above describes how the site authenticates the user. Now this information must also be made available to EPiServer CMS in order to allow or deny access to pages. EPiServer CMS uses the ASP.NET 2.0 Membership and RoleRrovider model for this purpose.
Three standard providers which EPiServer CMS can use*:
A third option which is shipped with an installation of EPiServer CMS is the MultiplexingRoleProvider which is a hybrid version of WindowsMembershipProvider and SqlServerMembershipProvider. It may sound tempting to use two providers but to store user accounts in two different sources should be avoided.
A public website is almost always exclusively using the SqlServerMembershipProvider. Using local windows accounts or active directory accounts shouldn’t be used with a public a website as it’s a security risk and increases the solution’s complexity.
Intranet solutions commonly implement the WindowsMembershipProvider or ActiveDirectoryMembershipProvider.
More information about ASP.NET 2.0 Provider model can be found here:
- EPiServer CMS 5 SDK on Membership and Role Providers
- Scott Guthrie’s ASP.NET 2.0 Membership, Roles, Forms Authentication, and Security Resources
* Note: Only from EPiServer CMS 5 R2 SP2 the ActiveDirectoryMembershipProvider is included. In earlier versions of EPiServer CMS 5 the source code for this provider must be downloaded and compiled separately. The source code is available here .
Users who have authenticated with a membership provider must also be authorized. This is done via the RoleProvider model . The role provider should correlate with the type of membership provider implemented (Windows, Active Directory or SQL).
Access to the administrator and editor interfaces in EPiServer
Access to the admin and editing interfaces in EPiServer CMS are defined in web.config. This is done in the <location>-elements of the admin and edit URL-segments. Only two groups should be defined in web.config: WebEditors and WebAdmins. The only authorization the WebEditors Group should define is the access to the edit interface. Not what web editors can actually do once they’ve gained access to the edit-interface. Part two goes into more detail about this where we also have a look at how we structure of our security groups and relate them to page tree!