I currently have a very basic cluster composed of two Tomcat 6.0.32 instances (Tomcat1 and Tomcat2) running on the same VPS. I'm using mod_proxy_ajp and mod_proxy_balancer as the load balancer through Apache (on the same VPS).
We are using basic form authentication (via j_security_check) to create authenticated sessions for users.
The load balancer is working well and unauthenticated sessions are being replicated between the two instances successfully. However, I am unable to have authenticated sessions replace between each instance.
I am using a very basic JSP called session.jsp (based on the JPS template http://www.syslog.gr/articles-mainmenu-99/15-tomcat-cluster-session-replication.html) to test the session to see if it is a new session and print out the JSESSIONID. I have one copy of the JSP inside of the protected area and one copy outside of the protected area.
I've run the following tests:
Test 1)
I access session.jsp outside of the application's protected area on Tomcat1, I note down the JSESSIONID and confirm with the load balancer that Tomcat1 handled the request. I then shut down Tomcat1 and refresh the page. The request is now handled by Tomcat2 (as confirmed by the load balancer). When the page finishes loading I see my original JSESSIONID and my session has survived.
Test 2)
I access session.jsp inside of the applicaton's protected area on Tomcat1. This prompts me to log in. After logging in I am sent to session.jsp and note down my JSESSIONID and confirm with the load balancer than Tomcat1 handled the request. I then shut down Tomcat1 and refresh the page. The request is now handled by Tomcat2 (as confirmed by the load balancer). When the pages loads I check my cookie. I now have a new JSESSIONID and I am once again prompted to log in.
So far from this I've figured that authenticated sessions aren't being replicated like unauthenticated sessions. Is this a good reason for this or does it point to a configuration problem?
You have not running on sticky_session mode and it could be enabled with worker.loadbalancer.sticky_session=1
And bettter check : http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
Related
We develop an React application with an Express NodeJS backend and this application is secured by an authentication using IBM App ID. Everything works fine on the authentication mechanism if the application is deployed on a Cloud Foundry Service with only 1 instance running.
For performance and high availability reason we need to scale up the number of instances. Unfortunately, as soon as we add an instance, we face problems with authentication. We loop over the authentication screen several times before the authentication succeeds and we can access the application.
For information, we use a Cloudant database to store the session.
Have you ever encountered this problem and how did you solve it?
Thank you for your feedback.
Technically what you are doing is the right thing.
I've encountered these problems before and first thing is usually local session handling - either the default memory store or some file based session store. You should have this covered, as you say you have sessions in Cloudant, but sometimes when you want to enable local developers running the app, you may need to have some switches to control if the shared store is used, but also if http or https is used.
Why http vs https is important, you probably have 'cookie: { secure: true }' which needs to be flip/flopped in that case. Next you might want to http trace the login attempt to see that you don't accidently use another host name than what you begun with. This could easily happen if your CALLBACK url for App ID changes it. These might still not be your reason, and if it is so - then setup that 2 instance environment, save the logs from app servers, http trace from browser and inspect created sessions from Cloudant. There should be only one session created, one url for application used, same session cookie saved in browser. If any of that does not add up - then you need to figure out why not.
I am using an xPage as an iWidget in IBM Connections 3.0.1. I have extended the ajax proxy to point to the nsf. During testing everything was working correctly but I realized it was only working when I was already authenticated with the application (I do use SPENEGO to auth). When I load connections in a fresh browser session I get the BMWIW0001E:Unable to load iWidget error. But if I load the app then reload connections all is well.
Is there a way to pass through the user's credentials or otherwise prompt for a login?
Is there a way to hide the "BMWIW0001E:Unable to load iWidget " error and display a custom error page?
The error message is generated afaik by connections, so you might be better of asking on Server fault or the IBM Connections forum.
For authentication in a mixed environment you have to sort out the trust relationship between the servers. Pick your poison: LTPA, oAuth, not sure about spinego.
As a short term remedy you could use a landing xpage in your widget flagged for anonymous access (allow public access and in the ACL: anonymous with no access but read public access.
In that page you check #UserName and redirect to a mini login or the real widget page. Redirect can be also by loading a dynamic control
When a user hits login page of a Portal (it could be Liferay, Jboss Portal..), JSESSIONID cookieis created by the container. After entering credentials in the login page, same JSESSIONID gets carried over.
Here, end user will come to know the JSESSIONIDbefore he could get authenticated (by checking the JSESSIONID in the login page). This will increase vulnerability of the site for hacking because one can know the JSESSIONID before one gets authenticated.
This post advices to have a different JSESSIONID after authentication.
So, creating a new JSESSIOND can be achieved by Portal server being used (am using Liferay CE 6.0) or it has to be handled by web application developer? If it has to be handled by web application developer what is the best way to do? request.getSession(true) is the only option?? If I need to instruct Liferay to create a new JSESSIONID after authentication how it can be done?
This looks a lot like the session fixation problem I solved for Liferay 5.2.5 a long time ago. The solution consists of creating a custom Tomcat Valve that will force a new session ID. So the solution isn't really specific for Liferay and is dependent on if you use Tomcat or not.
I suspect it shouldn't be too difficult to adapt my old solution to a newer Liferay/Tomcat combination. You can find the necessary information about my solution in my old and currently unmaintained blog (if I only had more time...): Fixing session fixation in Liferay
The problem here is not that the user knows the session ID (the user always knows it, it is sent by his browser). The attack scenario is that the user, while logged out, clicks on the link that already has JSESSIONID embedded, then authenticates and this session becomes a logged-in session. Now someone who initially created the link can use the same session to act as the user. More details at https://en.wikipedia.org/wiki/Session_fixation
So yes, use the web or app server to re-set session ID after a user authenticates. You do not need to write it yourself. For Tomcat 7: http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
You can fix this issue by setting the following property to true like Liferay has as default.
#
# Set this to true to invalidate the session when a user logs into the
# portal. This helps prevents phishing. Set this to false if you need the
# guest user and the authenticated user to have the same session.
#
# Set this to false if the property "company.security.auth.requires.https"
# is set to true and you want to maintain the same credentials across HTTP
# and HTTPS sessions.
#
session.enable.phishing.protection=true
#Thiago:
This session.enable.phishing.protection=true is by default true in portal.properties. Anyhow, I have added this entry in portal-ext.properties. But, even then JSESSIONID remains same before and after login.
I have implemented a filter as per this link. After implementing this filter, when I hit login page of Liferay, one JSESSIONID gets created. After I enter the credentials and login, the same JSESSIONID is retained.
I have implemented this filter in a Servlet and not in any of my Portlets or in Liferay's ROOT application. My Servlet is deployed in LR + Jboss AS bundle. Am first hitting the Servlet and from here I have a link which will redirect to Liferay's login page. I have implemented this filter in my Servlet because Container will append JSESSIONID for first time request as it doesn't know if cookies are enabled or not. Since, JSESSIONID is getting appended, am not able to retrieve my images in Servlet (because url is myImage.jpg;jsessionid=). Hence, I have implemented this filter.
Is this filter conflicting with Liferay's configuration? Even after setting session.enable.phishing.protection=true same JSESSIONID is retained means what else could be the problem?
Put this code inside the portal-ext.properties.
It will fix the problem, each and every time logged in, new session id will be generated.
session.enable.phishing.protection=true
com.liferay.util.servlet.SessionParameters=true
I am making a web app that has a login page (Using Facelets with JSF 2.0) which checks credentials before redirecting to a isLoggedIn or error page. I have access to the server
that the app is deployed on and Tomcat is used as container. I would like to log ip addresses that clearly tries to perform brute force attacks. My idea for now is the following, but I am not sure how to get hold of the offending IP and even if I could it looks a bit clumsy, so what is a standard/good way of doing this? I would prefer not having to use
any other implementation of JSF.
During login write log messages (from Beans) using a logging framework to an app-specific
logfile in Tomcat's log folder where failed logins are saved with offending ip and time.
Create script that reads the log and checks if any ips have a high rate of failed
attempts. Add these ips to hosts.deny.
If you're using realm authentication check Tomcat's LockOutRealm. It does not write the host.deny file but it also could prevent brute-force attacks.
A Session is per browser (determined via cookies), but when does an "Application" start, and end, and how does IIS know know when a request is a part of the same same "Application" instance (if not done via cookies the same way that sessions are)?
"Application" scope is global, and every request to a website shares the same application. Anything stored in the application is visible to all users. The application starts when the first request to the website is made, and ends when IIS stops the website (for example, when IIS itself is shut down, or when the website hasn't been accessed in a while).
Application is said to be start when it is first deployed on the webserver and is available to the users for access. Each time it is un-deployed or the server is shut down the application ends.
The second part is not clear but assuming for determining the application, each application has a root which is unique for all the application that are deployed on a web /app server. So the server can figure that out from the URL being requested.
As such each request is considered as separate and some mechanism like sessions, cookies etc has to be used to club individual requests as a part of single user session.