Translate
In my last post I described how the new privileges feature in SDL Web helps (non-system) application managers make relatively low-impact changes. Lets review the specific settings in this post and then consider some examples in the next post.
Let's look at the list of privileges along with their descriptions. The first two columns in the table below are from the SDL Web Cloud documentation (retrieved 2016-09-05). I'm adding an additional column to share some history, background, and notes for users and implementers.
|
Privilege (per SDL Docs)
|
Operation (per SDL Docs)
|
History, background, and notes
|
|---|---|---|
| Child Publication Creation Privilege | Creating Child Publications of Publications to which the User has access. Typically, you would use this privilege to manage who can or cannot create Publications intended to be used as Web sites, either using the Site Wizard or in the Publication BluePrint hierarchy. |
The ability for non-administrators to create Publications was first introduced in SDL Web 8 with the Site Wizard feature. To be able to use the Site Wizard, users need to be identified with this type of access. In our technical implementation, AppData was used to store the setting and behind the scenes, the user's access was "elevated" to administrator to let them create Publications. While this was fine for a single privilege, we saw the opportunity to make an approach that can handle other system-wide settings. We've taken advantage of this opportunity with the other privileges and implementers can extend privileges themselves by first adding a privilege to the Content Manager and then handling how it should behave in code or the UI. The technical ability to elevate privileges will remain for implementers and our own improvements, though the next on-premise release of the Site Wizard may not use this. Finally, the privilege is specific to Child Publications. With the privilege, users could add Publications to an existing BluePrint "branch" but cannot create standalone Publications with their own branch, which is a capability reserved for administrators but would rarely be used in practice. |
| Group Management Privilege | Creating, viewing updating and deleting Groups. This includes managing Group scope and membership, getting a list of Users, editing a User and changing the Group membership of a User. | Previously, users with the Permission Management right in select Publications could see Group Management in the Admininstration tab. They would be able to manage groups, but only with scope settings that use Publications visible to them. Now the Group Management privilege allows non-administrators the ability to manage groups and their membership, including adding users to groups. |
| Approval Status Management Privilege | Creating, viewing, editing and deleting Approval Statuses | This was previously only manageable by adminstrators or users who had Workflow Management right in at least one Publication. |
| Multimedia Type Management Privilege | Creating, viewing, editing and deleting Multimedia Types | Multimedia Types allow you to group types of files (MIME types) into logical groupings. For example, rather than having a type of .jpg, .gif, or .png, you may treat these all as an image. You could then update the image multimedia type to include new formats as they come out such as .webm, Managing this list was previously an administrator-only task but now this privilege could be given to a non-admin group. |
| Privilege Management Privilege | Granting or denying system privileges (other than the System Administration Privilege and the Privilege Management Privilege) for all Groups. The Privilege Management Privilege does not allow the user to change other Group properties or Group membership. | With the new privilege feature we also needed a way to allow users in groups to set the privileges of other groups.
The system performs checks to avoid allowing non-admins to give themselves or others users the administrative privilege. |
| System Administration Privilege | Performing all operations described in this table. |
By default, Tridion will now have a system administrator group. Previously you would enable system administrators by checking the box for a given user. In SDL Web Cloud and in the next on-premise release, you would instead add users to a group that has the system administration privilege. If Group Synchronization (SDL Web 8 on-premise documentation) is enabled, this new system administrators group has the added benefit of letting you manage CMS administrators from Active Directory or an LDAP-compliant directory, assuming LDAP is configured). |
| Publish Transaction Management Privilege | Viewing, editing, deleting and undoing Publish Transactions, including those not initiated by the User. | Publishing is critical to Web Content Management. Though users could always manage their own transactions, it typically required an (internal or cloud) support request to get help with publishing requests for other users. As described, this privilege lets trusted users manage the publishing queue on behalf of other users. |
New Rights and Groups (Publication Administration Right)
In addition to the new default SDL Web Content Manager Administrators group, authorization includes the following changes for SDL Web Cloud (and thus the next on-premise release after SDL Web 8):
- The "Everyone" group has been renamed "All SDL Web Content Manager Users" and keeps the same ability to set rights or permissions for all CMS users.
- A new group called Business Process Type Manager has Schema Management and Business Process Type Management rights.
- A new Publication Administration Right grants the ability to perform typically system-administrator actions, but is scoped to a given Publication.
This last right could be used to give select users the ability to:
- Undo checkout on items that belong to other users (this has been a frequent customer request, seen as early as 2008 in SDL Tridion Ideas request by user "dleblond")
- Make changes impacting any item in a Publication, without access to system-wide settings
- Help others troubleshoot or handle issues with authorization (e.g. see hidden items, search for items across the Publication, and make updates)
Privileges Behavior
Here are some things to keep in mind when working with privileges.
Backwards Compatibility in the API
Previous extensions that checked if a user was an administrator will continue to work. Though the admin "flag" is no longer stored with the user in the database, using the APIs will continue to identify the user. This is one example of where it's a bad practice (and indeed not supported) to query the database directly.
System-Wide (Not Scoped), Inheritable Group Settings
Privileges are typically system-wide, applying across the entire BluePrint. Set only in groups (and not users), BluePrinting concepts like localization don't apply. However, some privileges are influenced by BluePrinting and Scope. For example, though a user could create a child Publication, they would only be able to do so from Publications they already had scope to.
Also note the changes to the group view:
- We moved the user scope settings to their own tab called "Group Visibility" (in practice you maybe want to leave these set to "all publications" and manage membership scope instead).
- The UI explains that the scoping applies to rights and permissions. In other words, privileges are not scoped to publications (they are indeed system-wide).
Privileges are inheritable through group membership. This means that a group's "effective" privileges include the privileges from all its parents as well as its own "explicitly" set privileges. Changing group membership may impact the effective privileges (e.g. group B that belongs to group A, which has the Multimedia Management Privilege, will lose the privilege if removed from A, doesn't inherit it from any other group, and doesn't have it set explicitlly). If you change group membership the system will prompt you that privileges may be impacted.
Though there is an "explict" settings where groups keep a privilege regardless of there group membership, there is no "deny" feature for privileges. We anticipate that in practice, privileges will be given to a small set of select users, likely in a flat arrangement without too many inerited privileges. Adding "deny" or "override" features would be overkill in the first release (and may never be really useful to customers).
In my third post on privileges in this series, I'll propose some example setups that you may consider adapting to your next authorization project.