Thoughts on Liferay Portal and Security: Part One

As an enterprise architect, it isn't enough to simply focus on aligning with the business. Stewardship of the technology you leverage within your enterprise (especially when it is open source) is also in order...



My early involvement with Liferay started back in the days of Liferay 2.1 when I created an integration with Netegrity Siteminder. Several versions later, I also integrated with XACML Entitlements Management products from Oracle and Securent (now Cisco). So security functionality has been part of my thought process very early on. Throughout the lifecycle of Liferay I have performed other activities such as being the first customer to get Liferay running on Azul Systems which is a specialized Java appliance that has 768 cache coherent cores.

I had the opportunity to perform the first security review of Liferay by using a now defunct binary-analysis tool from a vendor then known as AppScan. In order to be fair to the community, I will be updating my security analysis of Liferay in two parts, where the first part is to look at the security features of the product and to point out deficiencies I think need to be addressed and to at a later date (over the Christmas break) use two commercial static analysis tools to understand whether Liferay code was written securely.

Without further ado, here are my reactions of looking at the latest version of Liferay through the lens of security:

Enabling/Disabling users: Currently this is represented by a boolean value which indicates that you are either disabled or enabled. I believe that this should change to incorporate reasons for disabling. For example, if an account was disabled for reasons of spam/abuse, that is different than an administrator simply locking an account because the user is on vacation.

Identifiers: Many Liferay objects such as user, group, organization, etc leverage the Liferay counter model which provides an auto-incrementing value that is highly predictable. A better approach to such primary keys would be to support the notion of GUIDs which are more cluster-friendly and less predictable in nature. We no longer live in a world where disk space is expensive, so a few additional bytes won't hurt performance but could increase security.

IDs vs credentials: User identifiers as primary keys into databases should be kept private. There are many places within Liferay especially when interacting via remote services where this identifier is exposed. One optimization would be to have a servlet filter that allows for public credentials to travel over the wire and then be transformed into the private key implementation.

Siteminder: The traditional way to integrate with Siteminder was to either accept a cookie/header or to use the Siteminder SDK. Depending on how the former is deployed, there may be security gaps especially if you deployed a Siteminder agent on the web tier but not the application tier. Anyway, Siteminder like most products is moving away from proprietary SDKs to open standards such as SAML. There needs to be a way of integrating container-based SAML support into the Liferay security model.

Sanitizer: Liferay provides the ability to sanitize content via its com.liferay.portal.kernel.sanitizer.Sanitizer. This needs to be made more configurable (coarse and fine) and integrated with the OWASP ESAPI.

OpenID I am a big fan of OpenID and oAuth but these protocols do work over insecure (non-SSL) channels and therefore believe an administrator should be able to filter out ones provided by users that don't support SSL. Alternatively, for higher assurance sites using these protocols, you should also be able to specify a whitelist of providers.

Administrator: There needs to be two different types of administrators. Administrators that can create users and administrators that can create other administrators. You should also have the ability to restrict where adminstrator-level accounts can access the environment from. There would be something strange if an administrator who happens to be currently out of office accessing a bank site running Liferay from Iraq at midnight.

User Management: Liferay allows the ability for an administrator to open another browser window and browse the site as though you were the user. Imagine a scenario where you are using this on a company Intranet site and had a payroll portlet. There needs to be a way of specifying in the portlet's security model that this can only be seen by the real user and not via impersonation.

ServiceBuilder: This utility is used to describe a model's class and attributes. What would be a better place to describe the requirements for validation than here? Imagine the ability to tag an attribute with a Regular Expression that could provide validation capabilities. ServiceBuilder could ideally do several things with this information ranging from creating the appropriate database constraints to providing consistent validation whether accessed through portal or remote means.

Resources and Permissions: Liferay has a wonderful permissions framework that can handle many finer-grained authorization decisions but this still has certain gaps. The first gap is that you have to add resources into the permissions system by calling an API. In the scenario where you may want to implement something analogous to an XACML obligation, this model will require you to implement a new portal hook for each object type that only calls the addResources method so that you can then integrate it with a subsequent permissions call. For example, if you wanted to use the permissions framework to create a way for select portlets to be "available" during specified hours. An alternative way would be to allow for a given portlet/resource to support description of permissions in an extensible manner via its XML configuration.


