I just thought that I will blog about a common issue that afflicts people getting started with Liferay Portal. If you tie Liferay Portal to a LDAP and you have different password policies on your LDAP versus Liferay, you can run into issues with users entering a valid password for their LDAP but they still cannot login to Liferay.

When I was playing with Liferay back in the v3.6.1 days, I had configured Liferay to authenticate using our Active Directory setup. I then turned people loose on Liferay and within the hour had complaints about some people not being able to login even though they were entering their correct password. It did not take me long to figure out that the issue related to the “password policy” configuration that comes out of the box with Liferay. The default configuration only allows alphanumeric passwords that are at least 4 characters long. So if a user has a password that contains any special characters (non-alphanumeric) then their login will always fail. Also, if your LDAP allows 3-character passwords while Liferay requires 4, then that can result in a failure.

To resolve the issue set the passwords.regexptoolkit.pattern property in portal-ext.properties in {$LIFERAY_HOME}\server\default\deploy\liferay-portal.ear\portal-ejb.jar. Here is a sample setting that I did to resolve the issue by adding a bunch of special characters as acceptable ones in a password.

##
## Passwords
##

    #
    # If you choose to use the default com.liferay.portal.pwd.RegExpToolkit as
    # your passwords toolkit, set the regular expression pattern that will be
    # used to generate and validate passwords.
    #
    # Note that \ is replaced with \\ to work in Java.
    #
    # The first pattern ensures that passwords must have at least 4 valid
    # characters consisting of digits or letters.
    #
    # The second pattern ensures that passwords must have at least 8 valid
    # characters consisting of digits or letters.
    #
    # The third pattern ensures that passwords must have at least 6 valid
    # characters consisting of digits or letters or a bunch of other special chars.
    #
    #passwords.regexptoolkit.pattern=(?=.{4})(?:[a-zA-Z0-9]*)
    #passwords.regexptoolkit.pattern=(?=.{8})(?:[a-zA-Z0-9]*)
    passwords.regexptoolkit.pattern=(?=.{6})(?:[a-zA-Z0-9~!@#$%\\^&*,.?/_\\-+=:;'"]*)

The reason for blogging about this a couple of years after I first ran into this issue is that I had a team member run into it recently. I figured there would be others who run into the same issue and rush to the judgement that their LDAP configuration is wrong whereas the real issue is simply that their password does not meet the default password policy requirements.

PS: Obviously this is just one scenario that may cause login issues; incorrect LDAP configuration is just as likely a scenario and there are many others as well.

***IGNORE THIS POSTING***

Do we not have enough poll and/or survey portlets in the “IBM WebSphere Portal Solutions Catalog” that we (Xtivia) need to go create yet another implementation? Obviously the answer from my perspective is that at least one more is needed by the world! The first and foremost reason for creating yet another poll portlet (YAPP) is that none of the existing ones are free – and I like free here!  Also, the team and I  wanted to have some fun building a potentially useful portlet that is generic in nature. So here we go launching the development of a polls/survey portlet that has full multi-lingual support, polls or surveys with multiple questions, multiple question types including multiple choice questions with radio buttons, checkboxes, and drop-downs, questions with simple text entry responses, rating type questions (similar to Netflix Start rating model) and more. We will be looking to determine our distribution model for this portlet but I do expect to live up to the essential requirement of it being PRICE=FREE! I hope to share information about this development effort as the team makes progress – keep in mind though that this portlet will see functionality being built in phases over time as the team can make time for the development. I expect us to have the first version of this portlet ready by end January with a subset of the eventual functionality. And if you are interested in getting this portlet before our distribution model is ironed out, feel free to reach out to me!

September 8, 2008 Update: I apologize for this but after months of internal wrangling I still have not been able to work out the model for sharing this portlet, and being swamped with client facing work, I have had to pull the plug on sharing this portlet for now. I will revisit this when I can make some time.

While setting up my sandbox Liferay install, I ran into a few issues/questions that in my opinion, the docs were not too clear on.

How do you set up default content for new users?

The first one was how do you set up default page hierarchies for new users. Essentially, in my case I have set up Liferay to perform authentication against our Windows Active Directory domain. So I do not have to explicitly create new user accounts in Liferay. As and when users login for the first time to Liferay, their Liferay portal accounts get created (i.e. created in the Liferay Portal database). I was not too clear after skimming through the Liferay documentation and playing with the administration, on how to set up default page hierarchies deploying standard/custom Liferay portlets for new users.

The answer was two-part. The first part involved creating groups (that are very different from the concept of user groups that I am used to) that are essentially communities and similar to virtual portals in the WebSphere Portal sphere. For each group, you can go edit pages using the administration portlet, and create the requisite page hierarchies with the relevant portlets laid out on those pages. Fairly straight forward and this part is pretty clear from exploring the product! Then came the question of how do I associate new users that do not exist in the Liferay Portal with the group(s) (or default page hierachies) that I had created. I explored the admin portlet but did not see anything obvious. On the user management screen, I saw the ability to create new users explicitly and below that were various other options that looked related to new user creation. However, I finally clicked on the “Default Groups and Roles” link below the new user creation form and that was the answer to my question. Basically, you can define roles and groups that are automatically assigned to new users. This enables you to set up new users with access to default page hierarchies.

Easy enough when you figure it out! However, there seem to be several issues here -

q The biggest issue is that Liferay is not aware of the external user repository. It is only aware of its internal user repository and users are only added there once users login to Liferay. So if my external user repository (LDAP – Active Directory being Microsoft’s implementation) has users and user groups set up, there is no default way to utilize the user groups in Liferay.

q Additionally a page hierarchy can only be visible to a single Liferay group. So if I want one set of users (group A) to see a page hierarchy, and another set (group B) to see the same page hierarchy but with one additional page, I have to create two groups and create the identical portions of the page hierarchy twice. Of course, if it is acceptable for a user from group B to see 2 different communities – group A with the common pages and group B with the single additional page, then Liferay’s model. Otherwise, it looks like a lot of unwelcome administrative overhead.

Switching to a more robust database after a bundled install

For initial investigation, I had chosen to perform a bundled install of Liferay with JBoss and Tomcat – this was pretty cool as I was able to have it running in a jiffy! However, after a couple of days I wanted to switch Liferay to using MySQL – this was pretty straightforward and simply involved creating a MySQL database, populating it with Liferay tables/seed data using a SQL script, plopping in the MySQL drivers in the JBoss lib folder, and updating the liferay-ds.xml file used for data source configuration. Pretty simple unless you do what I did – I renamed the liferay-ds.xml to liferay-ds.xml.original and configured MySQL using a new liferay-ds.xml. Well that ends up causing issues as JBoss ends up initializing from liferay-ds.xml.original as well. So only have a single liferay-ds.xml configuration file in the JBoss deploy folder!

Public and private events in the calendar

Somehow I was not too clear that the Desktop community home page is a private page that is specific to each user and that the calendar portlet on that page is not shared. So any events that you create on the calendar portlet on the Desktop community can only be private events. And the corollary to this is that all events created on any other community are public events that are visible to all users that have access to that community.

IMHO, it would have been a better design to have the “Add Event” capability accommodate the user being able to designate the event as a private or shared event. And for a shared event, indicate the groups with access to that event. And from an access control perspective, it would be easy to ensure that the user creating the event can only make the event available on the communities that that user has access to.

Currently if I have an event that I want to be visible to multiple groups, I need to create that event once for each group! L It should be pretty easy to modify the “Add Event” to support what I am suggesting. Maybe I will do real work for a change and I actually code a variant of the “Add Event” that implements my suggestion.

Signing off

I typed this up on my flight from Austin to Colorado Springs and it is time to sign off. However, I have quite a lot more to say about authorization in Liferay – I believe that there are significant limitations in this area. But overall, Liferay is certainly worth a look and can work for many organizations in the SMB space.

Took a hiatus from blogging for a whiiiiiiiiiiiiiiiiiile! Lots of interesting things have been happening but I have been lazy in keeping up my blog. More WebSphere Portal stuff has been happening, but I will not write about it this time. Finally decided to dump the product that no IBM development team wants to own – WebSphere Site Analyzer (aka Tivoli Web Site Analyzer) and switched to AWStats for site usage analysis. I love it as does the client! On another front, started using Unison for file system replication across two physical sites that have spotty connectivity – dumped another commercial product (SureSync) in favor of an open source one. SureSync seems to work well and does a good job of real-time replication when you have good connectivity, but breaks down pretty badly across bad connections when you have large updates on a site.

However, the thing I am pretty excited about is Liferay - an open source portal solution that looks pretty promising. I looked at JBoss Portal as well, but was far from impressed with that one. JetSpeed, I have looked at earlier and passed on it. Liferay seems to have quite a good breadth of functionality out of the box – a full-blown content management system, document management, image gallery, message boards, event calendar, polls, wikis, blogs and a few others. It seems like a good fit for mostly content oriented Portals for the SMB market. The only thing that is missing is adequate documentation, but that will happen with time and community momentum (or with Xtivia’s efforts – a plug for my employer ). It was a breeze getting the base product installed with bundles available with various open source Application Servers/Servlet Containers. I opted to go with the JBoss+Tomcat bundle. Setting it up to do authentication using our Windows Active Directory Server was not too bad – check out the Liferay forums if the product documentation does not cut it for you. Setting up Liferay to run as a service on Windows was as simple as using JavaService to run JBoss as a service. Setting up Liferay over SSL was as simple as putting Apache in front of Tomcat using mod_jk redirection. So far so good.

Now I need to experiment with customizing Liferay – custom portlets and custom look and feel. Will check out Liferay’s flexibility and see what is feasible in terms of layouts – will be comparing with WebSphere Portal where we have successfully implemented all kinds of layouts breaking navigation into n levels – used tabs, drop-down menus, and left navigation – all at the same time even.

Anyways – its been fun playing with Liferay!