I'm in charge of maintaining a web application (Lives on a Tomcat server) which has two different access points, through two Apache HTTPD servers which are outside of my reach.
The two access points are meant to log in user either through a third-party SSO system or a good ol' authentication page which prompts for login and password.
The trick is, this SSO puts a limit on the size of files which can be uploaded or downloaded. As SSO users will need to retrieve and send things heavier than that, I need a workaround for this, most likely simply offering a link pointing to the correct resource location through the other server.
What concerns me here is security, in case someone enters a cleverly guessed address to get a document he's not supposed to. The person in charge doesn't want to hear about a SessionManager to make sure the user has the rights to retrieve the documents, but suggested that I could simply use their JSESSSION_ID to confirm their identity...
I am not sure about how to implement this, and have a serious gut feeling that this will backfire in a quite horrible fashion.
Can anyone who had to deal with a similar problem points some of the pitfalls and possibly share a few useful tips on how to securely bypass this SSO ?
One possible way to implement this is to protect the resources on the non-restricted site with a one-time password with a very short life time.
Example:
User clicks on a link to open a document on the SSO protected site. The link should not provide the document directly.
The Tomcat server generates a one time password and redirects (using http code 303) the user to the un-restricted site with this password as an http parameter.
3. When the browser connects to the un-restricted site, check that the password is correct and provide the document. Delete the password so that it cannot be used again.
The password should only be valid for say 30 seconds. You may also record the user's ip-address and validate that.
You should not use the jsession id for this. It is not a good practise to expose the jsession id in a parameter on the address bar or in an html page.
However, you say that the other access point is protected by username and password. If so, will not the user have to log in here anyway? And if so, does not that login protect the resources?
If you provide a link pointing to the correct resource, we need to consider the security.
https://www.owasp.org/index.php/Top_10_2010-A2
The most important thing is XSS and CSRF and solutions are provided in the above website.
Session Hijacking can be another security threat if we provide a direct link which can directly access the resources.
Related
I wanted to get some more information on about form based authentication. I understand that the form based authentication mechanism is used when you want to protect certain server resources, like all jsps under a certain directory, and only make those URL's available to users with certain roles.
I am working on an application from scratch, just to get better at web development, and I have the form based authentication setup, and it is working fine. However, I would also like to build in the ability for users to login on the fly, using a 'Login' button, not just when they necessarily try to access a protected resource.
I know that when I tried to have the login button take the user to the login page that uses j_security_check as its action, the server yelled because I was directly accessing the login page, which makes sense because since I wasn't trying to access a protected resource, so I guess the server wouldn't know where to take me after I authenticate.
So, my question is, if I want to keep the form based authentication in place to protect some admin resources, but also have the ability for the user to just login on the fly using a login button, do I have to roll my own security, and have the form take me to a servlet(for example) that manually checks the username and password against the database, and set some attribute that says whether or not the user is logged in? How would that mesh with the server knowing whether or not I'm logged in? I know that there are some server side methods for getting the user, asking if they are in a certain role, etc, but isn't that all server managed, meaning I can't just say 'hey, I've authenticated the user myself, and this is who they are, it has to go through the form based authentication? I'm still learning web development. Thanks for the help.
The only way I can think of providing the behavior that you want is through a cookie that doesn't expire easy, which has its fair share of security concerns. It seems you want to have the ease of use that the "Login with Google", or "Login with Facebook" have. These tend to make heavy use of something called OAuth, and I don't think are applicable for your project.
Are you forced to login for a resource every single time you access it? You shouldn't be , as you seem to be using the servlet's form authenicator.
I want to implement a stay logged in or remember me in my jsp login page. I am using container based form authentication. I think I need to I have to store users' data such as userid and token - a status information to determine whether as user is logged or not, into the cookies.
Also I heard that we should not store users' password even it is encrypted.
If I store their password and userid, I can sigh them in automatically by submitting the data to servlet before I show the login page to users.
If I do not store their password, what method could I use to sign them in automatically?
I would suggest that you not create your own framework for this but rather use something like spring-security or Apache Shiro since the security of your application is pretty important and not something you generally want to build from scratch.
If this is purely for educational purposes, I would suggest looking at the code for the two mentioned applications to see how they handle it.
I have seen this implemented as a secure token in the cookie (with expiration date) whose value is also stored on the server for a set period of time and associated with a specific user account. When the user returns to the site with that cookie, the server will compare it's token value to that of the cookie and let them in if they match (and it is not expired).
Again, it is best to use pre-existing and tested libraries for this kind of work.
Best of luck.
RESOLVED. This question can be deleted by moderators
I have a very simple site written using Java EE (JSPs, Java, Tomcat server). I want to implement a simple login system. I thought I got the registration and login working; however, there is a huge problem with the way I'm doing it.
Let's say Alice logs in. She is able to view her profile with her information, everything looks normal so far for Alice.
Then Eve comes around and wants to log on. She does and is taken to her profile, everything looks normal for Eve.
Then Alice reloads her profile to find that the site now has her logged in as Eve!
So to reiterate: after one person is logged in, anyone is able to go to the site and be logged on to that account. And the most recent person to log on is the active account.
How do you keep track of session information like this so that multiple different accounts can be logged on using the site at the same time?
Thanks!
EDIT:
This ended up being a very simple fix.. I just need to use setAttribute("EMAIL", userId); rather than the stupid way I did it which was just using a global String variable
Rather than try to roll your own security, use an existing framework, like Spring Security. Out of the box, it gives you basic login capabilities and handles securing pages using a role-based authentication scheme.
Reading your problem, I think that you store the last logged user's credentials in an instance variable of one of your servlets. This causes the last person to log in to overwrite everyone's credentials...
If you want a simple authentication, you can use Java EE's provided system :
http://docs.oracle.com/javaee/5/tutorial/doc/bncbx.html
Once a user logs in, put his own credentials in his Http session (request.getSession().put(username, )). Then, everyone will have a distinct profile.
I'm building an app to let users export data from a university system. Currently, they can log in and see the data in HTML, but I would like to let people download it as CSV.
I have an app where users supply their username and password. I would like to log in to the university system and HTML scrape the resulting page. How can I do this?
I'm building a GWT app. I could either do this in Java-transliterated-JS on the client, or Java on the server.
Update: Selenium might be nice, but it looks like overkill.
You're going to have to do this from the server unless the domains are the same. You'd need to determine what the POST transaction used by the other server for the login step looks like - parameter names etc. Then you'd perform that operation and do whatever you want with what comes back. If you need to see multiple pages, you need to maintain the appropriate session cookie too so that the server knows you're still logged in on the subsequent HTTP requests.
If you have to hit another site to validate the credentials, then I'm not so sure that people should feel comfortable providing those credentials to you. That is, if you don't have rights to check the credentials directly, why are you trustworthy to receive them? I know sometimes people need to integrate with a system they don't own, so this is just a question.
First, this has to be done server-side because of the limitations on client scripting due to the same origin policy.
The typical way of handling the "screen scraping" you mention is to treat the web page as if it was an XML service. First, examine the source code of the page, then using an internet/HTTP stack, craft a POST to the correct URL and read the response using a standard XML library. It will take some ingenuity to come up with a good way to dig into the XML to find the piece you need that will be as insulated as possible from changes to the page. Keep in mind that your system can break any time that the owners of the site change their page.
Sometimes, you can't just send the POST but have to request the blank page initially in order to get hidden form values that need to be returned in the POST. You'll have to experiment to find out what it requires.
Additionally, you probably have to handle cookies as well, since they usually are an integral part of the web site's authentication and session management (though you might get lucky that the session doesn't matter between the initial POST and the first response).
Last, you may be unlucky enough that the site uses javascript to do part of the authentication work, which may require additional digging to understand how the credentials are posted to the site.
There are other potential barriers such as the site checking to see that the referrer is their own site, possible use of SSL (HTTPS) and so on.
I'm pretty sure that the protection against cross-site scripting in web browsers will mean that you can't log in to the university's app using javascript running in the web browser. So the part of your program that fetches data from the university will need to run on your server. Once you have the data, you can process it either on your server or in javascript in the browser, but I think it would be easier to do it on the server.
See http://en.wikipedia.org/wiki/Same_origin_policy
I'm not too sure about GWT, but in general, you would take the form data submitted by the user, check it against a database of username and hashed passwords. If the database checks out, set a session cookie that says the user is logged in.
In your pages, check if the session cookie say the user is logged in. If not, redirect to login page, otherwise allow them to view the pagfe.
This question is more towards Design and Architecture and I want to know SO Readers think on my scenario.
I have a requirement where in my Application should provide other application interface when the user logs in to my application.
For example, lets say my application is www.gmail.com and other application is www.stackoverflow.com so what am trying to accomplish is that when the user log's in gmail account he should see his home page of stackoverflow and a particular questions.
From technology point of view, we have to use Java and so am not sure of what design and architecture consideration would go in to implement the requirement.
One Approach, am thinking on is that when the user logs in to gmail than I will populate the request object with all the login credential parameters for stackoverflow website and also question_id which would be passed in as parameter and then on Stackoverflow side, I would parse the request object and authenticate the user credentials and depending upon request parameter, I would render the question_id which I received from request.
I want to know what would be best approach and issues encountered in designing such an system.
Edit
After seeing all the answer, I would like to add little update to my question. What I am looking for is to get the feel of issues and challenges what I would have to face while trying to accomplish my task, also I am using Java and am not sure how can I accomplish my goal using Java as we do not have something like OLE which we have in Microsoft Technology stack to achieve the task.
Hope I am making some sense here.
I can think of three ways you could solve this.
Implement single sing-on. You log-in to all enterprise applications, and once logged all of them use the same authentication credentials (I think this is the best option. you don't need a full-fledge SSO, at least for these two application you could use the same credential validation mechanism)
You could also do what your are proposing creating the authentication credential for the user (i.e a cookie) and then do a redirect. Keep in mind that both application will need to be in the same sub-domain in order to work.
As mentioned before, you could also expose through your application the data/services you want to consume from the other application.
In my company we have what we call "Graphical Services", which are managed by a central server which also do credential validation, if the credentials are right it display a user interface for the user (generally in a Pop-up or an iframe).
Hope it helps.
You can't definitely do that at client side or java script as it will lead to cross site scripting issues. Or you can use iframes (which isdeprecated).
The other way of doing it would be to have your own interface/UI for the application and use only the service layer from your back end (java/j2ee in your case) which you may end up duplicating all the front end again (on the positive side, you will get your own branding of the site).
Regarding credentialing all most all the sites now used "OAuth" or similar and it should not be that difficult for authorizing
If both applications are web-based in-house applications, you could write a master login component, independent of either application, that will perform the user authentication, load any useful data it can at login time, and send the user's browser to the correct URL, making sure to pass any relevant information to the target app (as part of the forwarding request or behind the scenes in some distributed shared memory). Just a thought.