SDL Tridion CME Authorization

Any discussion for authorization or access to your Tridion setup should include rights, permissions, and scope otherwise you're missing part of the picture. Balance flexibility, security, and maintenance by understanding the basics, learning about patterns, and understanding how the rules combine.

Basics

SDL Tridion separates authorization into rights, permissions, and scope.

Rights = what you can do such as manage components or publish
Permissions = where you can do it (organizational item context including folders, structure groups, categories, but also target types) as well as how (read, write, delete, or localize)
Scope = which publications you can do it

I may have the right to walk where I want, but I may not have permission to enter your front door.

Too bad scope doesn't fit in that clever metaphor. Maybe think scope as jurisdictions where publications are local governments or localities... oh, never mind.

Don't do this. The first time I attempted to define an authorization model I came up with:

1. Give new user two groups:
• One of the default groups for rights
• Another group for permissions
2. Then set their scope in their membership for both groups.

This worked, but occasionally gave an author more authorization than expected--a Marketing chief editor would get the ability to publish HR content although they're supposed to only have read-only permissions for those folders, for example.

Good Patterns

I've since learned a better practice is to:

• Use the default groups for rights
• Create subgroups for permissions and scope
• Add users to the subgroups

Flexibility Has Costs
Colleague Andy Lim further explained that we can separate the subgroups for flexibility. Authors get one for scope and one for permissions so rather than "Global Marketing Chief Editor" you may have a "Global" group for scope and a "Marketing" group for permissions. Up to you if you want to combine these, but either way there is an n x m calculation in this. You could have fewer groups (n + m) but you still have up to n x m combinations.

Recommendations:

• chose a method, document it, but create only the groups you need up front
• avoid taking "full advantage" of the scope features just because they're available (thanks for the tip, Dominic) 

Keep it Simple

For the ultimate in easy configuration, keep the membership scope settings for the parent groups (for rights) and individual users set to "All Publications." These are set in a group's or individual user's member of tab.

This keeps scope management limited to a single layer, sandwiched by the less interesting top and bottom layers. You'll rarely have to update or troubleshoot rights groups nor individual users if you follow this. Also, by keeping rights consistent throughout the BluePrint, you get bonus reduced maintenance--new publications get the same group rights as their parents. This is significant because rights are not inherited down the BluePrint--you set them per publication.

With multiple variables, reduce the variations for consistency.

• Lots of subgroups with the exact same scope? Put the scope in a parent group, don't set it for each subgroup.
• Will Marketers always update news releases and biographies? Make a single Marketer group rather than one per folder.
• Will content editors update everything? Start with one group for now.
• Reduce groups. Reuse settings. Recycle that can of soda on your desk (sorry, nothing else fit).

Combinations

Scope reduces to the common subset of an author's membership in groups and those groups membership in other groups. Think intersection for scope.

Scope combines from group membership settings to limit.  We like to limit scope, right?

On the other hand, permissions are additive. If you have access to folder A from Group A and folder B from Group B, you get all of them.

Your permissions combine, like Captain Planet. "Mother, may I eat dessert and play video games?"

Be judicious in using the deny option. You can explicitly deny permissions to a folder, but it overrides all other permission settings and it's easy to forget (trust me). Read more on permission settings on SDLLiveContent.

SDL Buddy demonstrates how a permissions deny setting blocks any settings you may have already configured. Down in front, please!

Typically subfolders inherit their containing folder's permission settings, however you can remove this dependency. Note this is distinct from localizing folders, which I wouldn't recommend solely to manage permissions.


Rights. Permissions. Scope. All set? Start with (first training then) the above to balance flexibility, security, and maintenance. Remember that scope is an intersection whereas permissions are a union (additive). Deny settings can get in the way!


Don't worry, although you have multiple dimensions to juggle (rights, permissions, scope, groups, users, publications, folders, etc), permissions are fairly straightforward to test and change to fit your organizational needs (though potentially time consuming).


In a future post, I'll describe a solution for a brain-twisting requirement to manage permissions from a single parent publication.