Portal Architecture

Before we dive into the user interface for adding and maintaining various portal resources, we should survey the concepts Liferay uses to organize a portal. Portals are accessed by users. Users can be collected into user groups. Users can belong to organizations. Organizations can be grouped into hierarchies, such as Home Office → Regional Office → Satellite Office. Sites can be created independently or can be attached to users or organizations. Within sites, users can belong to teams, which are groupings of users for specific functions within a site.

---

tip

Note: Prior to Liferay 6.1, independent sites were called communities. Both organizations and communities had their own sets of public and private pages. Starting with Liferay 6.1, organizations can't directly have their own sets of pages--only sites can. Organizations need to have attached sites in order to have pages. This is just a reorganization of ideas intended to simplify how Liferay manages pages.

---

A simple way to think about this is that your portal has users and various ways to group them together. Some of these groupings may be organized hierarchically by an administrator. These are called organizations. An administrator can also create more ad hoc groupings of users called user groups. User groups can be composed of users who do not fit into a particular hierarchy or who belong to different organizations. Other groupings may be created by the users themselves. For example, users from different organizations could create a site called "Dog Lovers" and allow anyone to join. The site would not fit into an organizational hierarchy; it would just serve a common interest in dogs. Administrators can create teams within sites. The following figure illustrates how users can be grouped in Liferay Portal: users can belong to sites, organizations, and user groups and user groups can belong to sites and organizations.

Figure 1.8: Liferay's User Collection Model

Liferay manages permissions for users and collections of users via roles. Roles can be scoped to grant permissions within a particular organization or site. They can also be scoped to customize permissions that cut across the entire portal. For example, a Message Boards Administrator role could be created that grants permissions to administer any message board in the portal. Users from multiple organizations or sites could be assigned to this role. Alternatively, a similar role could be created that grants those permissions only for a particular organization or site. Roles provide a powerful mechanism for administrators to configure portal resources and security in a consistent and robust manner. The figure below illustrates permissions defined by roles for users and collections of users. Permissions can't be directly assigned to users. Users receive their permissions from roles, either directly, or from an organization, user group, or site.

Figure 1.9: Liferay's Permissions Model

Teams belong to individual sites. Roles that appear inside sites are scoped just for sites. This means that although each site in the portal may have access to a particular role with its configured permissions, membership in this role can be different for each site and the granted permissions only apply within one site.

Users

Users represent physical users of the system. These are the user accounts that people use to log into the system. By default, users get their own private sites with public and private pages that they can manage themselves. Users' personal sites are important: they enable users to have their own public blog or their own private calendar, a place to store their documents, and more. If, however, you don't want users to have personal sites, this default behavior can be turned off by a portal administrator in the portal-ext.properties configuration file (see chapter 14). Liferay uses site templates to control the default portlets that appear on the public and private pages of user's personal sites. See chapter 3 for information about templates.

Users can be collected in multiple ways. They can be members of organization hierarchies, such as Liferay, Inc. → Security → Internet Security. They can be collected into arbitrary user groups, such as Bloggers, which could be used to set apart users who get a Blog page in their personal space from users who do not. Users can become members of independent sites which serve to draw together common interests. Users can have roles which define their permissions in the portal. These roles can be scoped by portal, organization, or site.

User Groups

User groups are simple, arbitrary collections of users, created by administrators. You can make a user group a member of a site or organization. This makes each member of the user group a member of the site or organization. Permissions can't be directly assigned to user groups, but user groups can be assigned to roles. If you assign a role to a user group then each member of the user group will be assigned that role (and thus the permissions defined by the role). Although user groups can't have sites, they can have site templates which can be used to customize users' personal sites. We describe this in more detail below.

Roles

There are three kinds of roles:

• Portal Roles

• Organization Roles

• Site Roles

We refer to these three kinds of roles as role scopes. Roles are used to define permissions across their scopes: across the portal, across an organization, or across a site. For example, consider a role which grants access to create a Message Board category. A portal role would grant that access across the portal, wherever there was a Message Board portlet. An organization role would grant that access within a site attached to the organization. A site role would grant that access within a site.

Roles can be assigned to users, user groups, organizations, and sites. Note: It is important to understand Liferay's portal architecture concepts before assigning roles. For example, assigning roles to an open site could create a security problem within your portal. An open site means that users are free to join and leave. So assigning a role to an open site potentially grants the permissions defined by that role to every user in the portal. Open, restricted, and private sites are discussed in the Sites section.

Organizations

Organizations are hierarchical collections of Users. Organizations can't have pages directly associated with them. Instead, sites can be attached to organizations. There is also a special type of organization called a location, which can't have any suborganizations. If you represent an organization by a tree diagram, locations would be leaf nodes.

Organizations in Liferay are meant to model organizations in real life. They are handy for defining where a user belongs in a particular hierarchy. For example, if you are implementing Liferay for a large organization, it might help to define user Joe Smith via his position in the organization chart. If Joe Smith is a Sales Engineer located in the New Jersey office, working in the North East division of the Sales department, he might be a member of the following organizations:

• Sales

• New Jersey Location

• North East Division

Now imagine that you have placed an Asset Publisher portlet as a static portlet on every user's home page (via a user group page template) so that you can inform employees of various announcements via the content management system. If you tagged your content appropriately, you could ensure that Joe Smith gets any announcements that are meant for Sales, the North East Division, or the New Jersey location.

Organizations need sites in order to have pages. If certain users have been granted the manage pages permission, they will be able to create and maintain pages within an organization. They can use the organization's public pages to include information or applications appropriate for guests or logged-in users who are not members of the organization. For example, a member of an IT organization might place a help desk ticket entry system portlet on a public page of the organization's site. The IT member could create a private page on the organization's site for applications for the organization's own use. For example, a back-end portlet of the aforementioned ticket entry system portlet could be placed here.

Sites

Sites are simply collections of pages. Sites can contain public pages, which are accessible to all portal users, and private pages, which are only accessible to site members. Liferay's default pages are part of a site named for the portal because all portal users have a common interest in the default, public pages of your site. There are three types of sites:

• Open

• Restricted

• Private

An open site (the default) allows portal users to join and leave the site whenever they want to, using the control panel or a My Sites portlet added to a page which they can access. A restricted site requires that users be added to the site by a site administrator. Users can request membership in a restricted site using the control panel or the My Sites portlet. A private site is just like a restricted site except that it is invisible to non-members in the control panel and in the My Sites portlet. Users can only be added to a private site by a site administrator.

Teams

Teams are sets of users with similar permissions within a site. Teams can be created both within sites that are attached to an organization and within independent sites. Teams are different from site roles since teams appear only in the site in which they are created. This is very useful if you need to create a team of users for a specific purpose within a single organization or site and not for each site in the portal.

Teams can be essential for some use cases since they can be created by site administrators. Site administrators can't create roles, so the ability to have teams empowers them to manage permissions at a level they weren't capable of previously.

---

tip

Generally speaking, Site Administrators cannot view or access the content of the portal as a whole, but only have access to the content and resources of their own Site. However, if they are managing users in the Users and Organizations interface, they can view all of the users and organizations on the entire portal. They need this capability to effectively add and manage the users of their own site, but if privacy is a concern on your portal, you will need to be concious of which users are granted the Site Administrator role.

---