Alfresco membership and security model
A content management system requires a membership system for its users to access content, setup user preferences, and to allow its users to receive notifications and alerts. Members of the system can collaborate with other members by selectively sharing documents, and sharing ideas via discussion forums. Members can control and follow the business process through a workflow.
Traditional membership models address basic authentication (who can access) and authorization (what they can do). Alfresco extends this model by providing capabilities to manage groups and subgroups of members, member attributes, and member workspace, and provides a set of administrative tools to configure and control the membership.
Users and groups
Users are individual members, whereas groups are logical categorizations of users.
In Alfresco, a user is identified by a unique user ID, also known as login ID. The administrator is like a super user of the system. Alfresco identifies the registered users (users not logged in as guest). The name of such logged-in user is shown on the top right-hand corner of the Alfresco Explorer screen and left-hand corner of the Alfresco Share.
Alfresco groups, logically group a set of users in the system for security and collaboration purpose. A group can have any number of subgroups. There is a default group called EVERYONE, which represents all the users of the system.
A user can belong to more than one group and subgroup as shown in the following diagram. For example, the user Mike ExecEngg belongs to two groups: Executive and Engineering.
A group can have more than one user. For example, the Sales group in the following diagram contains two users: Amit Sales and Candace Sales.
A user belonging to a subgroup will automatically belong to the parent group. For example, Chi EnggDoc belongs to the Engineering Documentation subgroup, and thus automatically belongs to the Engineering group.
This is how a typical organization's hierarchy works. An employee belongs to a particular department or some times more than one department.
Permissions and roles
Permissions define access rights on spaces and content. Out-of-the-box Alfresco supports extensive permission settings on spaces and content. In Alfresco, users are assigned a set of permissions on a content, which would define user's access right and control user's actions on that content. Permission sets an association between user and content. More detailed description is provided in Securing your spaces and Securing your content sections of this chapter.
Permissions are identified by a string. A particular permission, for example ReadChildren, may be granted or denied to an authority: a user, group, administrator, owner, and so on. The children of a node will inherit permissions from their parents. So by default, the files within a folder will inherit their permissions from the folder. Permissions set on a node take precedence over permissions set on the parent nodes. Permissions inheritance may be turned off for any node.
A permission group is a convenient grouping of permissions such as Read made up of ReadProperties and ReadChildren. Each one of these permissions is applicable to node, space, space properties, subspace, content, content properties, and business rules. The following are typical permissions groups:
- Read
- Edit
- Add
- Delete
Roles are collections of permissions assigned to a user. Each role comprises of a set of permissions. Alfresco provides out-of-the-box support for the following roles:
- Consumer: This role can read content
- Editor: This role can read and edit content
- Contributor: This role can read and add content
- Collaborator: This role can read, edit and add content
- Coordinator: This role can read, edit, add and delete content (full access)
Alfresco roles and permissions may be extended to support your requirements, refer Extending security permissions and roles section in later part of chapter.
Authentication
Alfresco imposes authentication using the user name and password pair. Authentication is performed at the following entry points to Alfresco repository:
- Web client
- CIFS
- FTP
- WebDAV
- Web services
- Web Scripts
- Spring beans exposed as public services in Java
For example, a user can access Alfresco repository through Explorer program or another application can access Alfresco repository through web services protocol. No matter how a user or an external system connects to Alfresco, they all should go through the same authentication process to access data from the Alfresco repository.
How is security imposed in Alfresco?
Alfresco imposes authorization by assigning a role to a specific user or group for a specific space or content.
Spaces and content in Alfresco can be secured in a number of ways. By default, a space or content in Alfresco can be managed only by the owner who created it. For each space, you need to give specific roles (group of permissions) to specific users (or group of users) to set the permissions on that space. Subspaces may inherit parent space permissions. Security rules may be specified at the individual content level that may be different from security rules for its parent folder or space.
Refer to the previous figure, where users Tom FinExec and Hope Fin both belong to the Finance group. Let us say you have a space called Finance Department and you would like to give full access control to only people who belong to Finance group and give Read access to the people who belong to Sales and Executive groups.
As an administrator to Finance Department space, you can invite Finance group as Coordinator (full access) and Sales and Executive groups as Consumer (read access). Refer to the table given below which shows examples of space structure and roles assigned to specific groups and individual users on a space:
