[no subject]

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


</pre>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<hr>
<!--X-Follow-Ups-End-->
<!--X-References-->
<ul><li><strong>References</strong>:
<ul>
<li><strong><a name="00564" href="msg00564.html">[ale] User authentication in web app</a></strong>
<ul><li><em>From:</em> cfowler at outpostsentinel.com (Chris Fowler)</li></ul></li>
</ul></li></ul>
<!--X-References-End-->
<!--X-BotPNI-->
<ul>
<li>Prev by Date:
<strong><a href="msg00565.html">[ale] User authentication in web app</a></strong>
</li>
<li>Next by Date:
<strong><a href="msg00567.html">[ale] User authentication in web app</a></strong>
</li>
<li>Previous by thread:
<strong><a href="msg00571.html">[ale] User authentication in web app</a></strong>
</li>
<li>Next by thread:
<strong><a href="msg00597.html">[ale] User authentication in web app</a></strong>
</li>
<li>Index(es):
<ul>
<li><a href="maillist.html#00566"><strong>Date</strong></a></li>
<li><a href="threads.html#00566"><strong>Thread</strong></a></li>
</ul>
</li>
</ul>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
</body>
</html>