Liferay Groups Benchmarking

Liferay

These are excerpts from a July interview with Daniel Tyger about groups and roles at Antioch University. During our talk Dan contrasted Sakai unfavorably with Liferay, a portal-and-collaboration product.

Antioch is a widely dispersed multi-campus university which emphasizes collaboration within campus-wide communities, programs, departments, and cohorts, rather than rigid class-centric hierarchies. There's been a lot of dissatisfaction with Sakai's "tunnels". He's finding the Liferay Portal (currently being readied for production deployment) to be a much better fit.

They integrate the university's identity management system by creating hundreds of populated groups in their LDAP server. (E.g., "ANE-All", "ANE-Students", "ANE-Alum", "ANE-Staff", "ANE Human Resources", ...) In turn, LDAP provisions Liferay with corresponding "User Groups". Each group gets a community space. Within a community space (or just "a community"), there are two types of pages: public (to everyone, including search engines) and private (available on equal terms to every logged-in member of the community).

Another type of content control is given to individuals via their Profile area. Blogs, wikis, and so forth can be added there, and more fine-grained rights ("access", "write", "comment", "configure") can be assigned to "Roles". Roles are also used to combine User Groups to be treated as a unit. This allows for all kinds of like-minded or like-purposed groups outside the usual course groupings to obtain automated membership spaces.

RAY: "Liferay's use of "role" seems very odd to me and I may still be off on the details. FWIW, a Google search shows that it confuses some customers, as well."

DAN: "Liferay roles are confusing, but so are Sakai role creations and realms. The fact is, I've been fully aware of Sakai's complexity for years (and still doesn't meet these needs, even when you try hard for "workarounds..."), yet in Liferay, within a week or so, we figured out their structure and it does meet all of these needs.

As a pluggable enterprise-integrating collaboration suite, Liferay may be worth a closer look, even though Dan is the only Sakai user who's mentioned it to us so far. Here are some starting points for further research:

Liferay conceptual overview

It certainly sounds flexible, but I suspect some vocabulary sprawl... Anyway, here's what I've gathered from the administration manual without benefit of actually trying the product.

  • Users : The usual, authenticated in all the usual ways.
  • Pages : The unit of content, containing portlet instances, child pages, and so forth. The pages themselves are either "public" (viewable by everyone) or "private" (seen only by the collection of users associated with them, as described below). The contents of those pages – in particular the functionality of embedded portlets – may involve considerably more complex access rights...
  • Organizations : Hierarchical non-joinable collections of users. Users can belong to multiple organizations and belong to multiple children under a single top-level organization. Organizations get to have their own pages, which organization members see when they log in.
  • Location : A child of an organization which cannot itself have any children.
  • User groups : Flat non-joinable collections of users. A user group doesn't get its own pages space, but it can get its own set of page templates (including embedded portlets) which will show up when the user logs in.
  • Communities : Flat collections of users, organizations, and user groups. Communities can be openly joinable, joinable by request, or managed privately. Tags can be used to suggest connections between joinable communities. Communities get their own pages. There's a default pseudo-community called "Guest" to handle the public-facing part of the site. It's also easy to make a community equivalent to every authenticated user in Liferay. Community templates can be created, containing a default set of pages and portlets.
  • Roles : Roles describe some function. A user may have (or "be a member of") a role across Liferay, or within the scope of an organization, or within the scope of a community. User groups can also be given roles (or "be added to" a role). A user may have multiple roles in any context. Out-of-the-box there are three organization-scoped roles and three community-scoped roles: Administrator, Member, and Owner, with all members having the Member role. Roles are assigned permissions.
  • Permissions : There are some portal-wide permissions (such as the ability to create new Communities), and a larger set of portlet-specific permissions (much like Sakai 2's tool-defined permissions). A screenshot shows 20 different permissions for the Message Boards portlet alone. When you set a permission for a role, you can specify whether it applies across the entire installation or is scoped to the particular community or organization page that contains the portlet. (One imagines amusing results should these scopes be randomly set.) I haven't seen it explicitly stated, but my assumption is that if any of your roles has a permission granted, you get it.
  • Groups integration : LDAP groups can be mapped to Liferay user groups. Mass import, user-by-user synchronization on login, and exporting of changes are all supported.

Looking at all this, it struck me that it would be natural to feed the hierarchical non-joinable organization memberships from LDAP (since a company's LDAP groups are likely to model the enterprise's organizational structure), but there didn't seem to be a way to do that. As it turns out, I'm not the first to notice this gap...

UX notes

Again, I haven't gotten to try the suite out, and so I've gathered what I can from the documentation.

The web-supported workflows for creating and managing organizations, user groups, and communities don't look particularly remarkable:

The user profile page gives a nice centralized spot for person-centric exploration, though, as shown here. I haven't found screenshots of organization membership browsing, so that remains a mystery.

Perhaps the most interesting positive feature is Liferay's web-based support for integrating with LDAP authentication, personal information, and group memberships. Among the Sakai community, LDAP seems by far the most common delivery mechanism for person and group directories, and is also frequently used to authenticate. As Dan confirms, optimizing the administrative UX for LDAP could be a wise investment.