Content Security in Alfresco One
By: Jon Chartrand – Solution Architect
Locking down content is a primary concern for those leveraging – or considering – Alfresco One for its content management (CM) capabilities. Thankfully, Alfresco makes this simple by allowing and controlling access across five separate “tiers”, each of which provide opportunities for users and managers to specify and manipulate privileges to both users and groups. Beyond that, keep in mind that users, groups, and site participation can be controlled outside of Alfresco at the enterprise level with LDAP/Active Directory, Kerberos, NTLM, and others. This allows for IT-managed oversight and tight controls on the first two tiers of Alfresco security.
Platform Tier (Access/privileges to the application)
The Alfresco platform is relatively unique in that a user can be granted access to “just” the application itself. This means they cannot access or participate in any of the Site-based activities but they can log into Alfresco and utilize both the “My Files” and “Shared Files” portion of the personal dashboard. This creates opportunities for content to be shared or collaborated-on with a relative outsider to the platform without worrying about them accessing more sensitive materials contained within an Alfresco site. Those considered ‘Alfresco Users’ can be created in Alfresco directly by an administrator or provisioned in your enterprise SSO architecture.
Site(s) Tier (Access/privileges to the Site)
Alfresco’s repository and social functions are broken out into logical groupings called Sites. Each site represents one or more users engaged in a common theme, effort, or goal which has been granted its own area of the platform. More than just sharing files, users of the sites can collaborate with one another through calendaring and events, managing and updating a wiki, contributing to a blog, establishing lists of links, and other activities. For now, however, we’re going to examine security solely against the mirror of content management. Privileges within a site are dictated by the role each user is granted. This assignment can be managed either by a site administrator or at the enterprise level.
Users are granted one of four standard roles within an Alfresco site: consumer, contributor, collaborator, or manager. When focused on content, the role privileges shake out like this:
• Consumer: Read
• Contributor: Read, Upload, Create
• Collaborator: Read, Upload, Create, Checkout, Edit
• Manager: Full Control
This allows site managers the ability to grant a range of permissions to each user allowing them to participate in the consumption, contribution, collaboration, or management of content as necessary. Another additional feature is the ability to grant site-level roles to groups of users in Alfresco. This makes setting, managing, and revoking access for multiple users an extremely simple affair. When it comes to privilege overlap, such as for a user granted an explicit role by username and an inherited one through a group, Alfresco operates on a ‘most-permissions’ model. This means the user in this case would be granted whatever the widest permissions allowed based on either role assigned.
Folder(s) Tier (Access/privileges to the folder)
Within either the Shared Files or a sites’ Document Library, the content is managed by whatever logical organization of folders is chosen by the contributors or site manager. This makes both contribution and consumption a simple matter – just like using a Windows file share. The great thing about Alfresco folders though is that users can manage permissions on any self-made folder with a remarkably high degree of granularity.
The permissions window for a folder, seen here, provides an easy to manipulate interface for altering the roles and permissions everyone has to it. The first thing to note, however, is that folders automatically inherit the permissions of their direct parent. At the top of the screen you can see the checkmark next to “Inherit Permissions” which provides a visual indicator of this and requires that the user specifically undo this function (with a confirmation) to be able to set their own permissions. This process means users cannot “stumble” into setting custom permissions on a folder without an explicit and forewarned act.
Once the inheritance is removed, the user is now free to assign both users and groups to the folder permissions. Alfresco folders have a slightly different role-scheme than Sites do.
Rearranged from the order in the image to instead display by order of increasing permissions:
• Consumer can read content
• Editor can read and edit content
• Contributor can read and add content
• Collaborator can read, edit, and add content
• Coordinator can read, edit, add, and delete content (full access)
These roles mean that users have a wide range of options for how they would like others to interact with their folder(s) and the content within. The scenarios where this kind of non-inherited permission capability would have great value are nearly endless in a collaborative environment like Alfresco.
File(s) Tier (Access/privileges to the file)
Taking the next step through the tiers, Alfresco also allows customizing the permissions of individual files within each folder as well. Users who own the content or are designated managers of the site the content lives within can access and alter the permissions, making the same level of customizability at the folder level available at the file level. This is accessed in exactly the same way and with the same interface, making for a consistent experience when dealing with permissions.
Like folders, files inherit their permissions from their parent – in this case the folder the content currently lives in. Updating the permissions means first disabling (and confirming) the removal of that inheritance, but once complete the author or manager has access to the same set of roles as is available at the folder level. This means authors and managers have exceptionally granular control over their content; who can see it, who can edit it, and who can delete it.
Of course, we’d be remiss if we didn’t discuss some of the dangers this level of granularity can evoke. For example, if a file is set to allow PersonA access as a Collaborator but is then moved to a folder that PersonA does not have permissions to read, it effectively renders the file permissions moot. Likewise, if a site manager establishes specific permissions on a folder and an author overrides those permissions at the file level, this could lead to complications in accountability and auditability. As such, altering permissions at either a folder or file level is something that should always be considered carefully and in consultation with an administrator or site manager.
An optional addition to an Alfresco installation is the Records Module. This creates and enables an entire suite of Records Management capabilities within Alfresco One including locking, cut-offs, disposition schedules, freezes/holds, and comprehensive audits. When it comes to content, declaring something a record indicates to the environment that this item is complete and needs to be sealed for future discovery or destruction purposes. This declaration makes the content-now-a-record essentially inviolable to everyone but administrators and provides deep auditing capabilities – including storing the audit report as a record itself. While this tier of security isn’t customizable in the same way the others are, it certainly represents another way in which content can be secured and controlled in Alfresco One.
To review, the five tiers of security within Alfresco One are:
1. Platform (Access/privileges to the application)
2. Site(s) (Access/privileges to the Site)
3. Folder(s) (Access/privileges to the folder)
4. File(s) (Access/privileges to the file)
5. Record(s) (Cannot be changed)
Each of these represents a different level of control you have over your content in an Alfresco installation. This means you and your users have unparalleled control over who can see, upload, edit, and delete materials in a content management system which already provides so many benefits over traditional file shares like file versioning, collaboration, and workflows.
If you’re interested in learning more about security in Alfresco One or how Alfresco can help you keep your content under control while also enabling collaboration across your enterprise, let us know!