Self Documenting Security Roles
Security and role configurations can be a tangled mess. Let's see if we can do better. Something I haven't seen discussed in the community is the idea of self documenting security roles.
The Issue
Conventional security / role configurations that have any level of complexity need supporting documentation / spreadsheets to make sense of them. This is a problem because documentation is often out of date, incomplete, hard to find, and hard to understand.
As a dev, I always laugh when I see useless comments scattered throughout code that wouldn't even need to be there if the original dev wrote just wrote self documenting code instead. What if we could make our roles (mostly) self documenting?
Another issue is that role names are often abstract. They hide needles in a haystack. Let's say that a certain role, Blog Author
, needed to be blocked from writing changes to a Secret Page
item that was deeply nested in the item tree. We can go into Security Editor and deny write access on that item for that role. I have been in situations in which someone did something like this, and it caused a lot of problems and was hard to debug. Why? Because the role name Blog Author
doesn't give any indication that it has a deny permission on Secret Page
.
What's in a Role Name?
A role name can encapsulate numerous concepts. Here are a some examples:
- A pseudo "job title" for a user, e.g.
Author
,Developer
,Designer
- An action, e.g.
Sitecore Client Bucket Management
,Sitecore Client Account Managing
- A conceptual group of roles/user types, e.g.
Sitecore Client Users
Something I've never seen is a role name that describes a specific security permission.
Example
Consider the role sitecore\Developer
. It is a member of these roles:
sitecore\Sitecore Client Developing
sitecore\Sitecore Client Configuring
sitecore\Sitecore Client Maintaining
sitecore\Designer
sitecore\Author
What does any of this actually mean? What permissions does this role have when all is said and done? Let's go deeper. sitecore\Author
is a member of sitecore\Sitecore Client Authoring
which is a member of sitecore\Sitecore Client Users
. Finally the chain of inheritance ends, and I still don't know what any of this means, so it's off to the Sitecore docs:
Gives the user minimal access to Sitecore. With this role, the user can log in to the Sitecore Desktop, but will not have access to any applications.
Now we know that this chain of roles is abstract in nature and that it encapsulates numerous security permissions. If we want more details, we have to go digging through the Access Viewer or Security Editor.
My Approach
When it comes to setting up security and roles, I always keep these principles in mind:
- Simple hierarchy
- Not too much abstraction
- Flat is good
- Simple is good
- As few security settings per role as possible
- Don't modify the default roles
- No cyclical dependencies
Ultimately, the goal is composition over inheritance.
Role Naming Rules
Before we dive into the meat and potatoes of this post, one challenge we have to contend with is that role names can't contain any special characters.
When you create a new role with a super snazzy name, the dialog box says:
The role name can only contain the following characters: A-Z, a-z, 0-9, ampersand and space.
That's right -- you're not even allowed to use hyphens! https://sitecore.stackexchange.com/questions/13001/allow-hyphens-for-sitecore-security-roles
Proposed Schema
Here is a loose idea for a simple self documenting role naming convention:
<Domain>\<Scope> && <Path> && [<PermissionLevel> <PermissionType>] && <Inheritance>
Where:
- Domain:
sitecore
orclientdomain
- Scope:
ITEM
,MEDIA
,SITENAME
,GLOBAL
,WORKFLOW
, or any broad category that is useful for your project - Path: if applicable, a general path to the item in which the security setting has been applied to
- Square brackets meaning there can be 1 or more of these:
- PermissionLevel:
ALLOW
/DENY
,DISABLE
/ENABLE
- PermissionType:
READ
,WRITE
,RENAME
,CREATE
,DELETE
,ADMINISTER
,PROTECTED
, etc.
- PermissionLevel:
- Inheritance:
WITH INHERITANCE
if inheritance is applied
Here are few examples following this convention:
sitecore\SITE1 && Content Site1 SecretFolder && DENY READ
sitecore\SITE1 MEDIA && Media Site1Folder && ALLOW WRITE && DENY CREATE && WITH INHERITANCE
Voila. Self documenting role names.
What do you think of this idea? Do you have any other ideas for how to make security roles more maintainable?
Keep improving,
MG