Search code examples
javarequestliferayportlet

How to send sensitive data to a Liferay portlet from outside the Liferay portal

I've got a Liferay Portal (6.2 CE) with some Portlets (let's say Portlet A and Portlet B)

I'll be called from outside the portal (a third party from the internet) with some params (http://myUrl/myPath?param=X&[email protected]&info=moreUserPersonalData), and depending of the value of one of those params I need to display one or another portlet. Following the example, if param=A, go to portal page with Portlet A; if param=B, go to portal page with Portlet B.

Some of the params will be sensitive data and I need them to reach the final portlet A or B.

So, I've got different doubts...

Wherever I'll be called, I can decide its technology. I've managed:

  • A servlet. The main problem is that I cannot share the session between the Servlet and the Portlet, so I can't set there the params. I don't want to send it by GET (it's personal information) and any way to avoid that (like ciphering the data or saving temporarily in a database) looks too much complicated for such a simple task.
  • A landing portlet. I need to make the redirect with no user action needed, so the lifecycle of a portlet doesn't help me. The render phase (the one called when I land there) doesn't have the redirect method (looks like it goes against liferay's portlets politics) and I don't want to make a javascript autosubmit to reach the action phase.

So, in summary, I need to:

  • Be called from a third party
  • Manage some of the data sent by that third party
  • Redirect to a portlet, sending sensitive data not seen at the url
  • Decide the better technology to do that

Can you give me any suggestion?

Thanks in advance.

Solution

  • Secure IPC in Liferay

    This is mostly a placeholder until you clarify your requirements and functional specifications. I am going to present some security essentials related to the Liferay platform and associated technologies. I will make the advice as general as possible however full disclosure the bulk of my experience is 6.2 EE.

    Proposed solution

    I think the most obvious way to do this is to have one, or many, web services exposed to clients outside the portal. I would suggest you stay away from trying to accept all the data into a single web service and then routing it accordingly. Instead I suggest you create a web service for every particular end point (wherever you are routing data to) and call that point directly. Your client should be configured to send the data to the appropriate place. However, if for whatever reason you absolutely need to have a single end point to call, then I would suggest you create that end point by registering a jsonws through service builder and then using Liferays internal Spring AMQP bus to route the message accordingly.

    To register a JSON WS simply create a service builder entry as follows:

    <entity name="Entity" remote-service="true" local-service="true">

    In your JSR-286 Portlet that will create the following modifiable files

    • EntityLocalServiceImpl.java
    • EntityServiceImpl.java
    • EntityImp.java

    Your EntityServiceImpl file will generate code in EntityService (which will be the service you invoke externally). I generally suggest in EntityServiceImpl you write code that has to do with Liferay's permission checking / resource framework, and once that is successful you then call a method by the same name in the EntityLocalServiceImpl method. The local service method alone should be where you write to the message queue or database.

    To invoke your web service you can reference the million Liferay documents online related to JSONWS. Is is just a brief architectural overview, but I have general hardening steps for the entire stack below.

    Liferya Tech Stack Hardening

    Let's talk about how you currently have your portal configured. I am going to assume you are running one or many Tomcat application containers behind an Apache web server. However, if you are not running these specific technologies, the advice I am giving is interchangeable.

    1. Portal Version

    Make sure you are at least running the Enterprise Edition at 6.2 or DXP. Verify that your portal is at the most recent batch level for that release branch. I would suggest you go even further and make sure that you have every single hotfix as well (you can be at the highest patched version but still missing a hotfix).

    2. Portal Installation and OS

    I would suggest your harden your Tomcat server / portal installation by doing the following things.

    • Install inside a chroot jail.
    • Owner and group should be a non root user
    • Run your Tomcat instance with Java security manager, develop a java policy file specific to the needs of that Tomcat instance.
    • Enable, correctly configure, AND ENFORCE SSL at the Tomcat layer
    • Override all the default error pages (404, etc). Create a new page to display for any page that returns a java.lang.Exception
    • Protect your shutdown port
    • Make sure tomcat doesn't server index pages when welcome page's arent specific.
    • Changer permission bits on your portal_home/conf folder to 400/read only.
    • Remove server version in HTTP response headers
    • Strip and repackage ServerInfo.properties in the catalina jar.
    • Set secure flag for cookies
    • Add HTTPOnly for cookies
    • Make sure that you have iptables or some other firewall that closes all ports from the outside. SSH only from the inside. Only enable port 80 from outside (if its public facing) and drop the rest.
    • Deactivate the JSP deployment engine

    3. Web Server layer

    The web server layer will have general security measures similar to your Tomcat instance. It may be much more difficult to run your web server in a chroot jail or with a non privileged account though. It would be nice to have a real, enterprise IPS sitting in front of your web server (or load balancer if one exists).

    • Enable and properly configure SSL (for best security do this at the app container and web server layer). Disable ssl v2, v3, etc. This topic is way to big for a single bullet point
    • Remove information gathering abilities by removing/disabling ETag, directory listing pages, server name response headers,
    • Run your web server from an apache user with apache group (or whatever account you choose). You can attempt to make this a non privileged account but again it might be difficult.
    • Change the permission bits on the configuration folder to 750
    • Limit what type of Request methods you want to allow here (you can disable request methods like put, post, etc here). What do you obviously will determine how you configure this
    • Disable http 1.0
    • Disable trace requests
    • Set set your httponly and secure flag for cookies at this layer as well
    • Enable protection against click jacking, xss, etc.

    4. Liferay properties hardening

    There are several properties that you can toggle to harden your Liferay platform. Some very obvious ones (and their descriptions):

    Always keep the following two enabled

    auth.token.check.enabled=true
json.service.auth.token.enabled=true

    This relates to the p_auth get parameter you will see in the portal. The client is responsible for generating this token. If your client is outside the portal environment.

    If your client is outside the portal environment you can ignore tokens for particular origins

    auth.token.ignore.origins=.....

    Basically this will allow you to ignore the auth token requirements for particular origins. This is much better than ignoring for all.

    I would definitely suggest you forcing HSTS and again filtering based on request methods

    jsonws.web.service.strict.http.method=true
jsonws.web.service.invalid.http.methods=DELETE,POST,PUT
# Not necessarily filtering the above methods just an example

    To secure the webservice I would likely require basic authentication

    basic.auth.password.required=true

    With basic authentication you also need to make the specific web service endpoint public 

    jsonws.web.service.public.methods=.....

    Then a this point you need to configure basic authentication and user account on your tomcat/web server.

    I would further restrict access to the jsonws page, servlet, and services by using

    son.servlet.hosts.allowed=....
json.servlet.https.required=true
jsonws.servlet.hosts.allowed=....
jsonws.servlet.https.required=true

    You might also want to check out the AccessControlled annotation

    For basic authentication done right you need to look at the authentication pipeline examples.

    4. Additional Liferay hardening

    In addition to securing the web service I would probably secure your portal by:

    • Disabling the default administrator account using the default.admin.*properties,
    • Block the following pages
      • /c/
      • /api/
      • /usr/
      • /group/
    • Disable all the default portlets by filtering based on p_p_id
    • Seriously consider restricting WebDAV Servlet, Spring Remoting Servlet, Liferay Tunneling servlet, Axis Servlet.
    • Disabling unwanted/unused struts actions
    • Use JNDI of JDBC

    I realize this is basically just a big dump of information without much context but when talking this broadly about security its all applicable. I didn't even touch the data layer because you didnt mention persistence. StackOverflow is more helpful when you do the preliminary research, try to implement a solution, and run into a very particular problem. Hopefully this will put you in the right direction to a more pointed question