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.
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.
The system performs checks to avoid allowing non-admins to give themselves or others users the administrative privilege.
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).
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):
This last right could be used to give select users the ability to:
Here are some things to keep in mind when working with privileges.
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.
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:
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.