Anyway, there are probably other things that I have not yet thought about but probably could be weaknesses, so all disclaimers apply. With that being said, you should feel confident in the fact that while no portal is ever 100% secure, there is a vibrant community looking out for your best interests when it comes to security and that Liferay is leading the pack in this regard. Something that cannot be said of many commercial implementations. Take note Gartner and Forrester...

An Enterprise Architecture viewpoint on state government...

In the same way a parent coaches their children to save money and be fiscally responsible, I humbly believe that the federal government needs to do the same for the states and local government...



Instead of making fun of the government and its approach to enterprise architecture, today I will instead propose three ideas that can help save all of us taxpayers money. Many people know that I am a registered republican and fiscal conservative. I am also passionate about encouraging others to pray, fast and be charitable and will look at government issues through these lenses. So, here are the three ways government can save money:

Implement a volunteer police force: Consider the scenario of how much of our budget is spent on law enforcement. Now consider the fact how it could be reduced if we allowed for volunteerism to enter the equation. My own background includes being honorably discharged from the United States Coast Guard which is not only a military fighting force but the police of our waterways. I can volunteer to get shot at by foreigners by enlisting in the military, I can volunteer to die in a burning building as a fire fighter but I can't volunteer to do traffic duty at the annual Thanksgiving day parade nor sit in a parked car with my lights flashing at a construction site?

Make English the official language: Have you ever considered how much additional expenses associated with printing and translation occur to support forms in other than English? Allowing volunteers to serve as translators has several additional advantages. First, when you take someone from the community and put them into a role that helps out others, you allow the government to form a more cohesive bond and can even provide support for languages not officially supported. You also make it easier for people to get government jobs and therefore can lower the pay scale if you had less requirements related to language. For example, if you wanted a state employee who knew enterprise architecture, speaks Spanish, Arabic and COBOL then your pool is limited. Once you remove the language restrictions, the job pool is increased making it fairer to all the citizens of the government to apply.

Consolidate identification systems: In the State of Connecticut, I hold various licenses and permits. Don't you find it a big waste of process in that the State Police administer a separate photo ID than say the department of motor vehicles? Of course you are asking yourself why would the state police trust DMV to issue a permit? While there needs to be additional due diligence at initial application time, why do you need it at renewal? In the state of Connecticut at each renewal, I have to prove that I am a citizen. I was a citizen when I first applied and kinda think that the odds are pretty good especially for us folk that are born in the United States that we will be a citizen in the future. For those who will argue that I could renounce my citizenship, I guess I would ask the question of why does this even matter? After all, I already got weapons that I purchased when I was a citizen anyway.

Did you also know that in the state of Connecticut, permits related to the building trades are governed by the department of public safety who also runs the state police? Why can't I renew my electricians and radio repair permit at the same time and same location? Taking this one step further, did you know that the state of Connecticut has non-police officers at the handgun permit desk doing renewals but if you want to renew your boxing (pugilism) license, it is handled by a police officer? Does this feel backwards to you?

Is your CIO an Agile Leader or a Conservative Manager?

Being Agile is the antithesis to being conservative. Agility while focusing on short-term delivery does not mean that you cannot take a long range approach. Having a clear vision for the team to rally around and the need for managementleadership to think ahead to ensure that we're not just moving forward, but moving in the right direction is of utmost importance...



If Agile is the antithesis to being conservative, would it be a far stretch for us to acknowledge that annual planning is the antithesis to innovation? Agilists are out there, every single day, responding to change, creating things no one has before. Agile leaders are open to new ideas, willing to take risks and comfortable with agile's level of change. If your CIO believes he needs a PMO organization to govern planning cycles then is he responding to change or more focused on creating documentation that can impede yet undefined forms of innovation.

Agile teams are about trust and couldn't function nor deliver without it. Leaders encourage trust by enlisting team member's strengths to achieve results and giving the team autonomy to make their own judgments about the best way to meet objectives. Managers on the other hand are savagely focused on taking care of HR review processes where the focus resides solely on one's competencies.

Agile leaders are passionate in ways that make the masses feel good about themselves, their employers and society at large. Managers may also exhibit passion but the feeling of warmth is only felt by the priveleged few. One way to spread passion is by also spreading empathy and caring for others. The best amongst the Agile community care about the human condition and will enquire first about your health and well-being while managers will only care whether you got your timesheet completed on-time...