User Management in Your WCM System #wcm #pmot

I found this article interesting: User Management in Your WCM System #wcm #pmot – via Real Story Group Recent Blog Entries < Real Story Group

In our WCM selection advisory services, user security and entitlements continue to come up as tricky issues.  These are certainly not new challenges, but vendors address them in different ways, and certainly customers vary in their requirements here. 

So to provide a little education, below I’ve excerpted bits of the front matter from our Web Content & Experience Management Report.  The front matter is where we explain all the features against which we evaluate individual tools.   Hope you find it useful.  And as always, I welcome your feedback in the comments…  

Authentication & Authorization: Who’s Authorized To Do What

There are two key issues here:

  • Authentication: Are you who you say you are?
  • Authorization: What are you allowed to do?

Most Web CMS packages will tie into existing corporate directory systems (such as LDAP servers) for authentication, while providing authorization (what some call “entitlements”) within the CMS itself.

Let’s deal with authorization first. Many people can be involved in the production of even a departmental website. Since one of the key advantages of WCM is to distribute management capabilities directly to individual specialists, implementing a new CMS can lead to new people becoming involved in this process. 

In any case, you need a system to manage internal access and permissions that is much more robust than that required to support only one or two webmasters or editors

Users can be assigned privileges based on the role they play (the types of things they can do) or the group to which they belong, which defines their authority and, typically, the scope of the content areas they can edit. It is possible (and indeed not uncommon) for a user to make up a group of one.

Consider the following chart of Groups and Roles for a generic enterprise.

Example Groups Example Roles
  • HR Managers – Can only add and modify jobs and career info
  • Product Managers – Can update catalog content only
  • Graphic Designers – Can create and modify image files and templates site wide (may also be a role)
  • Librarians – Manage classification systems and metadata vocabularies
  • Germany — users who can only touch the content on your German site or subsite
  • Super user – Performs any function in the system
  • Editor – Contributes and approves content
  • Author – Contributes content
  • Department coordinator — adds and removes users and privileges for that department (only)
  • Intern – Adds metadata to site content

Note, however, that many vendors do not have notions of groups in their system, or have groups, but they are really roles.  That’s fine if you have just a handful of contributors, but once you start getting above 30 or 40 named users, it can become very cumbersome to manage.

So ideally your system lets you assign a combination of Groups and Roles. Using the chart above, let’s say that Nancy serves as an Editor in the Project Manager Group. She approves the additions and updates that Authors have made to catalog content.

Almost all CMS packages ship with generic roles already configured for your use. These products then typically enable you to modify those roles as necessary. However, not all CMS packages allow you to create completely new roles, and among those that do offer this capability, they may not be able to circumscribe functions in exactly the way you would like. For example, you may want your Interns to add and modify metadata, but have no other privileges, or for Managers to initiate workflow tasks, but not be able to author content. Ask prospective vendors to show you just how to make the roles and groups you think you need.

On the other hand, if you have very simple needs, stay cautious about products that offer highly granular control mechanisms. These can be hard to manage and the novice administrator can accidentally create problems, typically around locking editors out of sections to which they should really have access. This leads to staff annoyance and more trouble tickets for your help desk.

Finally, if you have a very distributed organization, look for the opportunity for delegated user management, where individual departments can control user persmissions — for just their department — but not be granted “god-like” superuser controls.  In some platforms, you have to have the highest security permissions to manage users, but most customers don’t want (or need) that.  

[This report section continues with a discussion of authentication — an important topic, for another time…]

Link to article: User Management in Your WCM System #wcm #pmot