We have already created 2 JAVA web applications A & B and hosted it on 2 different
servers using TOMCAT on both these servers. These applications have already been moved
to production and we cannot make any major changes or move it to a single server as it is not in our control.
The authentication is being done through a common LDAP server which is being used by many other applications also.
Now, the client wants us to create a new application C and once logged in, the end users should be able to access the above 2 Applications A & B(through links) without having to
re-login again(SSO).
Pls advise on how to implement the same.
CAS seems the right solution for this but I don't see how you could do to avoid touching anything.
You will at least have to touch some config files.
Look at:
- Spring Security and CAS Integration
Regards
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 4 web applications added (deployed) to the apache tomcat 7 server. The server will host only these applications at any point in time i.e. tomcat is used only to host these 4 applications. And we're not deploying anything in the ROOT.
Now, I'm facing issues with Session Management.
Problem is that I'm getting different sessions for each of the application (which, if I'm correct, is because each application has a different container).
I can think of two possible approaches:
Session remains consistent across all applications. Therefore, it'll
be easy to handle session.
I listen to the web server for application change (change of
context/container, I presume) and then create, validate or
invalidate session.
Here I have two questions corresponding to both the approaches.
Is it possible to have same session across all applications
(containers)?
Is it possible to listen to apache for change of application
(container)?
If answer is YES to any of the questions above, please guide on how I can do it? And if both approaches are not possible, please suggest a better approach?
Present Approach: I'm invalidating the session before switching to another application and after the switch is made, I'll create a new session for the corresponding application. Here, all will work as expected if the user browses through UI but problem persists if the user is in one application and then directly try to access another application through URL (web address).
Please let me know if you need any additional information.
Thanks in advance.
Application containers and contexts are very much isolated, however there is opportunity to do cross context communication. See here and here.
Alternately, you can do your own custom session management using custom headers and interceptors
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.
i have a two web applications running in java wih weblogic server, both the applications have same user name and password, so i decided to use single sign on machanism for sharing the session.
Apart from openSSO configuration, policy agent installation, i have to write java code for redirect the particular page from one application to another application.
if anyone already implemented the single sign on with java, please send me java the part to control the user authentication.
If OpenSSO is setup properly for both the weblogic instances, you can just redirect from one application to the other, you don't have to do anything else.
I have a Java web application designed to be deployed on the internet. It needs a database connection. Depending upon hosting environments it may not be possible for the deployers of the web application to configure appropriate data sources so the application needs to store it's database connection information somewhere to be reloaded if the application is restarted.
I also need to give one user administrator privilileges. If this is just the first user account created there is the small possibility that the admin account could be hijacked in between the time that the application is deployed and the time that the installer logs in.
I need to do both of these tasks securely and in a way that is lowest common denominator for a web application.
Clarification: Upon first use I want the application to set up an admin user. That admin user will have all security access in the system. Somehow I need to determine what that user is called and what their password will be. If the application gets deployed on a shared web host the application will be live from the moment it is deployed. If I allow the site to be configured through a web interface there is the small possibility that an unauthorised person will do the web configuration before the site owner effectively hijacking the site. I am looking for an elegant way to avoid this.
Ok, to answer your revised question...
There isn't really that much you can do. If you don't want the admin to configure their account during installation on the server, then there will always be a small window where someone else might create it via the web before they do.
All the solutions involve modifying something on the server (as this is how they prove they are the real admin). Yes, that can mean a config file...
Upon first connect, give the user a
token. Basically a hash of some
salt+theirIP+theirUserAgent, etc.
Then ask them to log into the server
and feed this token to your app,
probably in a config file. If the
generated token next time matches the
one in the config, allow them to
proceed.
A simpler solution is to let them put
their IP address in the config from
the start, and just allow this IP. (Assumes they know what their IP address is)
Alternatively, allow account
creation, but refuse to do anything
else until some file is removed from
the server. Many PHP apps do this
with an install.php, but the file
could be anything you test for.
The most common way to do this is through a static configuration file, in some simple text format.
The file resides on the same system as the application, and should be just as secure as the code (eg. if someone has access to modify the configuration who shouldn't be able to, couldn't they just as easily modify the code?)
For one of our Java web apps, we're using Spring dependency injection to configure most of the app. If you create a "Configuration" class with all of the configurable properties exposed, you can wire up a bean in Java that is configured via Spring XML context file. You can then create different versions of the XML file for your different environments, and have them automatically built into specific packages, which can be deployed all-at-once. If you want to go all-out, you can basically configure every single class in your application using Spring, which is really useful.
There's a little bit of overhead to get Spring setup, but it's actually not too hard, there are plenty of tutorials out there.