views:

1206

answers:

3

We are currently trying to implement a web application which is using the J2EE authentication mechanism with a FORM-based login, inside the Websphere 6.1 web container. If the authentication is successful, we have everything working; the LDAP membership groups are being retrieved, the group to role mapping is being performed, and the roles are being returned to and correctly interpreted by the web application.

If the authentication is not successful, the form-login-error page is being returned. However, this is a static page that simply says something like "there was an error". How do we trap the specific error that prevented the successful login (username/password incorrect, LDAP repository unavailable, account locked, password expired, etc.)? It seems like there should be some easy way to do this, as you would want to treat some "security" exceptions differently than others.

A: 

This is ancient knowledge - I believe to have done such a thing with tomcat. There was, as far as I can remember, no standard way, as the implementation was completely decoupled from the request and frontend web stuff, so that it was difficult to establish any means of communication between the authenticating component and the frontend (e.g. error page).

We ended up with a tomcat specific way, relying heavily on the current implementation. I'm no longer with that company, so I can't tell about the current state of the code or the solution we chose back then. I believe you'll also have to have some Websphere specific solution - be it the use of thread local variables, keying messages with the username that attempted to log in, somehow getting hold of the session identifier or similar.

Olaf
A: 

Check this article Securing J2EE Applications with a Servlet Filter. I believe it covers your requirement to be able to pass the reason for the authentication error.

Philip T.
Nice article, but I read the question "how do I feed back errors during authentication to the user". Authentication is (in JEE) decoupled from application, so that filters can't intercept the request (and username/password) used for logging in. Which is usually nice except in situations like this...
Olaf
+1  A: 
jim
Interesting - I've never tried to implement my own j_security_check servlet. I always assumed that the container would take care of this and the application would not have a chance to see the password. Will check immediately...
Olaf
Sorry - That's kind of misleading. You don't have to implement your own j_security_check servlet as that is handled by Websphere. Use the above code to check what comes out of that servlet and take action.
jim