Sitecore Strategy – Wrangling DXP Role Based Account Control in large enterprises

The overarching design of the role structure for backend users of the Sitecore platform is often an afterthought, with most implementations containing a mix of conventions across websites depending on who and when they were developed. In many cases this leads to confusion and administrative headaches and bad practices start to creep in - applying permissions directly to user accounts, ad-hoc custom roles and other compounding problems as more websites and users are added over the years.

Managing access in large-scale Sitecore implementations is a non-trivial task. When the implementation team rolls onto the next project, the Business-As-Usual administration of Sitecore access often falls onto end users of the platform like Marketers. With enterprises sometimes supporting hundreds of microsites and hundreds of content author contributors, ensuring the right balance between flexibility, security, and maintainability is crucial. Sitecore’s native security model provides robust capabilities, but designing a custom role structure that meets specific business requirements can be challenging. This article delves into best practices which can scale, real-world scenarios, and advanced techniques to wrangle RBAC effectively.

Sitecore CMS Security Model: A Technical Overview

Sitecore provides a good amount of documentation as to how the concepts hang together and crucially what the out of the box roles are intended for: https://doc.sitecore.com/xp/en/developers/latest/platform-administration-and-architecture/users,-roles,-and-domains.html

In a nutshell, the Sitecore CMS (this applies to XP, XM and XMC products) security model operates on a layered architecture with several components to managing access:

1. Domains and Users

   • Users are created within domains, such as extranet or sitecore, providing logical separation of access. Organizations can create custom domains to represent business units or other logical groupings.

2. Roles and Inheritance

   • Roles group Sitecore permissions and can inherit other roles - including out-of-the-box configured Authoring, Publishing and other roles, enabling scalable and reusable role definitions.
   • Custom Roles can be created using this inheritance structure (including being created within specific domains) and mapped to inherit out of the box roles.
   • Roles can be integrated to Entra (Azure AD) Single-Sign-On, allowing managing of user accounts outside of Sitecore by assigning organisational M365 accounts to Entra groups, granting them corresponding Sitecore Roles on login: https://doc.sitecore.com/xp/en/developers/latest/sitecore-experience-manager/configure-federated-authentication.html - Currently only supported in XM/XP, feature coming soon in XMC as of Q2 2024

3. Access Rights

   • Item-level security allows permissions (e.g., Read, Write, Create, Delete) to be assigned at a granular level.
   • Workflow states can enforce editorial permissions for content approval processes.

4. Security Layers in Content Authoring

   • Combining roles with workflow states creates a robust mechanism for managing authoring and publishing privileges.

Typical Sitecore RBAC Model

On a typical 'first website' the developer will create one or two custom roles under the default domain, for very small self-administered teams sometimes one role is created with the ability to self publish:

• extranet/BrandNewSiteEditor: Inherits out of the box Editor permissions and is granted access to BrandNewSite items in the content tree.
• extranet/BrandNewSitePublisher: Inherits out of the box Publisher permissions as well as the extranet/BrandNewSiteEditor role

This convention may or may not have workflow applied depending on business need.

As new websites are added, this convention is typically followed until the number of websites reaches some critical mass (~20+). As new users are added or existing users require additional permissions, administering this pattern becomes cumbersome.

Challenges in Enterprise RBAC Design

One of the key problems with RBAC design is that scaling problems don't become apparent until the number of sites increases, in one case I reviewed a solution with over 150 websites and a mish mash of custom roles, workflows and single user permissions. Administering user account permissions as new websites were created was a massive time sink and the impact of an author going on long service leave requiring their permissions to be transferred was a risk prone exercise.

The main compounding factors I have observed across these large scale implementations are:

High Volume of Users and Roles

Enterprises may have hundreds or even thousands of content authors, each with varying levels of access. Managing this volume requires a scalable and maintainable structure.

Diverse Content Ownership

With many sites under one umbrella, defining ownership and access boundaries can be intricate, especially when teams span multiple regions or departments.

Balancing Granularity and Simplicity

