-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark and Maarten,
On 10/10/12 8:24 AM, Mark Thomas wrote: > On 10/10/2012 10:30, Maarten van Hulsentop wrote: >> Hi, >> >> We are configuring our Tomcat web application to authenticate >> using SPNEGO (Kerberos in particular) on Tomcat 7.0.29. Following >> the step-by-step 'Windows Authentication How-To', i succeeded >> doing so. Part of setting it up was configuring a Realm that >> assigns a role to the user, because the web application requires >> this. The Realm is supposed to grant the role to any user, where >> the password equals the user name. >> >> Now, as long as we combine the SPNEGOAuthenticator and this >> Realm, there is no issue. But as soon as somebody starts using my >> special Realm in combination with, lets say, the >> BasicAuthenticator, we have introduced a huge security hole. >> >> In my mind, the responsibilities are assigned differently. The >> Valves (Authenticators) should be doing the HTTP >> request/header/login form/etc handling, and the Realm should be >> doing the actual Authentication against some data source. In the >> case of SPNEGO, the SPNEGOAuthenticator seems to try to do the >> authentication as well, and only delegate to the Realm to finally >> grant the role. > > Correct. Things aren't are clear cut as I would like for SPNEGO or > for CLIENT-CERT where it is difficult / impossible to separate the > information gathering (Authenticator) from the validation (Realm). At one point, I tried to re-architect the authenticator/realm stuff in securityfilter because it really is fairly insane. It was originally based (I gather) upon Tomcat's architecture and even used to plug-into Tomcat (until Tomcat Realms started needing more support from Tomcat internals instead of being completely independent), so it shares the same authenticator / realm separation. Conceptually, everything should be separated into controller, credential-gathering, and authentication components. The credential-gathering component should be able to take input (the request) and provide credentials. Then the controller can provide those creds to the authentication component. If the authentication fails, the credential-gathering component can be used to take appropriate action (e.g. return a 401 response, redisplay a login form, etc.). > Generally yes, but reality gets in the way for some authentication > methods. Very much so, yes: as soon as you try to step outside of the HTTP Basic/Digest and FORM authentication (really credential-gathering) strategies, things get weird. CLIENT-CERT is perhaps the weirdest of all of these, because there is basically neither a user interface to gather credentials (other than the browser's "choose client cert" dialog) nor is there an authentication interface, because everything gets done at the SSL layer. Technically speaking, the CLIENT-CERT could be implemented with the kind of separation described above, but it's needlessly complicated that way. The point I was trying to get around to, here, was that the credential-gathering component can produce credentials that have private information that only a certain (paired) authenticator knows about. In that case, a SPNEGO cred-gatherer could be coupled with a SPNEGO authenticator such that the authentication (and role-assignment) would only work when the credentials came from the right kind of credential-gathering component. I'm interested to see what you come up with, Maarten. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB17MYACgkQ9CaO5/Lv0PBNPgCfRmxbRsB8jmCssjXOcyYMxqSE mosAoKPBTIy4ugOaIVf5cWyVpe47PtDB =q9Fl -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
