Translate
As mentioned in the SDL Web Cloud update in July, we have extended the Tridion authorization model with a new setting and concept called privileges (SDL Web Cloud documentation accessed on 2016-09-05). This post gives an overview and reasons for the feature. I'll describe how privileges work and provide some examples in the next posts.
The Tridion authorization model is now based on four concepts:
- Scope
- Rights
- Permissions
- Privileges (new!)
Authorization
Scope determines which Publications, the highest-level folders in SDL Tridion, are visible to groups and users in the Content Manager Explorer. Rights allow users the ability to perform certain actions or commands in a given Publication and determine which buttons they can see or use in the ribbon toolbar. And Permissions determine where these right apply in terms of the ability to read, write, delete, and localize items within organizational items (folders or repositories, to be technical).
For example:
- A user may be scoped to only see Publications related to content, pages, and publishing websites (e.g. 200 Content, 300 Pages, and 400 Sites)
- The user's group may allow the right to manage content or perhaps pages (e.g. Chief Content Editor with Component Management or Page Management Rights)
- The user or group may be allowed to see and work with a select set of Folders, Structure Groups, and Categories through Permissions (e.g. read on "Building Blocks" and "System" folders but write on the "Article" folder)
For more background on authorization, see some of my previous posts:
Privileges in SDL Web Cloud
Privileges are much like Rights in that they allow Users the ability to perform certain actions or commands in the interface (or API). But unlike rights, privileges can only be set on Groups, not Users, and are not scoped to a specific Publication. The initial release of Privileges includes includes:
- System Administration
- Privilege Management
- Group Management
- Approval Status Management
- Multimedia Type Management
- Publish Transaction Management
- Child Publication Creation
These system-wide abilities were added to address the needs of the long-overlooked role of "Application Manager."
Missing Persona: Application Manager
In implementations, trusted non-technical "power users" would often know which changes need to be made to things like system-wide lists, the BluePrint, or the publishing queue. But they needed to rely on technical system managers in IT to make changes.
Some projects would set developers or such power users as System Administrators to let them change anything. However, this poses risks to security and isn't necessarily a fair reponsibility to place on roles that typically aren't admins. Authorization is indeed about security and access, but it is also a way to help users feel comfortable that they won't "break" the system.
Fellow product manager Onno Ceelen described privileges as the ability to "empower (non-system) application managers to work across the CMS while preventing 'damage' to the system."
In summary, privileges help you to optionally give system-wide settings management to select users, without giving them full administrative access. This helps both our own SDL Cloud operations team as well as partners, implementers, and IT teams that manage the system on behalf of their users. In the next post, I'll describe the privileges added to the latest release of SDL Web Cloud and how they work. We'll wrap up this series with some examples to give you ideas on how you might take advantage of this new feature.