Account locking for DatabaseServerLoginModule

[aldab]

This is a general question how this common use case should be implemented?

We extended DatabaseServerLoginModule by handling locking account inside login() method. So after 3 consecutive authentication failures (wrong credentials) account is locked for couple of minutes. Anyway the strange thing is that we had to pass authentication (return true inside login) and store the exception inside ThreadLocal variable. So inside our statless bean (initial invocation) we check if any exception is set and throw the appropriate exception to the client. Anyway it has a main general issue. Someone may invoke some other bean's methods and even the account is locked it will be authenticated as locking is outside the JAAS functionality.

Could anyone tell me what should be the correct solution for that? For me the best would be to raise my own LoginException inside this module and to retrieve it on the client side (not receive EJBException as it is now).

[aldab]

Eventually we handled this by adding Interceptor in which the account locking mechanism is invoked. Thus JAAS Login module cares about authentication and authorization only and if credentials are correct it authenticate user, but if the account is locked then on our own Interceptor the application exception is raised. In this way all methods invocations are handled.

Anyway would be great if anybody may share Your solution for that common use case.

[tiputini]

We are experiencing the same thing after migrating our EJB2 application from JBoss 4.2.3 to 6.1.0. The behavior in JBoss 4.2.3 used to be that the original FailedLoginException from the JAAS mechanism was propagated to the client. In JBoss 6.1.0, the client always receives the generic SecurityException thrown in the SecurityInterceptor.

I have been able to trace it back to the following change;

https://lists.jboss.org/pipermail/jboss-cvs-commits/2007-October/043547.html

Appearantly, you can implement your own observer instead, it gets called on authenticationFailed. With that you might be able to rethrow the original exception (SecurityActions.getContextException()).

I have tried implementing a custom interceptor as you describe. Without the use of a ThreadLocal, but using the SecurityActions.getContextException(). That seems to do the trick just fine.

Still, I would be interested to learn about the best practice on how to implement this use case. The use of SecurityActions is package restricted, so i am not completely satisfied with my current solution.