Java EE (Java Enterprise Edition) General Discussion

J2EE form-based authentication will redirect an unauthenticated user trying to connect to a secured resource to a login page and will 1) send the user to the originally requested page upon successful authentication OR 2) send the user to the error page in the event of authentication failure. There are a couple of problems that I have with this implementation - not with j_security_check specifically, but with the pattern generally.

There are several events that a Portal must manage beyond simple authentication validation. Specifically

- Notify a user after successful authentication that their account has been locked and they must contact someone to get it unlocked.
- Notify a user after successful authentication that their password is about to expire and offer them a choice between changing their password immediately or proceeding to the requested resource.
- Notify a user after successful authentication that their password has expired and require that they change it before proceeding to the requested resource.
- Notify a user after successful authentication that they don't have rights to access to the requested resource even though they've been successfully authenticated and offer to redirect them to a page that they are authorized to access.

I am currently investigating a scheme to solve these problems by using servlets for the login and error 'pages', having these servlets forward to different .JSP's based on roles, and writing some sort of JAAS module to add an access (authorization) role based on the password and account lock status.

Has anyone else worked on this kind of problem? Are there any efforts to extend the J2EE specifications to handle these alternate flows in the j_security_check activity.

I'm frustrated with each of the different container providers handling the JAAS Authorization differently. Further, since the j_security_check doesn't discuss how the server tracks the original request, each container provider has used a custom mechanism for keeping the original URI as j_security_check activity proceeds.

One final gripe, since the J2EE specification does not specify how to deal with JAAS, and further define a mechanism to getting the Subject associated with the current ServletRequest, all providers have done this differently too. Perhaps this was avoided as a 'non-goal', but wouldn't it have been nice to state that 'should a provider decide to offer JAAS based security, the implementation must...'?