User Management and Content Security

When we think about the security of our digital content, we often think in terms of backups. That makes a lot of sense. Backups are indeed a critical way to ensure the integrity and long-term security of digital content. It’s sometimes easier to forget about potential threats that come from inside your project team.

On most teams, people of different skill levels come and go over time. Some may be volunteers, some may be students, some community partners, or one-time contributors. All these users are likely to have an account on your website, and anywhere there is a website account there are likely to be security concerns. What happens when a team member has poor security practices (e.g. re-using weak passwords, leaving credentials on sticky notes around the office, etc.) that lead to unauthorized access by bad actors? What happens if a contributor goes rogue and begins to intentionally delete content? What happens if an inexperienced user just makes a big mistake that results in data loss or extended downtime? These scenarios are worth considering because they inform best practices around user management.

Let’s start with a description of the user roles available in Omeka, compiled from the official Omeka Users documentation, as well as a basic outline of the roles added by the More User Roles plugin.* Roles are listed in order of “power,” from most to least.

Overview of User Roles

The Super user role is built in to Omeka. This role should be assigned only to the “owners” of a site. That is, people who need granular control over every aspect of a project, including functionality and visual design, as well as user management (if you are reading. this, you might be a Super user). Super users can:

Do anything and everything in Omeka.
Supers are the only users with access to the top navigation tabs for Plugins, Appearance, Users, and Settings.

The Admin user role is built in to Omeka. This role should only be assigned to long-term “managers” of the site who need routine access to niche areas of the site, including plugin settings. Admin users can:

Add, edit, tag, and delete items/stories, both their own and created by other users.
Make items/stories, collections, and other content public or not public.
Make items/stories, collections, and other content features or not featured.
Add, edit, and delete Item Types.
Add, edit, and delete files.
Interact with plugins installed and activated by a SuperUser.
Add, edit, and delete tags.

The Editor role is added by the More User Roles plugin. This role should be assigned only to a select few users who are entrusted to edit and publish their own content as well as content created by others. They can also delete anything. Editor users can:

Add, edit, tag, and delete items/stories created by any user.
Make items/stories, collections, and other content created by any user public or not public.
Make items/stories, collections, and other content created by any user featured or not featured.

The Author role is added by the More User Roles plugin. This role is intended for users who are actively engaged in content creation and who can be trusted to publish their own content when it is ready. They can also delete any items they’ve added. Author users can:

Add, edit, tag, and delete items/stories which they created.
Make items/stories, collections, and other content they created public or not public.

The Contributor user role is built in to Omeka. This role is intended for users who are actively engaged in content creation but who are not allowed to publish their own content. They can delete any items they’ve added. Contributor users can:

Add, edit, tag, and delete items/stories which they created.

The Researcher role is built in to Omeka. This role is intended primarily for granting view-only access to non-public content. Researcher users can:

* Note that we are omitting the Guest User plugin since it doesn’t grant any specific capabilities on its own but instead relies on other plugins, none of which are officially supported by Curatescape. Refer to the user manual as needed.

Auditing User Accounts to Minimize Risk

As you may have noticed in the outline above, all user roles except Researcher do have at least some destructive capability, if only in the form of deleting one’s own content. Even if you trust your team 100% to act responsibly with their account privileges, you should still consider auditing your user accounts from time to time. Notice that here I’m referring to user accounts – not users. Users are people whom you can identify and evaluate. User accounts on the other hand can be operated by anyone who has possession of a username and password, or in some cases whomever happens to be using a particular device (like a shared computer or a lost phone). As such, each user account carries its own risk. The extent of that risk depends largely on the role assigned to a given account, and perhaps also on the amount of content created using it. If you have one user who has created 50% of your content, the fact that they are a low-level user may not matter if that account could still be used to delete 50% of your project’s content. So auditing your users is a great way to minimize your overall risk. Below are some tips for managing and auditing user accounts.

Be stingy when it comes to creating new user accounts. If a potential contributor is not going to become a long-term member of your team, perhaps they can just send you (via email, file-sharing, etc) whatever information they might be contributing. Not only does this minimize risk, it also saves time on training and makes it easier to enforce editorial standards!
Give users the fewest possible privileges, based on their actual needs and abilities. If you want to have final say over when content is published and featured, then don’t give your users the ability to do those things themselves.
Update user roles as needs change. If you need an editor for a specified task, assign that role to just one person and only until the task is complete.
De-activate dormant user accounts. At set periods – annually, quarterly, at the end of each semester – de-activate accounts belonging to users who will not be working on the project in the foreseeable future or who will be away for a period (for example, on sabbatical, studying abroad, taking a family leave, or just focusing on other life goals). You can always re-activate these accounts later. De-activating dormant user accounts is by far the most effective way to reduce the risk of data loss.

If your project is under contract with Curatescape and you are still worried about data loss after auditing your user accounts and taking other recommended steps to manage your users, rest assured that your hosted project website is fully backed up and recoverable in the event of a disaster. If you are hosting your own site on an external server, you probably have similar disaster recovery protections (be sure to check in with your hosting provider). As always, if you have questions about this or anything else, let us know.