Wednesday, June 27, 2012
Liferay Portal: Services (Part Three)
I previously blogged on several improvements that could be made by Liferay in order to improve authentication and authorization. Today, I am focused on needed improvements to the security of Liferay services..
.
The primary way services are created in Liferay is via Liferay's ServiceBuilder utilitiy. Below are several areas of improvement that can help increase the security posture of Liferay services.
Regular Expressions
The ability to perform web-based attacks such as SQL Injection, Cross-Site Scripting, etc comes down to the desire to properly validate input. When defining new elements, there currently is no way to define what is considered acceptable values. Use of Regular Expressions (RegEx) provides a good industry standard way to sanitized input. In defining a Regular Expression, it becomes possible to have the same validation logic not only for services, but to also propagate it up to user interface validations as well.
Enumerations
It is important to note that with a web services paradigm, validation is not just the responsibility of the service itself. If the ecosystem also leverages intermediary devices to perform XML validation (e.g. Vordel, IBM DataPower, etc) then they may also have the need to introspect. It is very easy from the perspective of WSDL to define everything as a xsd:String but reality says that there are lots of times when the actual values are constrained.
The ability to tag a <> table as a constraint could also help propagate up to an xsd:Choice. This would not only help with validation, but also help WSDL clients develop better code.
Encryption
ServiceBuilder when defining a new column does not currently allow a column to be defined as sensitive. This could be useful in scenarios where you may need to store a credit card number or other financial, health, personal identifiers. The ability to encrypt a particular column whereby the key used is specified for each company would help improve data at rest.
Listings
Liferay provides the ability to list all services registered by the Tunnel Servlet. Sometimes, you need the ability to specify when a service should not be listed. Likewise, the level of granularity applied to listing needs to be more than just whether a service is remotely accessible or not, but to restrict listing by access method (e.g. JSON, REST, etc)
Concurrency
There currently is no way to constrain concurrency on particular services. For example, there is a service that allows for manipulation of the configuration for a Company (Tenant). What good reason would there ever be for hundreds of simultaneous callers?
There should be a way to tag a given service with some constraints as to how many calls can run at the same time. This is equally useful for services that consume lots of resources: either lots of I/O and/or CPU. Tagging in this manner may help prevent denial of service. Lifeway would also need to define a filter interface on the tunnel servlet to provide an enforcement mechanism related to concurrency.
| | View blog reactions.
The primary way services are created in Liferay is via Liferay's ServiceBuilder utilitiy. Below are several areas of improvement that can help increase the security posture of Liferay services.
Regular Expressions
The ability to perform web-based attacks such as SQL Injection, Cross-Site Scripting, etc comes down to the desire to properly validate input. When defining new elements, there currently is no way to define what is considered acceptable values. Use of Regular Expressions (RegEx) provides a good industry standard way to sanitized input. In defining a Regular Expression, it becomes possible to have the same validation logic not only for services, but to also propagate it up to user interface validations as well.
Enumerations
It is important to note that with a web services paradigm, validation is not just the responsibility of the service itself. If the ecosystem also leverages intermediary devices to perform XML validation (e.g. Vordel, IBM DataPower, etc) then they may also have the need to introspect. It is very easy from the perspective of WSDL to define everything as a xsd:String but reality says that there are lots of times when the actual values are constrained.
The ability to tag a <
Encryption
ServiceBuilder when defining a new column does not currently allow a column to be defined as sensitive. This could be useful in scenarios where you may need to store a credit card number or other financial, health, personal identifiers. The ability to encrypt a particular column whereby the key used is specified for each company would help improve data at rest.
Listings
Liferay provides the ability to list all services registered by the Tunnel Servlet. Sometimes, you need the ability to specify when a service should not be listed. Likewise, the level of granularity applied to listing needs to be more than just whether a service is remotely accessible or not, but to restrict listing by access method (e.g. JSON, REST, etc)
Concurrency
There currently is no way to constrain concurrency on particular services. For example, there is a service that allows for manipulation of the configuration for a Company (Tenant). What good reason would there ever be for hundreds of simultaneous callers?
There should be a way to tag a given service with some constraints as to how many calls can run at the same time. This is equally useful for services that consume lots of resources: either lots of I/O and/or CPU. Tagging in this manner may help prevent denial of service. Lifeway would also need to define a filter interface on the tunnel servlet to provide an enforcement mechanism related to concurrency.
Tuesday, June 26, 2012
Liferay Portal: Authorization (Part Two)
Previously, I blogged on ways Liferay Portal could improve its approach to authentication. Today, I am focused on authorization and entitlements...
The model for how Liferay handles authorization and entitlements is rock solid. It can not only handle defining both coarse and fine-grained entitlements within its own but can also be easily externalized to third party products such as Axiomatics, Securent and others that leverage the XACML standards. This is easily accomplished by implementing the Liferay PermissionsChecker interface and registering it with Liferay.
Still there are a few gaps that it doesn't quite account for. Below are a few scenarios that come to mind.
Availability
When developing portal-based applications, especially those that invoke downstream services, one cannot always count on a resource being available especially in an enterprise setting. Many systems have scheduled outages whereby it makes zero sense to even present an option to the user to invoke them. The ideal scenario would be to have the ability to define a calendar object where an administrator could attach the availability to a given portal resource.
The calendar could either enumerate times of availability or inavailability depending upon culture. Equally there are times where you may not want users to access the portal in its entirety and this could equally be accomplished by first making the Login portlet unavailable. In addition to needing some way to express a calendar, Liferay would also need a way to propagate available/unavailable messages to portlets.
Credential strength
When Liferay is used in higher profile applications, it becomes vital to understand what exact credential was used at authentication time. Surely, we understand that authenticating via username/password would be less secure than authenticating via digital certificates.Taking this one step further, you may sometimes need to restrict access to a resource if they used a lower strength credential to authenticate.
Location
Imagine standing up a banking application using Liferay portal. Would it ever make sense to allow an administrator to perform administrative activities when his/her IP address indicates they are currently in Iran? The ability to restrict highly privileged accounts is a given. It is sometimes important to also restrict regular users from accessing certain resources as well. For example, what if you wanted to have a policy that allows a person to view their paystubs via a portlet but only from a work location? One could always embed these types of checks within the portlet itself, but doesn't it make sense to not couple a security concern with business functionality.
Secure Channel
For applications that handle sensitive information, whether credit cards, health information, etc, an administrator should be able to define certain resources as being accessible only via a secure channel.
| | View blog reactionsThe model for how Liferay handles authorization and entitlements is rock solid. It can not only handle defining both coarse and fine-grained entitlements within its own but can also be easily externalized to third party products such as Axiomatics, Securent and others that leverage the XACML standards. This is easily accomplished by implementing the Liferay PermissionsChecker interface and registering it with Liferay.
Still there are a few gaps that it doesn't quite account for. Below are a few scenarios that come to mind.
Availability
When developing portal-based applications, especially those that invoke downstream services, one cannot always count on a resource being available especially in an enterprise setting. Many systems have scheduled outages whereby it makes zero sense to even present an option to the user to invoke them. The ideal scenario would be to have the ability to define a calendar object where an administrator could attach the availability to a given portal resource.
The calendar could either enumerate times of availability or inavailability depending upon culture. Equally there are times where you may not want users to access the portal in its entirety and this could equally be accomplished by first making the Login portlet unavailable. In addition to needing some way to express a calendar, Liferay would also need a way to propagate available/unavailable messages to portlets.
Credential strength
When Liferay is used in higher profile applications, it becomes vital to understand what exact credential was used at authentication time. Surely, we understand that authenticating via username/password would be less secure than authenticating via digital certificates.Taking this one step further, you may sometimes need to restrict access to a resource if they used a lower strength credential to authenticate.
Location
Imagine standing up a banking application using Liferay portal. Would it ever make sense to allow an administrator to perform administrative activities when his/her IP address indicates they are currently in Iran? The ability to restrict highly privileged accounts is a given. It is sometimes important to also restrict regular users from accessing certain resources as well. For example, what if you wanted to have a policy that allows a person to view their paystubs via a portlet but only from a work location? One could always embed these types of checks within the portlet itself, but doesn't it make sense to not couple a security concern with business functionality.
Secure Channel
For applications that handle sensitive information, whether credit cards, health information, etc, an administrator should be able to define certain resources as being accessible only via a secure channel.
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.
