EPiServer – Security and Access Control (1/2)
EPiServer CMS is using the standard methods in ASP.NET to handle authentication and authorization. On top of this they have added a few providers to handle authentication and access control to EPiServer assets like pages and files uploaded by editors.
Make sure that you read up on how the authentication, location and authorization-tags works in web.config before you try to understand security in EPiServer CMS.
Check list for ASP.NET security
- MachineKey – Always add a machinekey-tag to your web.config-file. Use this online tool to generate the MachineKey.
- Authentication – I almost always use ASP.NET Forms authentication because it gives you the most flexibility. This is all you need and I always set timeout high to get the “Remember Me”-checkbox to work as expected. Sometimes I also use the defaultUrl-attribute to control what happens after login.
<authentication mode="Forms"> <forms loginUrl="Util/login.aspx" defaultUrl="/" timeout="129600" /> </authentication>
- Membership and RoleProvider – Configures how a username and password is validated and how to retrieve what groups a user is a member of.
- Authorization – EPiServer uses authorization tags together with location tags to control access to physical folders like the EPiServer user interface.
Select Security PROVIDERS
Select the right providers for your site:
- SqlMembershipProvider and SqlRoleProvider from Microsoft stores username, password and group membership in a SQL database. EPiServer is preconfigured with the needed tables so you can just start using them by changing defaultProvider-attribute.
- WindowsMembershipProvider and WindowsRoleProvider from EPiServer enabled forms login but with windows credentials. This is the default provider for a new installation. A big limitation if an editor needs to work with Access Control is that Window Users and Groups are only synchronized when a user log on. So it is not possible to add rights to a user before it has logged in at least one time and the security admin tool shows cached data for who is a member of a group.
- ActiveDirectoryMembershipProvider from Microsoft and ActiveDirectoryRoleProvider from EPiServer. Tries to workaround the problem with cached Users and Groups by talking directly to the Active Directory. I have personally have had a lot of issues with exceptions from the Active Directory providers and trouble to get it to work in a DMZ. They are also sensitive to interruptions if the LDAP server is not available. I recommend to use WindowsMembershipProvider if possible since it also uses the local machine as a cache.
- MultiplexingMembershipProvider and MultiplexingRoleProvider from EPiServer forwards the requests to a list of providers and this enables you to combine both SQL and Windows accounts.
TIPS – IF you Can not login with your Windows Account
EPiServer WindowsMembershipProvider does not work if you try to login with a domain account but do your machine does not have a working connection to your Domain Controler.
Workaround by creating a local account that is a member of the local administrators group.
Tips – Use a local group to optimize and handle Groups in groups
EPiServer WindowsRoleProvider uses queries that only retrieve a list of groups you are a member of directly. It does not discover if you indirectly are a member of group through another group.
This is quite annoying and and AD-admin get something sad in their eyes if you suggest that you should not use groups in groups.
Workaround this by creating a local group on the web server and add the AD group that is using groups in groups. WindowsRoleProvider will see that you are a direct member of the local group.
This technique can also be useful if a lot of different AD-groups should have the same access in EPiServer. The reason is that EPiServer stores one row in a table for each access control entry for each EPiServer page and directory in VPP.
It could simplify your web.config if you do not have to maintain a long list group names for edit and admin mode access. (EPiServer 6 has a new feature that takes care of this.)
Break in to an EPiServer site
Forgot the password? Only got ftp-access? Do not worry, as long as you have the right to change web.config you can always break in!
You need to comment out all “<deny users="*" />” in web.config and then it is possible to access edit and admin mode without authentication.
I suggest that you reset your password or create a new account in admin mode and turn on security as fast as possible!
Notice that you must login to be able to edit pages.
Access Rights for pages and uploaded files
- Read – Let’s you see the page or download the file.
- Create – Allows you to create child pages that will inherit the same ACL as the parent, upload new files or create directories.
- Change – Allows you to save a new version of a page and mark it ready to publish. You can also check in a new version of an existing files.
- Delete – Allows you to move a page to the wastebasket or delete it permanently. You can delete files and directories.
- Publish – Allows you to change and publish pages. Not applicable on files.
- Administer – Allows you to change the ACL for this page or directory as an editor and change dynamic properties on this page (and indirectly all children)
Users with access to admin mode can always change access control lists and do not need Administer right.
Page Files are special. Each page can have its own page folder and files uploaded to this directory have the same availability as the page. So if the page is not publish – no one can access the files in the page folder except editors. Very convenient since scheduled publishing also affects the files!
The same happens when the page is moved to the waste basket. No one can access the files in the page folder than editors. This is a common cause for broken images and links to document when editors copy and paste pages. If you delete the original page, no one can access the images its page folder!
Tips for Access Right configuration
If you follow these guidelines it will be much easier to administer access.
- Avoid giving users access rights directly. Always add roles (groups) and make users members of these instead.
- Never give WebEditors group any access rights (except on small sites where you are not going to use Access Rights at all). This roles is intended as a master switch if you have access to edit mode or not.
- Give the virtual role “Creator” the right to change and delete pages if you setup a site with writers and an editors-in-chief that publish pages. It will save a lot of maintenance work when writers makes mistakes.
- Using role names with both location and role will simplify when you administer who is a member of what, i.e. pressrelease_writer, pressrelease_publisher, startpage_editor, article_writer, blog_admin