Highly granular permissions can provide precise control but may lead to complexity in management. Striking the right balance is key.

Audit and Compliance Requirements

Enterprises often need to enforce strict compliance and generate access reports, further complicating RBAC design.

Real-World Scenario: Mass Scale Multi-Site Role Management

Problem:
An organization manages 300+ regional and campaign-specific microsites. Each microsite requires:

• Authoring teams with access only to the sites they contribute to.
• Most websites allowing for self-publishing by authors, some websites requiring a two step publishing process with an approver.
• A global admin team with access to all content.

Solution:

1. Hierarchical Role Design

   • Create "Global Admin" and Developer roles with access to all sites and top-level permissions.
   • Profile end users of the platform into 'Authoring Role Personas', grouping contributors by the type of content they administer and what actions they are able to perform. This exercise should typically produce a set of broad Personas which are responsible for subsets of the pool of websites.
   • Top Level Roles (TLRs): Define the 'Authoring Role Personas' (e.g., APAC Campaign Microsites Editor, Primary Subsite Content Producer) as Top Level Roles which are intuitive within the context of the business domain. These roles should be delineated by the level of publishing permission they are granted.
     • (optional) If there is a large variance in permissions across the websites (e.g. can only edit some but can publish on others) this suggests that the Top Level Role is too broad. If this is unavoidable, 'typical' Editor/Publisher custom roles can be created per-site and used for inheritance into the Top Level Role.
   • Map out of the box Sitecore roles to Top Level Roles, granting the ability to execute actions (e.g. publish) across all websites/the role has access to.
   • Apply access permissions to subsets of websites and content to the new Top Level Roles, restricting access to specific items in the content tree.

2. Workflow Integration

   • Use workflows to restrict publishing permissions at the microsite level to specific Top Level Roles, ensuring local editors can author but not publish directly.

3. Automation

   • Map the Top Level Roles to automated role assignment using external identity providers like Entra/Azure AD. This allows for onboarding/offboarding of staff accounts to be tied to the overarching O365 account management within the organization.

Principles for Designing a Custom Role Structure in Sitecore

1. Start with Organizational Analysis
   Understand how content authors and editors interact with Sitecore, including their roles, tasks, and workflows. Group users into high-level categories based on their needs.

2. Use Hierarchical Roles
   Build a hierarchy of roles to reduce redundancy. For example, define broad roles like "Global Author" or "Regional Editor," and add more specific permissions through inherited roles.

3. Leverage Sitecore Security Layers
   Sitecore’s security model includes domains, roles, and item-level access. Use these layers strategically to align permissions with business requirements.

4. Modular Role Definitions
   Break roles into smaller, reusable modules that can be combined for more specific permissions. For instance, create separate roles for content creation, approval, and publishing.

5. Implement Least Privilege
   Grant users only the access they need to perform their duties. Avoid assigning broad access that could lead to accidental or unauthorized changes.

Addressing Auditing and Compliance

1. Custom Security Reports
   Extend Sitecore PowerShell Extensions (SPE) or develop custom scripts to generate reports on role assignments and access rights. I recommend this excellent reporting script to get arms around the current design: https://github.com/jbluemink/Sitecore-Security-Rights-Reporting

2. Integration with Identity Providers
   Use Single Sign-On (SSO) systems like Entra/Azure AD or Okta to centralize authentication and simplify role management. Mapping to specific roles is not currently (as of Q2 2024) supported in the XMC product, but Federated Authentication purely to grant access to the platform is in place.

3. Access Review Workflows
   Automate periodic reviews of access permissions, notifying managers to confirm or revoke roles as needed. Federated Authentication allows for this to be managed using standard account onboarding/offboarding.

Conclusion

Designing a robust Role-Based Access Control structure in Sitecore is essential for managing large enterprise environments with diverse user needs. By adopting a strategic approach to role design and leveraging Sitecore’s security features, organizations can ensure secure, efficient, and scalable access management. Proper planning, testing, and ongoing refinement are critical to achieving a balance between usability, security, and scalability.