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.
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'm looking at exposing separate services inside an application server, and all services need to authenticate with the same API key.
Rather than each request authenticating with the DB individually, I was hoping I could write the authentication service and configuration once, do some caching of the available API keys, and expose that auth service to the other services on the app server (TC, Glassfish, etc). I don't think HTTP loopback is a good choice, so I was looking at Spring Integration, JavaEE, RMI, etc.
There's lots of info available, but it's still not clear to me if this is something that Spring Integration can support after reading through some documentation and projects. It looks like Spring makes the assumption you're in-app, or MQ based (external MQ or embedded MQ.) I'm also not sure if this is something inherently available in EJB implementations with Jboss or Glassfish...It seems like it might be though.
While MQ's seem possible, they seem like overkill for what my purpose is. I really just need to pass a bean to my authentication service on the same box, and respond with a bean/boolean on whether the key was approved or not.
Anyone have some guidance on accomplishing something like this? (or maybe why I'm making the wrong decision?)
You can do it via plain PCT/IP or RMI.
But I don't see problem to follow with Micro Service Architecture principles and use the Spring Integration REST ability
Any networks access you always can restrict via firewalls and HTTP-proxies.
I have a very simple question for which I have not found an answer in SO or elsewhere (namely, the hundreds of pages of JBoss security documentation):
I want to implement a login function (specifically, database logging), at the point when authentication happens through JAAS, without the client having to make a separate REST call.
I'm not an expert, but my understanding is that the authentication happens through a database query off in the JBoss XML, without calling the server directly. Since JBoss is doing this and connecting the authentication with the server war, I'm hoping that there is a hook available to have it kick off a REST call, or call the Java code through another mechanism.
Couldn't find a duplicate but please point me to it if it answers this exact question.
Thanks
My experience is with webapps and not with client apps so I do not fully understand your question, but it is clear you are suffering a serious missunderstanding.
want to implement a login function (specifically, database logging), at the point when authentication happens through JAAS.
To do that you just need to implement a LoginModule class and register it with JBoss.
Let's make this clear. JAAS is executed at the server, as part of a resouce security policy. When a resource needs authenticated access, the JBoss servlet executes the security policy related to it. The security policy includes
a) how the container (the JBoss server) requests the authentication data. But that part is not specified by JAAS. JAAS only specifies how the container passes that data back to the login module.
b) the login module that the container runs to check that the authentication data is correct, and to fill/provide the principal that will be passed to the application in the server. The login module makes its checks as it wants (let it be SQL query, or LDAP queries, or calling a WS, or...).
The without the client having to make a separate REST call. has no relationship with JAAS. It may be that the policy requires to setup a cookie for authentication. I am pretty sure (again, I am used to webapps) that if you use Basic HTTP authentication you do not need extra calls. Then again JAAS is only related with checking the user/password and providing/filling the principal. How the data is obtained by the container (JBoss server) is not related to JAAS.
I'm not an expert, but my understanding is that the authentication happens through a database query off in the JBoss XML, without calling the server directly. Since JBoss is doing this and connecting the
The "JBoss XML" does nothing, it is just a description of the security policies. When you deploy an app, its descriptor tells which resources are to be protected by which security policies. Do not confuse the terms. Which performs the SQL query (or LDAP query, or webservice call, etc..) is the container (the "JBoss server") through the login module.
From the rest of your question, I cannot understand what are you trying to do. Do you want the JAAS module to call your webapp code directly?
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.
We are looking at building an application that either proxies a standalone LDAP server or delegates to an embedded Java LDAP instance (ie: ApacheDS, OpenDS) in order to log requests and determine who is accessing which applications on our very large corporate network.
My question is is there a good way to intercept an LDAP request and "pull it apart" or have either OpenDS/ApacheDS push notifications of requests coming into LDAP.
You don't need to do any of that. You can configure LDAP servers to log accesses, either in the LDAP directory itself or elsewhere.
OpenDJ (the actively developed fork of OpenDS, http://opendj.forgerock.org) has support for multiple and customized access logs, so you can even configure some filters for the specific requests you're interested in.