In a lot of Sitecore implementations that I’ve done over the years, a conversation that typically always comes up out of the discovery meetings is on the topic of authoring security and permissions. What can authors do? What can authors not do? When working in fast paced environments, project teams typically try to find areas where fatty development can be trimmed. One of those areas usually ends up being authoring environment security.
This is the first part in a series of blogs on Sitecore Authoring Security.
In this blog, I’ll expose 3 key excuses why authoring security and permissions are generally left out, left last, or simply forgotten and provide tips for avoiding these pitfalls.
#1 – Intrusive
In these implementations, security is generally left for last because of the intrusiveness that sometimes arises during the development phase. Developers generally dislike roadblocks in their way when they are developing. I call it the developer groove. Well, not really. But you get the idea. When developers start to implement security in the middle of a development push, sometimes that security can slow down work.
Some tips for avoiding this and still implementing security:
- Developers should be using their own Sitecore accounts that are listed as “administrator”. This will keep security from getting into the way.
- Limit the amount that you use the “sitecore/admin” account in Sitecore. Sets up a bad habit for later.
#2 – Time/Money Constraints
Time and budgets can be a limiting factor for a lot of things during any website implementation. To implement Sitecore security effectively can be burdensome and time consuming if your Sitecore implementer is lacking experience in this area, or if the client doesn’t have a clear sense of what they want to do. This can result in a lot of rework and repetitive testing.
Tips for avoiding:
- Ensure that a plan has been established and agreed upon by all parties. If this plan can’t be agreed or completed, hold off until it is. This will prevent a lot of the rework that can generally occur, which saves time and money.
- Document the functional roles within the company and how the client organically works. Implementing a security and workflow plan that closely mimics how the client is structured organically can go a long way towards user acceptance of Sitecore overall.
#3 – Indecision
I saved the best for last. One of the top reasons why authoring security, workflow, editing controls, really anything related to the process of how an organization is to author content is left to the wayside, is because of indecision. The client can’t come to grips with their own process to understand how content should be authored. In these cases, by the time the client has come around to understand, the project is long since over. I’ve seen clients have to re-engage in a contract just to do security because they took so long to figure out their own process.
Tips for getting over this hurdle:
- When it comes to authoring security and workflow: Keep it simple!
- Don’t worry about copywriters, editors, authors and Sitecore access. Start with a simple process and adjust as needed.
- Avoid complex security and focus on the roles, not the person.
- Security shouldn’t be assigned to individual user accounts unless you have a specific reason (read: very rare).
- Keep security confined to roles only.
- Use role inheritance to achieve desired functionality.
Conclusion
Don’t allow these excuses to get in the way of implementing your Sitecore solutions and building much needed security controls around it. Finding the right solution partner that can help navigate Sitecore security, role based permissions, and content workflow can accelerate your Sitecore implementation.
Next in This Series: Authoring Security
- I’ll start to talk about a fictitious company’s’ desire to implement role based security and how they can achieve it with little to none developer interaction.
- Then walk through the different functional roles within the company, draft a plan, and then provide a walk through on how to draft your roles.
- Finally, I’ll demonstrate through a webinar how to take that plan that was created and create the appropriate role based security in Sitecore.
Following the conclusion of this series I’ll focus on expanding our newly built role based security and discuss Sitecore Workflows and how to build workflows appropriately.
This post also appears on Coria’s Blog at http://blog.coria.com. At Coria, we love solving hard problems. We go about it by supplying a turnkey Team-in-a-Box with integrated technical Subject Matter Experts, developers, project management, analysis, and quality assurance to solve your company’s most challenging puzzles.
Sitecore Hacker 
Leave a Reply