File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Struts 2 and Authentication Interceptor - is this secure?

 
Annie Jones
Greenhorn
Posts: 10
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I currently have an application that uses a custom interceptor to check whether a User object is in the Session. If the object exists then I assume the user has been previously authenticated. The way that the User object is first put into the Session is from a Login Action (once the username and password are determined to be a valid login in the DB).

This User object contains:

int userId;
String username;
String password;

I'm concerned that storing this User object in the Session is not secure.

Additionally, I am concerned that my interceptor does not re-validate the credentials every time a request to a secure part of the site is made - all it does is check that a User object exists in the Session.

Is there a better or more standard/secure approach to this problem? I'd really like someone with some good experience to help me out here.

Thanks!
Annie
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Technically these aren't Struts questions, they're generic regarding security.

Users don't have direct access to session objects (unless you give them access to them, anyway, but that would be unusual). Unless someone has access to the server and can access session memory somehow, it's secure enough.

By re-validating the credentials do you mean checking against the DB to see if the password is still correct? Unless someone on the server-side changes the password in the DB without changing the password of the user object in session, this is (essentially) impossible.

It is, however, possibly reasonable to check if that user is still allowed access to the system--for example, if an employee quits some employers will *immediately* lock them out of the system to prevent them from accessing now-sensitive data. If your application has that kind of requirement then it *might* be reasonable to continuously check for access rights.
 
Annie Jones
Greenhorn
Posts: 10
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I meant re-validating against the database each time a secure part of the site is accessed.

Thanks so much for your response - really clear and well explained, thanks a lot!
 
Annie Jones
Greenhorn
Posts: 10
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, one other thing - might it be better to store a simple Integer object (representing the user ID) in the Session saying that the user is authenticated - rather than storing the entire User object with the username and password.

This would save some memory, especially if the username and password are not required after the initial login.

What do you think?
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the savings would amount to < 1k per session object, which hardly seems an issue. It doesn't really matter, though, if you truly never need any information from the user object.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic