Users are individual members, whereas groups are logical categorizations of users.

In Alfresco, a user is identified by a unique user ID, which is also known as the login ID. The administrator is like a superuser of the system. Alfresco identifies the registered users (users not logged in as a guest). The names of such logged-in users are shown on the top righthand corner of the Alfresco Explorer screen and the lefthand corner of the Alfresco Share.

Alfresco groups logically group a set of users in the system for the purpose of security and collaboration. A group can have any number of subgroups. There is a default group called EVERYONE , which represents all of 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 sometimes, to more than one department.

Permissions define access rights on spaces and content. Out of the box, Alfresco supports extensive permission settings on spaces and content. A more detailed description is provided in later sections of this chapter.

Permissions are identified by a string. For example, a particular permission such as ReadChildren, may be granted or denied to an authority—a user, a group, an administrator, an owner, and so on. The children of a node—subfolders or files in a folder—will inherit permissions from their parents. So, by default, the files in a folder will inherit their permissions from the folder. Permissions set on a node take precedence over permissions set on the parent nodes. Permission 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 nodes, spaces, space properties, subspaces, content, content properties, and business rules. The following are typical permission groups:

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:

The roles and permissions of Alfresco may be extended to support your requirements.

Alfresco imposes authentication by using a user name and password pair. Authentication is performed at the following entry points to the Alfresco repository:

When a call is made to the repository through the public service API, the caller must first be authenticated. This can be done by logging in using a username and password. Some applications and authentication mechanisms may support single sign-on. For example, a user can access the Alfresco repository through the Explorer program, or another application can access the Alfresco repository through the 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 in the Alfresco repository.

Alfresco imposes authorization by assigning a role to a specific user or group for a specific space or content object.

Spaces and content in Alfresco can be secured in a number of ways. By default, a space or content object in Alfresco can be managed only by the owner who created it. For each space, you need to give specific roles (a group of permissions) to specific users (or a 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 object level, and they may be different from security rules for its parent folder or space.

Let us refer to the previous figure where users Tom FinExec and Hope Fin both belong to the Finance group. Let us say that you have a space called Finance Department. You would like to give full access control to only those people who belong to the Finance group, and give Read access to those who belong to the Sales and Executive groups.

As an administrator for the Finance Department space, you can invite the Finance group as a Coordinator (full access), and Sales and Executive groups as Consumers (read access). Let us refer to the table given below, which shows examples of space structures and the roles assigned to specific groups and individual users on these spaces: