Terminologies

Earlier, we have addressed many terminologies regarding Liferay Portal. So here we're going to introduce a pattern: Portal-Group-Page-Content (PGPC). As you would expect, we are trying to summarize the main features and behaviors of the portal in a simple pattern.

First of all, let's examine a high-level overview of terminologies, scope and hierarchy in the portal. As shown in the following diagram, the portal is implemented by Portal Instances. The portal can manage multiple portal instances in one installation. Of course, you can also install multiple portal instances in multiple installations, separately.

Each portal instance can have many groups, which are implemented as organizations, communities, user groups, and users. Note that each user can be represented as a group by itself, since if a user is a power user, they will get public pages and private page as any group does. Here we can use the term Group Instance to present organizations, locations, communities, user groups, and users (there is only one user in a group). Each portal instance has complete isolation of the users, organizations, locations, and user groups. In particular, organizations have a hierarchical, for example, parent organization, child organizations, and location. Note that one page can have only one parent organization and many child organizations.

Each group has two sets of pages (that is, public pages and private pages, called layout-set); each page is implemented as a layout. Most interestingly, there is a hierarchy in layouts too, such as parent pages and child pages. Note that a page can have one and only one parent page and many child pages.

Each page may contain different content, which would be implemented as portlets. Thus the content will have different scopes. For example, the content would be scoped into page, group, portal instance and portal. This pattern is known as Portal-Group-Page-Content. We will address these terminologies, scope and hierarchy in detail in the coming sections and chapters.

Multi-tenancy

Liferay Portal allows us to run more than one portal instance on a single installation. Data used for each portal instance is maintained separately from every other portal instance. Portal data, however, can be kept either in the same database or in different databases. This is called database sharding.

This feature should be useful for Multi-tenancy, which is a principle in software architecture where a single instance of the software serves multiple client organizations (called tenants). With a multi-tenant architecture, the portal is designed to virtually partition its data and configuration and each client organization works with a customized virtual portal instance.

Let's have a brief look at multi-tenant capabilities. As shown in the previous diagram, a portal instance is implemented as a set of database tables such as Company, Account_, Shard, and VirtualHost. As you can see, portal instances are presented as different values of companyId; each portal instance has its own account information (presented as database table Account_), possible database (implemented as database table Shard_), and virtual host settings (presented as database table VirtualHost).

Role-based access control

Traditional membership security models address two basic criteria: authentication (who can access) and authorization (what they can do):

• Authentication is a process of determining whether someone or something is, in fact, who or what it is declared to be

• Authorization is a process of finding out if the person, once identified, is permitted to have access on a resource

The portal extends the security model by terminologies: resources, users, organizations, locations, user groups, communities, teams, roles, permissions, and so on. The portal provides a fine-grained, role-based permission security model (known as RBAC) - a full access control security model:

Resource, role, and permission

As shown in the preceding diagram, a resource is a base object. It can be a portlet (message boards, calendar, document and media library, and so on), an entity (message board topics, calendar event, document and media library folder, and so on), or a file (documents, images, applications, and so on). Resources are scoped into portal, group, page, and content model-resource and application (or called portlet).

Permission is an action on a resource. Portal-level permissions can be assigned to the portal (users, user groups, communities, and organizations) using roles. Group-level permissions can be assigned to groups such as organization and communities. Page-level permissions can be assigned to page layouts. Model permissions can be assigned to model resource such as blog entries, web, and content. Portlet permissions can be assigned to portlets such as View and Configuration.

A role is a collection of permissions. Roles can be assigned to a user, user group, site, location, or organization. If a role is assigned to a user group, site, organization, or location, then all the users who are members of that entity receive the permissions of that role.

User

A user is an individual who performs tasks using the portal. Depending on what permissions have been assigned, the user either has the permission or doesn't have the permission to perform certain tasks.

Additionally, a registered user who has the permission can have public pages and private pages. More interestingly, a user's private pages and public pages have the ability to use page templates which can be used to customize a set of pages. The pages — private/public — are configurable in properties. You can turn on or turn off access to these pages. Also, only a power user can use a private/public page. A guest is also a user.

Group

A group is implemented as an organization, user, and user group. A user is a group with only one member, that is, the user itself. An organization could be a regular organization and location.

Organizations represent the enterprise-department-location hierarchy. Organizations can contain other organizations as sub-organizations. Moreover, an organization acting as a child of a top-level organization can also represent departments of a parent corporation.

A location is a special organization, having only one parent organization associated and having no child organization associated. Organizations can have any number of locations and sub organizations. Both roles and users can be assigned to organizations (locations or sub organizations). By default, locations and sub organizations inherit permissions from their parent organization using roles.

A community (renamed as site) is a special organization with a flat structure. It may hold a number of users who share common interests. Thus we can say a site is a collection of users who have a common interest. Both roles and users can be assigned to a site.

A user group is a special group with no context, which may hold a number of users. In other words, users can be gathered into user groups. Users can be assigned to user groups, and permissions can be assigned to user groups using roles. Therefore, every user that belongs to that user group will receive those role-based permissions.

A team is a group of users under a community or an organization. A community or organization can group a set of users and create a team. The notion of a team is somewhat similar to a role, but a role is a portal-wide entry, while a team is restricted to a particular site or organization. Therefore, you can manage the permissions of a team like a role. That is, a team is like a site or organization role, but specific to a certain site or organization. A team is different from a User Group too. A user group has the scope of a portal, while a team is always exclusive to a site or organization.

In addition, each group can have public pages and private pages. Thus users in a user group can share private and public pages. More interestingly, a group's private and public pages do have the ability to apply page templates or site templates in order to customize a set of pages in a fast way.