Develop Reference

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=myUser#email.address&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.

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

Create a website made with SSL/TLS security encryption.

Providing LDAP support on top of existing Database authentication

I am working on a java application having Database authentication using spring-security.
It is very usual that, this application is used with other applications on similar domain.
Requirement: The need is that all such partner apps should be able to share common authentication with my application.
Also it is required to continue supporting DB authentication as well.
One way I found is to embed LDAP server like ApacheDS in my application so that other partner apps can use it to get authenticated.
In this case, I need to load ApacheDS with related Database records and keep it in sync programmatically.
But disadvantage on this is to have redundant copy of authentication data - one at DB and another at ApacheDS LDAP.
Question: Is there any way to avoid such duplication. By googling, I found option of having virtual directory server Penrose or Oracle Virtual Directory. But unfortunately they cannot be embedded in application. Is there any way to provide embedded LDAP support on top of existing Database authentication?

Disclaimer: I know very little about Spring Framework and even less of Spring Security
Having said that. I did face a similar situation, in my case, it was Apache DS as my app authentication source and client AD as the other.
My deployment environment was Tomcat and I used Tomcat Combined realm, which nests more than one realm for authentication. My app realm was configured to be one and client's AD was configured to be another.
Users could authenticate from any one of the realm, it worked. However, I did have to replicate client's AD users every night (including AD tombstones to mark them inactive), for authentication is one thing but other client information was also required, e.g. email, roles etc. and inclusion of new users.
I am kind of sure that Spring Security will also have the concept of Combined Realm.
I understand that this answer is not really an answer and more of design approach and many years too late at that; however, I wished to share my experience.

Does Websphere 8.5 provide an API to interface with an Active Directory using security details configured in Websphere security settings?

I am using Websphere Application Server, that has administrative and application security enabled, which uses LDAP to interface an Active Directory for authentication.
The web application that is deployed to the server is required to be able to retrieve information from this AD, as well as modify information in this AD (such as adding a new user to the AD). I could use JNDI to achieve this, however I need the application to use the settings configured in Websphere to do the connection so that I don't have to maintain multiple sets of LDAP information (one in the application and one in Websphere).
I have searched around but couldn't find anything concrete. The closest I saw was I can configure it as a federated user repository instead of standalone LDAP registry, after which I can retrieve some attribute values, but it does not explain if I am able to modify them.
Any help would be appreciated. Thanks!

If you will use federated repository, then you can use VMM API. It is quite complex comparing to JNDI or ldap related libraries, but should provide you with features you need.
Start by looking at this page - Developing with virtual member manager - and subpages, you will find some code examples there also.

What "register new user" solution for JASPIC JDBC realm authentication?

I've created my own JDBC realm (using WildFly 8.2) as described at paragraph 50.3 of the JavaEE 7 tutorial. My understanding is that JDBC realm authentication implies that user credentials are read and checked by the server, the application doesn't even know the coordinates for the auth-reserved DB.
For a "new user sign up", the only thing I can imagine is to implement a classic solution from the inside of my application: accessing auth DB, check if chosen username is already present, insert row in the table... but doesn't this violate the whole paradigm of "container managed authentication", and maybe insert security holes?
Is there some server-implemented mechanism that I ignore?

but doesn't this violates the whole paradigm of "container managed authentication", and maybe insert security holes?
Yes, more or less. The container managed security concept, where the application is totally unaware of the authentication mechanism and the identity store (location where the user data is actually stored) doesn't really take the use case into account where an application has its own user sign up/register functionality.
The idea seems to be more intended for integrating externally obtained applications (e.g. say a Sonar or JIRA instance) into an existing enterprise structure. There the users are created by an admin using a central system like LDAP, or in some situations even an admin UI of the application server.
Unfortunately many of your typical public web applications aren't of this variety. They are standalone apps (don't integrate with existing internal enterprise infrastructure) and they effectively manage their own users.
The classical concept is an ill fit there, and that's why the Java EE Security EG is currently exploring how to best address this.
You basically have three "solutions" in the mean time:
Just define your DB connection details twice, once at the server level, once at the app. It looks like you were indeed already doing this.
Use JASPIC, which is a container provided authentication API which has the option to let the application contain the auth module. It can use the exact same data source and possible JPA entity manager and such that the application is also using.
Do your security using an external security framework, e.g. DeltaSpike Security or Shiro, that's totally implemented in "user space".
From a Java EE perspective, none is really ideal. The first has the duplicate definition and indeed somewhat violates the principle, the second is by itself okay, but JASPIC is a tad low level, and the second is a rich solution but doesn't integrate well with existing Java EE security.

Java Security Architecture

I am using ActiveMQ to connect a number of application modules written in Java.
I eventually would have a web interface for the application, developed in either Grails, Struts2, or Rails.
My 2 main concerns are:
to have an external security module that is not bound to the Web Framework in use.
to have an independent security db
Any recommendations for this Architecture?

You should place all your components within a secured firewall. Then you wouldn't need to worry about any kind of security for ActiveMQ. If not a firewall, you should have a way to whitelist your components so only you can connect to them.
For the database, I recommend having one user that read data and one user that writes data. Separating this permissions will be a closer step to someone deleting you data.

You need to secure both parts of your application. For the first part go with Amir Raminfar's answer, and insure that your running on secure servers. Also make sure to use what ever security features are built into MQ to allow the components to communicate securely. For Web Security there is no good way I know of to have a framework agnostic security setup. An option for you may be Spring Security You should be able to integrate it with Struts and there is a Grails Plugin This should make it easier to do security in a relatively common way whether you use Struts or Grails but you will probably not be able to easily use Spring Security from Ruby.