Hi Bryan- I've done something similar to this on Tomcat and JRun. I noted in your last comment:
> But as you say prior, the filters aren't even being run, apparently, > before the container evaluates j_username and j_password, so I guess I > have no Servlet-standard hook there. I guess it's off to the > Authenticator API I go. > > Heck, at least I can keep all the authentication logic in one place with > that strategy, as opposed to splitting it between a Filter and a > LoginModule. > I'm not sure I completely understand your conclusion, but if you want to use JAAS, you will need a login module. The custom Authenticator Craig speaks of will automate the typical 2 step Form Authentication process. The Authenticator doesn't interact with the security datastore, the LoginModule does. I think rolling your authentication logic into the Authentictor might violate the seperation of concerns inherent in the authenticator/login module design. The Authenticator (like the FormAuthenticator) should be responsible for the user side of the interaction: is the user session authenticated? is the user offering credentials? where does the user want to go? The LoginModule should be responsible for interacting with the security data store and given a set of credentials, verifying that they are proper and returning a Principal after successful authentication. BTW: I see a lot of value in what you are doing. It would be nice to have a standard for single sign on that worked across all J2EE compatable servers. However, as it stands now, you will have to write LoginModules and Authenticator-type components for each container you encounter. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
