Monday, June 25, 2012
Liferay Portal: Authentication (Part One)
Today, I am starting a multiple part series where I analyze the security posture of Liferay Portal. My goal in doing so, is to help make application security visible and to help make Liferay the most secure portal on the planet. I humbly suspect that anything I uncover will be almost immediately addressed by the masses of contributors to the Liferay community.
There will be four parts to the series:
Administration Model
Liferay provides a robust administration model where an administrator is all powerful. This should be decomposed in a way that you can separate out administrators who can create other administrators vs administrators that can just create regular users. At some level, Liferay should have a separate security administrator role that separates out the ability to administer users vs an administrator that can administer portal functionality.
Interactive vs Service
Credentials tend to be issued for a particular usage scenario. Some credentials are meant to be used by users while others are meant to be used by services. Currently, there is no way to specify the intent for issuing a credential nor to enforce its usage in a channel specific way.
Credential types
Liferay stores username/email address and password combinations and tends to delegate other forms of credential handling to external providers such as Yale CAS, CA/Siteminder and so on. The delegation of this type of activity avoids making Liferay unnecessarily complex to maintain and helps keep it focused on being a good portal. With that being said, there are a few scenarios where this can be problematic.
In the scenario where Liferay is the destination (relying party) there is no issue. However, if Liferay is being used as a launch point (identity provider) then it requires a way for it to gain a handle on credentials other than what it natively uses. More importantly, a user may have multiple credentials based on the destination site a user may want to visit. I may desire to use Liferay in an Intranet scenario where I use it as a launchpoint to an outsourced payroll provider, healthcare insurance provider and 401K provider all who require a different set of credentials. Being able to administer the form of credential in one place can have value in a variety of settings.
Impersonation
Liferay has the ability to allow an administrator to impersonate the identity of another user. Generally speaking, this is a good feature in a support setting yet this is too coarse-grained. The ideal secure implementation would think of impersonation as a role where it is explicitly granted to a user. In highly secure scenarios, it may be appropriate to impersonate a user even when granted the right. This could be extended to say that certain users cannot be impersonated. Taking this one step further, you may want to disallow impersonation on certain portlets. Imagine what would happen if you could impersonate another user and you exposed payroll via a portlet.
| | View blog reactions- Authentication (AuthN)
- Authorization (AuthZ)
- Misc (catch all for topics not related to either authentication nor authorization)
- Static Analysis (Concerns found by using HP Fortity)
Administration Model
Liferay provides a robust administration model where an administrator is all powerful. This should be decomposed in a way that you can separate out administrators who can create other administrators vs administrators that can just create regular users. At some level, Liferay should have a separate security administrator role that separates out the ability to administer users vs an administrator that can administer portal functionality.
Interactive vs Service
Credentials tend to be issued for a particular usage scenario. Some credentials are meant to be used by users while others are meant to be used by services. Currently, there is no way to specify the intent for issuing a credential nor to enforce its usage in a channel specific way.
Credential types
Liferay stores username/email address and password combinations and tends to delegate other forms of credential handling to external providers such as Yale CAS, CA/Siteminder and so on. The delegation of this type of activity avoids making Liferay unnecessarily complex to maintain and helps keep it focused on being a good portal. With that being said, there are a few scenarios where this can be problematic.
In the scenario where Liferay is the destination (relying party) there is no issue. However, if Liferay is being used as a launch point (identity provider) then it requires a way for it to gain a handle on credentials other than what it natively uses. More importantly, a user may have multiple credentials based on the destination site a user may want to visit. I may desire to use Liferay in an Intranet scenario where I use it as a launchpoint to an outsourced payroll provider, healthcare insurance provider and 401K provider all who require a different set of credentials. Being able to administer the form of credential in one place can have value in a variety of settings.
Impersonation
Liferay has the ability to allow an administrator to impersonate the identity of another user. Generally speaking, this is a good feature in a support setting yet this is too coarse-grained. The ideal secure implementation would think of impersonation as a role where it is explicitly granted to a user. In highly secure scenarios, it may be appropriate to impersonate a user even when granted the right. This could be extended to say that certain users cannot be impersonated. Taking this one step further, you may want to disallow impersonation on certain portlets. Imagine what would happen if you could impersonate another user and you exposed payroll via a portlet.
