Is there any java program or api to change the content of the configuration file of the haproxy? for example to append/remove few configuration dynamically.
Run a thalassa server on the same machine as HAProxy and call its http api from your Java program. It defines restful POST and DELETE interfaces for registrations, which are dynamically configured backends.
append documentation
remove documentation
Inspired by the Answer of allonhadaya I tried out thalassa.
Pearson Eduction who are the main contributes build a complete stack around:
https://github.com/PearsonEducation
So in your example you would probably use three of their components
Thalassa (Service Directory Service)
Thalassa Http Client
Thalassa Aqueduct
The Service Directory is the central service manager. With the application itself (if it is a node application there are predefined compontens) or with the Thalassa HTTP Client you register your service (application) at the service directory. In your case with your existing java application, using the HTTP standalone client might be a good way to start.
Thalassa Aqueduct ist the bridge to the HA-Proxy. It connects the Service Directory with the HA-Proxy configuration. At the moment it has (only) some REST Methods to also configure the HA-Proxy Frontends and Backends. But a quite OK Webinterface to see how many connections are handled and balanced right now.
Related
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.
I have 5 microsrvices:
acmeair-mainapp (main service)
acmeair-as
acmeair-bs
acmeair-cs
acmeair-fs
Which application should I include in SD or how can these applications be configured?
I have followed the Bluemix documentation but things are not transparent with how to follow the steps. The Bluemix docs says to add some code to register a new service and it gives sample code for nodeJS, Python, and cURL, yet my application is written in java. Please help me proceed.
By main service I assume that application is the one that needs to talk to the other 4.
Conceptually, what you will do in this case is have acmeair-as, acmeair-bs, acmeair-cs, acmeair-fs register with a unique name and url with service discovery.
acmeair-mainapp will then request the name of the microservice it needs to talk to and service discovery will return to you the URL of that microservice.
You can use this Java code I have as an example to register a Java microservice with service discovery (which is what your 4 microservice apps should do) It additionally does the "heartbeat" needed to keep your application alive in SD's eyes.
You can also view the Service Discovery API Docs. They provide Java samples for their requests there. These Docs can help you craft a request for your main application to use to get the URLs it needs from the other 4 microservices
I've got a question about hawt.io security.
I've installed hawt.io as a web application (currently its embedded jetty but we have an option to use tomcat in an embedded / regular mode as well).
Hawt.io visualizes the JMX mbeans tree of the same process, we don't connect to remote servers, everything is local.
What I would like to do is to find the best way to provide an authentication and authorization mechanism to be used:
User's authentication: should be done preferably via LDAP
User authorization: some users can gain full access to all mbeans, others are restricted to not execute mbean operations, but only read attributes.
I thought that I can install a web filter, in jetty I can do it outside the web.xml and check requests, but since hawt.io uses POST web method to communicate to its internal jolokia, the identifier of the operation execution is inside the body of the request, so I don't really have an access to it from within the web filter since in Java Servlets I can read the request body only once. I know I can provide a 'fake request', but maybe there exists a better solution.
Maybe someone can provide relevant configuration snippets for configuration of such an installation. Thanks a lot in advance
For role based authorization you can query up-front if the user has access to a given mbean/operation/attribute. If you implement this interface
you can probably integrate with some server-side authorization for JMX. By default hawtio uses a dummy implementation that lets everything through. This all was originally designed to work with the JMX guard stuff implemented for Apache Karaf which exposes the same mbean but actually does restrict access via ACL configuration. Anyways, the client-side javascript is set up to locate this mbean by scanning for "type=security;area=jmx", just set a higher 'rank' attribute in your mbean and the javascript will use it.
I am a little confused about the roles of a java application server and its differences from a web server.
I found many sites explaining the same difference between the two but not to my satisfaction.
So please explain me about the two following cases:-
1)App. Server and its difference with web server:
From these two links:
Difference between an application server and a servlet container?
What is the difference between application server and web server?
web server: It handles everything through http protocol by accepting requests from clients and sending
responses to them with the help of its servlet container(e.g Apache Tomcat)
App. Server: An application server supports the whole of JavaEE like JMS,JPA,RPC etc.
Now what I am confused with is that how can I use a lot of JavaEE APIs like JMS,JPA etc. with my Tomcat
by adding their jar files in my web application ?
Does that mean that if I use an appliation server I don't have to add those jar files?(I don't think so)
2)The roles of an appl. server (This is very important to me)
From Wikipedia
http://en.wikipedia.org/wiki/Application_Server
An application server provides services such as security,transaction support etc.
"The term is often used for web servers which support the JavaEE" -- It sounds like if we add the required jar files of JavaEE APIs a web server becomes an appl. server.What about it.
Now my question is how an application server performs the tasks of security control or transaction management by itself ?
E.g. in my web application using Spring framework I am providing security by using spring-security and transaction management by using #Transactional annotation and all those things you know.
So does the appl. server have anything to do with my security or transaction management or it has its own ways ?
Forgive my ignorance.
Using Spring, you're in fact embedding some kind of Java EE container inside your application. But even when using Spring, if you need JTA support (because you need distributed XA transactions), you'll need to use an additional transaction manager. If you need JMS, you'll need to install an additional JMS broker. If you need connection pooling, you'll need to use an additional connection pool. Sometimes it's as simple as adding additional jars to the classpath and properties or XML files. Sometimes it's harder.
A Java EE app server comes with everything bundled. You have less flexibility, but you don't need to install, configure and make everything work by yourself.
When you use the Java EE framework, that is a specification. So the application server, if it is Java EE compliant, needs to implement this. So once it is implemented the specification, then it will address Security,transaction etc because it is mentioned in the spec. So it is a contract. Whereas, in a web server, it will just pull out your static resource. There is no need for handling other stuff.
In case of the Spring framework, the framework knows how to handle transaction, security etc. So particularly the developer need not look into these aspects which are implemented by the Application Server in the other scenario.
how an application server performs the tasks of security control or transaction management by itself
It is rather the specification that address these issues, not the application server. So, the duty of the app server is to implement these.
So, if your application is Java EE compliant, then these areas will be addressed and the implementation would have been done by the app server.
May be this is oversimplification,
A web server is basically a HTTP server serving contents over http protocol. So a web server is simply about serving the contents over http protocol. A typical example would be Apache web server. This is simply a file server.
Now the question is where does the web server gets the contents from ? Possible sources are
Static contents (the contents like images/css etc) which are not generated on request but statically served.
Dynamic contents: Simply put, the contents to be served are generated upon the user request.
For the static contents, the web server does not need anything as it simply reads the file and serves it.
For dynamic contents, the web server might need help of additional components which will generate the contents to be served.
Here the Application Server comes into picture.
Now these additional components referred earlier, might interact with database or some other system etc.
In a web environment where your website is exposed to huge number of users (intended/unintended), you need typical services like transaction/security/concurrency etc. so that the user get expected responses and do not see inconsistencies in the behavior of the application.
An application server has inbuilt abilities to manage transaction/security/concurrency/resource management. generally these are referred as Managed services and environment offered by them is called Managed Environment where these basic services are managed by the application server and programmer does not have be bother for them.
Application Server needs web servers or we can say Web servers use Application server's services to generate dynamic contents.
For example, JBoss uses Tomcat as inbuilt web server. Whereas web logic has its own web server. Tomcat again can be called as application server (in principle) as it also offers managed environment for servlets (it manages concurrency and instance pool of servlets/JSPs ).
Coming your your example of Spring:
An Application server will come inbuilt with transaction/security etc whether you need it or not. The Spring offers a very nice way handling this. Spring has all these things BUT you use what you need. Not just these, but just a Java Web Sever like Tomcat is sufficient to build a full fledged services that needs an application server.
This question is kind of related to our web application and it is bugging me from last few months. So we use linux server for database, application and we have our custom built java web server. If we do any change in source code of application, we build a new jar file and replace the existing jar file with new jar file. Now update to take place in live application, we just execute a HTML file which contains this kind of code :
<frameset rows="100%"?
<frame src="http://mydomain.com:8001/RESTART">
</frameset>
How does this opening of port make the application to use new jar file?
The webserver is instructed to give the /RESTART URL special treatment. This can either be through a mapping to a deployed servlet, or through a hardcoded binding to a web container action.
It is very common to have URLs with special meaning (usually protected by a password) allowing for remote maintainance, but there is no common rule set. You can see snapshots of the Tomcat Administration console at http://linux-sxs.org/internet_serving/c516.html
EDIT: I noticed you mentioned a "custom built web server". If this web server does not provide servlets or JSP's - in other words conforms to the Servlet API - you may consider raising the flag about switching to a web server which do.
The Servlet API is a de-facto industry standard which allows you to cherry-pick from a wide array of web servers from the smallest for embedded devices to the largest enterprise servers spreading over multiple physical machines, without changing your code. This means that the hard work of making your application scale has been done by others. In addition they probably even made the web server as fast as possible, and if not, you can pick another where they did.
You're sending an HTTP GET to whatever's listening on that port (presumably your web server). The servlet spec supports pre- and post-request filters, so the server may have one set up to capture this particular request and handle it in a special fashion.