Self Documenting Security Roles

Cover Image for 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?

Useless comments

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:

  1. A pseudo "job title" for a user, e.g. Author, Developer, Designer
  2. An action, e.g. Sitecore Client Bucket Management, Sitecore Client Account Managing
  3. 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 or clientdomain
  • 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.
  • 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


More Stories

Cover Image for On Mentorship and Community Contributions

On Mentorship and Community Contributions

> Reflections and what I learned as an MVP mentor

Cover Image for NextJS: Access has been blocked by CORS policy

NextJS: Access has been blocked by CORS policy

> CORS is almost as much of a nuisance as GDPR popups

Cover Image for Early Returns in React Components

Early Returns in React Components

> When and how should you return early in a React component?

Cover Image for SPE Script Performance & Troubleshooting

SPE Script Performance & Troubleshooting

> Script never ends or runs too slow? Get in here.

Cover Image for Troubleshooting 502 Responses in Azure App Services

Troubleshooting 502 Responses in Azure App Services

> App Services don't support all libraries

Cover Image for Year in Review: 2022

Year in Review: 2022

> Full steam ahead

Cover Image for Script: Boost SIF Certificate Expiry Days

Script: Boost SIF Certificate Expiry Days

> One simple script that definitely won't delete your system32 folder

Cover Image for JSS + TypeScript Sitecore Project Tips

JSS + TypeScript Sitecore Project Tips

> New tech, new challenges

Cover Image for NextJS: Short URL for Viewing Layout Service Response

NextJS: Short URL for Viewing Layout Service Response

> Because the default URL is 2long4me

Cover Image for How to Run Old Versions of Solr in a Docker Container

How to Run Old Versions of Solr in a Docker Container

> Please don't make me install another version of Solr on my local...

Cover Image for Ideas For Docker up.ps1 Scripts

Ideas For Docker up.ps1 Scripts

> Because Docker can be brittle

Cover Image for Sitecore Symposium 2022

Sitecore Symposium 2022

> What I'm Watching 👀

Cover Image for Tips for New Sitecore Developers

Tips for New Sitecore Developers

> Because learning Sitecore can be hard

Cover Image for NextJS/JSS Edit Frames Before JSS v21.1.0

NextJS/JSS Edit Frames Before JSS v21.1.0

> It is possible. We have the technology.

Cover Image for Tips for Applying Cumulative Sitecore XM/XP Patches and Hotfixes

Tips for Applying Cumulative Sitecore XM/XP Patches and Hotfixes

> It's probably time to overhaul your processes

Cover Image for Don't Ignore the HttpRequestValidationException

Don't Ignore the HttpRequestValidationException

> Doing so could be... potentially dangerous

Cover Image for Tips for Forms Implementations

Tips for Forms Implementations

> And other pro tips

Cover Image for Super Fast Project Builds with Visual Studio Publish

Super Fast Project Builds with Visual Studio Publish

> For when solution builds take too long

Cover Image for Symposium 2022 Reflections

Symposium 2022 Reflections

> Sitecore is making big changes

Cover Image for Azure PaaS Cache Optimization

Azure PaaS Cache Optimization

> App Services benefit greatly from proper configuration

Cover Image for Hello World

Hello World

> Welcome to the show

Cover Image for NextJS: Unable to Verify the First Certificate

NextJS: Unable to Verify the First Certificate

> UNABLE_TO_VERIFY_LEAF_SIGNATURE

Cover Image for JSS: Reducing Bloat in Multilist Field Serialization

JSS: Reducing Bloat in Multilist Field Serialization

> Because: performance, security, and error-avoidance

Cover Image for On Sitecore Stack Exchange (SSE)

On Sitecore Stack Exchange (SSE)

> What I've learned, what I see, what I want to see

Cover Image for Add TypeScript Type Checks to RouteData fields

Add TypeScript Type Checks to RouteData fields

> Inspired by error: Conversion of type may be a mistake because neither type sufficiently overlaps with the other.

Cover Image for Content Editor Search Bar Not Working

Content Editor Search Bar Not Working

> Sometimes it works, sometimes not