• Post Reply Bookmark Topic Watch Topic
  • New Topic

JASPIC custom ServerAuthModule (loginModule), where to hash the password?  RSS feed

 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm trying to implement a loginmodule so I can perform a "remember me" feature on my web app as well as hash my password with bcrypt. To build the class I used this tutorial: http://blog.c2b2.co.uk/2015/01/using-jaspic-to-secure-web-application.html. However I didn't manage to connect after implementing this. The passwords in db are hashed via SHA-256 at the moment and I suspect it is the reason why.


and I login like this (which did work before implementing a custom loginmodule):


Also on my pages I used to have a register and a sign in button that were displayed only if the user was null if not I had the username at the top. Now that I implemented this it's like the user is connected as "ANONYMOUS" (so there is "you are connected as ANONYMOUS" at the top of the page. To prevent this I did a temporary fix:


I tried :

isUserInGroup("ANONYMOUS");
but there is no user so I'm getting a npe. I'm not sure how to go about this as well.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmmm. This is new to me and I need to investigate it. Especially I need to investigate whether or not this particular mechanism is actually appropriate for webapps. Just because it's in a web article doesn't always mean it's purest gold - I read one the other day that was very useful but the author was completely unaware that in JSF your backing beans are NOT Controllers. So things can be wrong in minor or major details.

One thing you should pay attention to when attempting to make sense of this or any other article is that security consists of 2 distinct components: Authentication and Authorization.

Authentication handles login. The J2EE/JEE specs include the definition of a Container-managed Security architecture where the application contains no login code but merely defines the login method (BASIC or FORM-based or whatever) and - if applicable - the template login and login-fail forms.

Under this scheme, if someone makes a request to a secured URL (as defined by the URL-to-role mappings in web.xml), then the container (server) checks to see if the user is logged in, and if not, parks the request, runs the user through the login process and then - assuming login succeeded - resumes the original request as if nothing had happened. Note that this check is based on URLs and JSF URLs sometimes lag their resources, so there's a trick to resolving that that I won't go into here.

If you'll notice, the container is in total control of this type of authentication and authorization. If the user fails to pass the server's login process, the request never makes it to the application, so the application is defended against possible exploits by virtue of being completely isolated from the attacker.

In parallel with this container Authentication process is the container Authorization process. When a user is authenticated, the incoming URL's role mappings are checked and IF and ONLY IF the user is assigned one or more of the roles allowed for that URL, then the user is granted access. Otherwise the container rejects the request (403 - Forbidden) and again, the attacker has no direct connection to the webapp. Although web.xml can define a custom 403 page.

What you are attempting is security above and beyond - if not independent of - the container mechanism and I am not sure that that particular mechanism is integrated into the basic container security mechanism or not. If it is, the password is never passed to application code and it is the responsibility of the container security module (Realm) to deal with it. If not, then things are less clear.

So I guess I've got something I can read up on in my spare time.
 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Hmmm. This is new to me and I need to investigate it. Especially I need to investigate whether or not this particular mechanism is actually appropriate for webapps. Just because it's in a web article doesn't always mean it's purest gold - I read one the other day that was very useful but the author was completely unaware that in JSF your backing beans are NOT Controllers. So things can be wrong in minor or major details.


Well it integrates well with java ee or so I read.

Tim Holloway wrote:
One thing you should pay attention to when attempting to make sense of this or any other article is that security consists of 2 distinct components: Authentication and Authorization.
...


Yeah I used the container security before so I'm familiar with those. However I'm kinda perplex because a remember me feature is almost standard, I mean it's seen on a lot of websites. And I've read in articles that bcrypt was the hashing function that was advised in most cases. As far as I know those 2 things are impossible to implement in the original container security. Thus I thought more people would use JASPIC and there would be more resources out there. I know there are frameworks like spring security but that's just too much of an hassle to make it work with jsf. At least for the newbie me.

I'm gonna spend more time with this tomorrow I didn't have time today and I think I've an idea what to do.

EDIT : I understand why I didn't find lots of resource. It's because it's possible to do it without jasypt. However I'm using glassfish 4.1 and I think it's impossible without with this version.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If your definition of "remember me" is what I think it is, that's usually done by setting a cookie with the user's ID in it. That's what the JavaRanch does. It doesn't require any complex new-fangled security subsystem, since cookies work everywhere that they aren't disabled by the client.

It's really about the only reliable way. You cannot remember the user's source IP address, since on a dynamically-addressed system, that can change at unpredictable times. And if NAT is in effect, an entire office full of users can end up coming from the same IP address. There's no other uniqueness identified that can be transmitted automatically and freely over the Internet.
 
Cedric Bosch
Ranch Hand
Posts: 99
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:If your definition of "remember me" is what I think it is, that's usually done by setting a cookie with the user's ID in it. That's what the JavaRanch does. It doesn't require any complex new-fangled security subsystem, since cookies work everywhere that they aren't disabled by the client.

It's really about the only reliable way. You cannot remember the user's source IP address, since on a dynamically-addressed system, that can change at unpredictable times. And if NAT is in effect, an entire office full of users can end up coming from the same IP address. There's no other uniqueness identified that can be transmitted automatically and freely over the Internet.


It is indeed what I wanna do. The problem is, I believe, with glassfish 4.1 it's impossible to do. To login I use request.login(username,password) and glassfish has a Digest algorithm that cannot ( at least from what I've tried ) be none in 4.1. Thus I can't go in the database and take the hashed passwords because it's gonna use a digest algorithm no matter what. If that makes sens.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
J2EE Realms aren't supposed to READ passwords in any event. That's an unnecessary security exposure. The preferred action would be the equivalent of "SELECT COUNT(*) FROM USER WHERE USER_ID=? AND PASSWORD=?". Or, in your case, "SELECT COUNT(*) FROM USER WHERE USER_ID=? AND ENCRYPT(PASSWORD)=?". In either event, returning a 1 means LOGIN OK, returning 0 means LOGIN FAILS (invalid userid/password). For a MySQL database, the "ENCRYPT" function most likely to be used is named (originally enough) "PASSWORD".

Which isn't so hard if you can easily create a custom Realm. I can do it almost trivially with Tomcat subclassed off its JDBC Realm. I'm not sure how easy it is to do with the current Glassfish. A recent exercise with WildFly makes me suspect that the former JBoss security system has gotten a little too specialized to make it easy on that platform.

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!