We have a Tomcat server for a web shop, and we need to transfer the user to another (secure) server when he/she logs in. Here's a detailed explanation:
1) We have two Tomcat servers: one 'regular' (HTTP) and one secure (HTTPS)
2) Users initially visit the regular server
3) When they log in, we need to get their log in data, as well as the information about what page they were currently on (or were trying to see), pass it to the secure server and do the actual login; for instance, a non-logged in user sees a list of products, clicks 'BUY' and a popup is displayed, asking the user to log in; the user enters his/hers credentials and these, as well as the information about what product he wants to buy, are passed to the secure server; the secure server receives these, performs the login and displays the requested product to the user
How could this be done? Please note the following:
1) We've tried doing it with cookies, but we've decided not to go that way
2) Persisting the session to a database and then having the secure server fetch it is also not an option
Are there any other ways? We were thinking about creating an object and then passing it as a HTTP POST parameter, but I'm not sure how this could be done (I've been given the task to finish it).
For what it's worth, the technologies we use are Tomcat server, Wicket, Spring, iBatis and MySQL.
Thanks in advance :)
If you want to share the session between different Tomcat instances, you could configure them to work as a cluster with session replication: http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html
Then, you could configure an Apache HTTP Server to work as a load balancer, making sure that HTTP requests go to server 1 and HTTPS requests go to server 2.
But, you could also have only one Tomcat instance (or N identical instances) configured to handle both HTTP and HTTPS, and ensure the secure access with standard (...<transport-guarantee>CONFIDENTIAL</transport-guarantee>... in web.xml) or framework-specific configuration.
Not sure if I'm getting the gist of what you want but you could have the "pop-up" be a page served from the secure application to a protected URL. That would cause the authentication to occur at the secure server and you could go from there. For example, if the unsecured product page is on www.domain.com/browse/id1, then the "buy" button would open a pop-up to secure.domain.com/buy/id1, causing the authentication while transmitting the product id on the URL.
Related
One of our Spring MVC web application is deployed on multiple web servers with tomcat 7 and LB is at front to balance and distribute the requests to appropriate tomcat server.
Problem with this web farming is each tomcat server is able to store and retrieve its own HTTP session, but LB can send requests to any one of web server. So if a user is served for login page through tomcatServer1 then it's HTTP session will be created on it's respected server and it may happen that for second request of dashboard page LB sends it to tomcatServer2 where HTTP session is not available, resulting user is again redirected to login page.
To overcome this,
we are using "Sticky Session" property on LB, so that if a user (HTTP session + user's public IP) is first time served from tomcatServer1 then it will get bound to that server. Setting "Sticky Session" is not helpful as it's not utilizing all servers equally.
Another way is, develop our own session state server and deploy on a server then all server should communicate to that server for storing and retrieving session object/data.
Providing custom SessionManager to Servlet Container.
About #2, If in case we able to develop state server then also I have to modify the code to related to HttpSession.setAttribute() and HttpSession.getAttribute(). So question is, is it possible to override implementation of HttpSession for methods setAttribute & getAttribute? Also About #3, I don't know whether this solution will provide distributed state session server?
I developed session state server for tomcat using python.
Due to this I don't need to change the code already written for creating/accessing and destroying session. Also as there is separate server/service which is handling and storing session so not master cluster is needed.
One of our Spring MVC web application is deployed on multiple web servers with tomcat 7 and LB is at front to balance and distribute the requests to appropriate tomcat server.
Problem with this web farming is each tomcat server is able to store and retrieve its own HTTP session, but LB can send requests to any one of web server. So if a user is served for login page through tomcatServer1 then it's HTTP session will be created on it's respected server and it may happen that for second request of dashboard page LB sends it to tomcatServer2 where HTTP session is not available, resulting user is again redirected to login page.
To overcome this,
we are using "Sticky Session" property on LB, so that if a user (HTTP session + user's public IP) is first time served from tomcatServer1 then it will get bound to that server. Setting "Sticky Session" is not helpful as it's not utilizing all servers equally.
Another way is, develop our own session state server and deploy on a server then all server should communicate to that server for storing and retrieving session object/data.
Providing custom SessionManager to Servlet Container.
About #2, If in case we able to develop state server then also I have to modify the code to related to HttpSession.setAttribute() and HttpSession.getAttribute(). So question is, is it possible to override implementation of HttpSession for methods setAttribute & getAttribute? Also About #3, I don't know whether this solution will provide distributed state session server?
I developed session state server for tomcat using python.
Due to this I don't need to change the code already written for creating/accessing and destroying session. Also as there is separate server/service which is handling and storing session so not master cluster is needed.
Say I have logged into amazon.com. there are say 5 servers present to handle the traffic. Every request from my end hits say Amazon's server 1. Now there are many users coming to picture and my every request can go to server 2 or server 3. How do you make sure that servers two and three communicate communicate with one for my login details??
Which would be the best way to handle it in Java?
I would suggest the following:
Go for a Standalone Authentication and Authorization server.
Any incoming request should first be validated by Authentication
server and then processed.
Authentication and authorization mechanism will probably be Token
Based using OAUth.
To keep things like user preferences etc which expire with the
session, you will probably need a seperate In-memory DB server.
I am new to web app development.
Basically, I have got a GWT based web app. A user first needs to login. After successfully authenticated himself, he will be taken to the second page (actually another GWT view in the same page).
The login will generate a pair of keys from another web service. These key will be used for future communication with the web service, it is like:
client -> server => web service
Now the problem comes, I cannot save the key pair in a database. What shall I do?
I have been told I can put the key in a cookie and send back to the client. Every time the client raise request the cookie will be sent to the server.
I have also been told to set the keys as the session key and send them to the client.
I am note quite sure what is the different between these two methods. Are they applicable? or secure?
Many thanks
Both methods are applicable. The first one (using cookies) will rely on the user side (its cache). Second one, will keep data on server side (session). As a rule (although it's arguable), you never trust the client. What if client made a clear cache to his browser.
Even for security (I am not an expert here), I think storing data on server is always safer.
You can use both cookie as well as session or a combination of both to achieve this. Cookie are usually created when you launch your application (Also you can create it as and when required). The disadvantage of this is, it is temporary. As soon as you clear the cache or cookies, whatever cookie you created will be removed. If you store it on server side i.e., in session you must make sure to create a separate key value pair for each set of user, as many users can connect to the same server. The best approach will be using both the option together. I.e., to save a cookie and validate the session id.
This link will help you understand how create a cookie and session.
I’m developing a system to process financial transactions received by client merchants systems & it is a replacement of existing system which we have purchased from a vendor. Client interface should invoke the user authentication & transaction processing screens from our system.
System functionality as follows,
Receive input parameters from the merchant’s site
Validate it
Authenticate users (users are registered with our system & we should invoke our login screen)
Process transaction
Return status response to merchant
One the response is received client should validate the transaction data from the values reside in the session.
System overview can be depicted as follows,
(click here for full size image)
My problem is client could not retain the session once we are responding to the client. But the same functionality could be achieved by the system that we have purchased from the vendor (we don’t have source code of this to analyse the internal coding structure). I hope something wrong with the way that we are responding to the client.
How can I overcome this problem?
We are using Java 1.4.2, Websphere application server
There are many things which can make a session disappear. I'd suggest to track them and verify if anything went right. This is easier to do if you understand how sessions work.
Session has been timed out. This usually defaults to 30 minutes. This is confiugureable by <session-timeout> in web.xml where you can specify the timeout in minutes. You can implement a HttpSessionListener to track session creation and destroy using a logger.
Session has forcibly been invalidated. This happens when the code calls HttpSession#invalidate(). This is trackable with a HttpSessionListener as well.
Session cookie has been disappeared. Sessions are backed by cookies. If a session is been created, the server will add a Set-Cookie header with session ID. The client should send the same cookie back as Cookie header in all subsequent requests on the (context) path as specified in the Set-Cookie header. This is trackable in the HTTP traffic monitor ("Network" tab) of browser's builtin web developer toolset (press F12 in Chrome/Firefox23+/IE9+). Cookies are accessible for all webapps on the same cookie domain. Also, if ServletC2 runs on a different webapp context than ServletC1, then it won't use the same session. Further, if the "server" webapplication runs on the same domain, then it's in theory able to wipe out all cookies of the "client" webapplication.
The client doesn't support cookies. A well designed webapplication uses URL rewriting with jsessionid to track cookieless clients between requests on the same webapplication. But the second webapplication has to do the same when redirecting back to the first webapplication.