Here’s the scenario…
You’ve created the best website imaginable using Sitecore. You’ve taken a little time to chat with our SEO experts about possible ways to better reach your target audience and taken a look at SEO for Sitecore. You’ve put time and effort into creating the best user journeys for your entire site. You have the greatest content ever to go with the best website ever.
Suddenly, you realise that you need to give your content creators access to your perfect website. It’s a perfect system: only one person can go in and make changes. Meaning that, currently, no one can mess things up. But now you have to give other people access to your perfect system.
But, what if they start editing pages everywhere?
This is where the Sitecore user access model comes in.
Conditional user access
Sitecore allows you to create as many users as you wish and each of the users that you create can be assigned a role. Roles help to limit the number of user accounts that are required to have full site administrative access.
Sitecore is very powerful and you may not want all of the power available placed in the hands of everyone who has a user account.
When it comes to user accounts, you need to limit what functionality those accounts have access to. After all, you don’t want to get a frantic phone call from your boss in the middle of the night telling you that the website has gone down, only to find out that all of your content was ‘accidentally’ wiped out, three hours prior by Peter the intern*.
*My apologies to anyone called Peter, or those who are interns. Also, how did the boss know that the website had gone down at 2 AM?
The key here is to only give someone access to the tools (or in this case, functionality) required to do their job.
Say you want someone to add new items to your fancy blog, but you don’t want them to edit anything else (the contact details of your head office, for example). This is where roles come in.
All you need to do is assign a role with permissions to read, write, and create blog pages to the relevant users. This will ensure that your blog writers (or whoever else you apply this role to) cannot access or alter data other than those found on the blog sections of your website. You may also want a separate user to publish those blog articles, in which you give them a role with all of the above rights but with Administration too.
In Sitecore, roles are used to assign access rights to users. Each role must belong to one or more security domain (more on those in a few paragraphs) and can be attached to one or more user. When a user logs in, they will only have access to the areas that are granted to them via their role.
John West (CTO at Sitecore America) gives the definition of a role as:
“A role is a collection of users. Roles simplify the application of access rights by grouping users.”
– John West (2012), Professional Sitecore Development, Indiana: Wrox Books (978-0-470-93901-7)
Say Norman needs a role that will allow him to alter all of the advertisement banners, swapping them out for ones that advertise your newest product. You may not want him accessing the whole of the home page back end. A few stray clicks here and a couple of keyboard presses there and you might have a homepage that has a picture of his pet cats as the background, with no explanation as to why.
In this instance, Norman’s user account should have a role applied that only has access to the areas that are relevant to his task – in this case the media library would be sufficient.
Sitecore best practises, with regards to users, states that roles were created as a way of preventing individual users from being given access rights to specific parts of the system and to help in scalability.
All users inherit their access rights via the roles that are applied to them, this makes managing user access rights simpler: you need only edit the role for these changes to be applied to all affected users automatically. Otherwise, each user would have to be altered, in turn, to apply new access rights.
It’s all about scalability, you see. A company that starts with four employees may not see a need for such scalability. But what happens when the same company hires 200 extra staff? This is where roles would help in managing the access rights of all users.
Changing the access rights of a role is quite simple. After loading the Access Viewer (found in the Security Tools section of the Sitecore shell), select a role to edit, and toggle the tick/cross value of the permission of the chosen Sitecore item. Once the role details are saved, all users who implement that role will be automatically updated.
Roles are extendible, too
Say you give Mary-Jane the role ‘blog content approval’ which will allow her to approve (or deny) all blog content. A few months later it is decided that a role is required for approval of whole site content (let’s call it ‘site content approval’).
Since the whole site includes the blog, you need the ‘site content approval’ role to have the same access as ‘blog content approval’. In this situation, ‘site content approval’ will just extend that of ‘blog content approval’ (in programming this is called inheritance: all of the rights applied to ‘blog content approval’ are inherited or copied by ‘site content approval’), giving it relevant access to the remainder of the site.
As it has extended ‘blog content approval’, changes to the ‘blog content approval’ role will affect ‘site content approval’ role, too.
Which is a long winded way of saying: changes made to one role will filter down to all roles that inherit from it. These changes will also be applied to all affected users, too.
Also called Security Domains to help differentiate against domain name, a domain is a collection of roles and user accounts. For instance, the Sitecore domain (which is one of the default domains) contains all of the default Sitecore roles and user accounts. Domains allow administrators to group similar user accounts and roles by use or some other function or other metric.
The Sitecore security reference guide defines a security domain as:
A Sitecore domain is a group of accounts that are administered as a unit with common rules and procedures.
A domain is used to collect accounts that have some logical relationship, for example, all the accounts who have access to use the Sitecore clients may be stored in the Sitecore domain, whereas all the accounts who have access to the published Web site may be stored in the Extranet domain
– http://sdn.sitecore.net/upload/sitecore6/61/security_reference-a4.pdf (Sitecore Developer Network login required to access)
A team of marketers may, for instance, be placed within the domain “marketing”. This enables Sitecore administrators to manage groups of similar users and roles at once. This all makes it easier to manage teams that make up larger domains (domains that are perhaps grouped on a brand basis).
Here’s where it gets a little blurry: Sitecore Domains are also known as Local Domains, these (Sitecore) domains give users access to the local domain only. Let’s say that you’re hosting several web domains on the same Sitecore solution, and you want the Foo team to only have access to your Foo web domain, then you assign them to the Foo Local Domain. This means that the Foo team do not have access to, or even see, the Bar domain when they log into Sitecore’s shell.
This concept is known as the “Delegation Model” (as the management of individual domains is delegated to a specific team).
What this all means…
This means that the Sitecore security model is made of Domains; each of which contains a selection of Roles. These Roles define what content the User within a given Domain has access to. Meaning that the widest possible range of responsibilities (a particular Domain) is split into smaller parts (Roles), which are then applied to individual users.
This helps to divide up the responsibility of administering the many different aspects of a Sitecore managed solution, along with the power that Sitecore offers to the relevant users who actually require it. This increases the security of your Sitecore managed solution whilst, at the same time, reducing the chances of a user without permissions altering data that they do not have access to.
Leave me a comment below if you’ve got any questions on the Sitecore User Access Model and I’ll get back to you!