Web Application Login

[Darren Edwards]

I recently completed a project in which I hand crafted a login form and used the session to store the status - there was only one role of admin so it was very simple to do. I used the backend database to perform the username / password checks and it all works fine.

I've been looking over the security stuff in the web.xml in an attempt to learn how to do this 'properly'. Seems easy enough to use a form, but I can't find much information on how the username / password checking is done. Am I right in thinking it differs for each servlet container (I'm using tomcat currently) ?

How do others deal with this situation, perhaps you could point me to some good examples or sample code?

[Bear Bibeault]

"Darren",

There aren't many rules that you need to worry about here on the Ranch, but one that we take very seriously regards the use of proper names. Please take a look at the JavaRanch Naming Policy and adjust your display name to match it.

In particular, your display name must be a first and a last name separated by a space character, and must not be obviously fictitious.

Thanks!
bear
JavaRanch Sheriff

[Bear Bibeault]

What's "improper" about the way you are doing it? I always use hand-crafted authentication because it gives me more fine-grained control over user premissions and roles.

[Purushoth Thambu]

If you want to authenticate users in tomcat you can setup JDBCRealm. All you need to do is
- Create a form with action set to "j_security_check"
- Input field with name "j_username"
- Password field with name "j_password"
- Change the server.xml to use the right realm (JDBC/JNDI so on).
You must comment the existing realm if you plan to change.

And in web.xml you have to configure the <login-auth> element with auth-method, realm-name, form-login-config.

See Tomcat
realm howto

[Darren Edwards]

adjust your display name to match it.

Oops! Fixed now.

Purushothaman, my only problem with that is it ties the authentication into tomcat. Personally I think it destroys part of the purpose of java when you say to clients you must deploy it with container X (tomcat in this case).

I have already gone to the trouble of writing custom authentication which I can port with each application I write. It makes no use of the security related entries in web.xml though (entries I'm learning about ready to sit the SCWCD). Bear, does your solution make use of prefefined roles in web.xml or is it all hand crafted? What I'm getting at is if I can't make use of the security related elements in web.xml to achieve a powerful and flexible solution, what's the point of them?

[Darren Edwards]

https://coderanch.com/t/169779/java-Web-Component-SCWCD/certification/Share-WebApp-Security-implementations-experience is someone else asking a similar question, but there were no answers ...

[Bear Bibeault]

Originally posted by Darren Edwards:
Bear, does your solution make use of predefined roles in web.xml or is it all hand crafted?

I generally hand-craft it.

What I'm getting at is if I can't make use of the security related elements in web.xml to achieve a powerful and flexible solution, what's the point of them?

They're more than adequaate for a lot of cases. I usually just need a bit more flexibility.

Now, don't get me wrong. I'm not saying that you shouldn't use the built-in stuff if it works for you. But I'm saying that it's certainly not wrong not to either. If your home-grown solution is working for you, why muck with it?

Becoming familiar with the web.xml mechanisms is a worthwhile goal though as you may find it suits any future projects, or you could find that it will better suit your current project.
[ May 13, 2006: Message edited by: Bear Bibeault ]

[Darren Edwards]

I'm not saying that you shouldn't use the built-in stuff if it works for you

Sadly I cannot see any case where it would be a viable solution to use the built in stuff, primarily because it offers poor security (excluding client cert which is unrealistic for most) and an inability to keep authentication mechanisms cross servlet container compatible.

If your home-grown solution is working for you, why muck with it?

When I have time I like to see how other people have achieved the same goal so, armed with all the options, I can choose the best solution in future projects.

Perhaps something along the lines of;

<login-config>
  <auth-method>FORM</auth-method>
  <form-login-config>
    <form-login-page>login.jsp</form-login-page>
    <form-error-page>loginError.jsp</form-error-page>
    [B]<form-login-authenticator-class>com.example.MyAuthenticator</form-login-authenticator-class>[/B]
  </form-login-config>
</login-config>

where MyAuthenticator extends a simple interface (from servlet API 2.5 maybe!) with a method like

public boolean authenticate(String username, String password) throws ServletException;

IMO that would make form based authentication useable and flexible as roles can be dealt with separately while I can make a cross servlet container compatible authentication mechanism.

On the other hand, perhaps this is not a problem for most developers because they are using frameworks like struts?