-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lb,
lightbulb432 wrote: > Where does Tomcat authentication fit into the request processing lifecycle? > Does it happen before even the very first filter gets called? Yes. It's implemented as a Valve that runs before any of your code gets a chance to run. > What happens just before and just after authentication? ?? When a request comes in, Tomcat checks to see if the resource is protected (by a <security-constraint> in web.xml). If it is, Tomcat checks to see if there's a Principal associated with the request (session, I'm guessing). If there's no Principal, the current request is saved and the user is redirected to the <form-login-page>. The login page should submit to j_security_check with the j_username and j_password request parameters. Once the user is authenticated, Tomcat attempts to re-run the saved request, and the process starts over again. If there /is/ a Principal, it checks to see if any of the required role names for the resource are held by the Principal. If none of the roles match, you get a 403 error. If there is a role match, the request continues normally. > Where does the role-based authorization fit into this process? See above. > When you login using form-based authentication, where invalid login attempts > redirect to the "form-error-page", how do you add a custom message to that > page saying "Login Failed"? I ask because common practice is to send the > user to the same login page rather than a different page. You can do whatever you want, since you get to control the pages for login and login-error. > Is it configuration whether Tomcat uses redirects or forwards after > successful or unsuccessful attempts? What's the default for both? There is no configuration for this. Some versions forward, others do not. There is no default because it's not in the specification. > How can you use JDBCRealm or DataSourceRealm with [numeric] foreign keys from > roles > table to user table, rather than requiring the roles table to duplicate > whatever field (e.g. username, email address) will actually be entered into > the login screen? You can't. You'd have to write your own Realm implementation. > I ask because using simple text-matching rather than using > the primary key of the user table seems a bit inefficient Are you sure about that? You might want to do a performance test on your database. You're likely to find that string matching is /very/ fast, especially if you have the columns indexed (and you really should). > but more > importantly it may be disallowed from data standards in some organizations. I think the most important thing is data duplication. Why should I have to put the user's username into the user_role table multiple times? It seems silly, but honestly, it's the simplest thing that could possibly work, which is exactly what the TC devs should have done. If you don't like the implementation, write your own. In fact, I don't much care for the TC implementation of the whole authentication thing anyway, so I have opted to dump it and use securityfilter instead. Primarily, it allows me to do direct logins (submit to j_security_check even when no protected resource has been requested), and I can write my own authenticator that isn't tied to Tomcat's implementation in any way. That allows me to switch TC versions or to another vendor entirely without changing a single thing in my implementation. But that's just me. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG1Ynf9CaO5/Lv0PARAotKAJ9T2XsOyyN2I8M97NOIqE5PuSPxCgCeKa7S 5NTEizEofO5a7N3wI4scCBk= =TAw5 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
