[ale] Re: [ajug-members]: User authentication in web app

[Chris Fowler]

So what you are saying is that the security container will check the
user database for each access.  The select statement was just an
example.  I would not have used it without checking username first.


On Tue, 2004-03-16 at 08:58, Rob Kischuk wrote:
> I would recommend using J2EE Container Managed Security.  While there 
> are certain circumstances where it is inadequate, it is usually useful 
> to at least authenticate your users.  Most J2EE app servers are moving 
> toward using JAAS to fulfill the authentication needs, meaning you can 
> flexibly switch between using a flat file for your username/password to 
> a database to LDAP without ever rewriting your code.  Parameters can 
> usually be set to add encryption to your passwords.  This security 
> approach also lets you switch authentication methods easily - from 
> dialog boes to web based forms.  A very light overview can be found 
> here: 
> http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security4.html#67530. If 
> someone has a link to a better resource, it would be excellent. 
> 
> The security is declarative, meaning that you tell the servlet container 
> which pages should be secure, and what "roles" should have access to 
> them.  In your case, it sounds like you have really only one role that 
> you want to enforce, so you could simply configure your entire web app 
> to be restricted to users in the role "user".  Then, in your security 
> database, just make sure each user is assigned this role (the structure 
> of the database will vary based on your needs and app server 
> requirements.  For some app servers, you could probably configure the 
> role query as "select 'user' from dual" and dispense with the need for a 
> roles table in your DB altogether.
> 
> The really nice thing here is that you don't have to check for the 
> user's session - the app server will observe the resource the user us 
> trying to access and notice whether it is secured.  If it is, it will 
> check their session to se if they're authorized to access it.  If not, 
> it will send them to the log in page (if they're logged in and don't 
> have access, you'll get an HTTP 403 error - if you get into significant 
> role management, I recommend you override the 403 error page with a 
> custom page that matches your app's look and feel).
> 
> As for your existing method of authentication, it is dangerous.  "select 
> * from users where PASSWORD like PASSWORD('value');" will allow anyone 
> access so long as they specify a correct password.  If the username is 
> wrong, or even non-existent, a user could still gain access, because 
> that query only checks to see if a matching password exists.  You need 
> to also match the username.  In J2EE, the best way to check each request 
> for a certain token would be to use a servlet filter.  A filter can be 
> configured to execute on all requests, or only on requests matching a 
> certain pattern. Still, both of these concerns are managed by J2EE 
> security, and have been carefully written and tested, so I suggest 
> building on top of that.
> 
> -Rob
> 
> Chris Fowler wrote:
> 
> >I'm trying to determine the best way to do user auth in a web
> >application.  I've not done this yet inside of servlets.  I've done it
> >within our CGI programs that were all written in C.
> >
> >In the past all users were stored in our special password system.  This
> >was on an embedded machine.  I used getpwnam() to get user data and then
> >I would get ACL data.  That is just the details.  To track users I would
> >auth their password against the one in the passwd system using one way
> >encryption.  I then took the one way encrypted string and added it to a
> >cookie.  The cookie data was 128-bit encrypted.  Every time the user
> >would access a page I would then re-authenticate them with that one way
> >encrypted password that they entered on the login page.  If there was no
> >match then I would redirect them to the login page.  The reason I did
> >this was in the condition that the administrator changed their password
> >or rights in between pages.  This was the only way I could think of how
> >to guarantee they had privs to the site.
> >
> >I want to do a similar thing in the webapp.  I plan on using a table in
> >our database to store user accounts for the application.  So during the
> >login phase I'll get their password and do a select on that table.  I
> >could simply use the password() function in mysql like this:
> >
> >select * from users where PASSWORD like PASSWORD('value');
> >
> >If I get a row then obviously the password matched.  Is this the correct
> >thing to do?
> >
> >Next question I have is on session tracking.  I can then use the servlet
> >session API and then add this encrypted string to the cookie.  Every
> >time the user access a page I can then do this:
> >
> >
> >select * from users where PASSWORD like PASSWORD('value');
> >
> >If I get a match then I know the user is good.  Otherwise I need to
> >redirect them to the login servlet.
> >
> >This is the only way I can guarantee they have access between each page.
> >
> >Is my solution a good solution or provides too much overhead?  I want to
> >keep good track of users and make sure there are no loop holes in the
> >security system.
> >
> >Thanks,
> >Chris
> >  
> >