On 17/06/2010 15:08, Marc Boorshtein wrote: >>> Hi. >>> I must say that, with my limited knowledge of the Tomcat internals taken >>> into consideration, I tend to agree with Marc in this case, if he is >>> right in claiming that the Tomcat Realm mixes authentication with >>> authorization and does not allow to separate the two. >> >> Well, he said he's managed to make it work, so it must be possible to >> separate the two. >> > > I got it to work by writing custom code (namely I commented out the > "bind" in the JNDIRealm). Thats OK for my own needs building a POC > but I wouldn't use it in production. > >> As far as I could tell, his major complaint was that it didn't just work >> 'out of the box' (but it needs a 3rd party agent in the other examples). >> He also threw in a complaint about contract violations which I didn't >> think was fair, or valid. >> > > So apparently you didn't actually READ what I wrote in my previous > email. I would suggest you do as it is quite detailed and pinpoints > exactly what my "complaint" is.
Steady now. You might not like my take on it, but I read it. >>> At the very least, I would expect the Realm to check first if the >>> request already has a user-id, and skip the authentication part in such >>> a case. >> >> The Realm doesn't see the request at all. >> > > This is what the "base" problem probably is. The authentication > mechanism doesn't have the conext to make decisions > >>> There are many cases out there were Tomcat is only a part of a more >>> complex system, where a network-wide authentication is required, while >>> the authorization part may still be one that only Tomcat can do. >> >> I don't think the Servlet Spec defines a situation where authentication >> and authorisation occur separately, but I'm happy to be corrected. >> > > No, it doesn't. It just defines an API that should work regardless. That's a fairly sweeping statement you've made there. >> The Spec defines some methods of authentication & authorization (BASIC, >> FORM, etc), and some objects associated with the request which describe >> some properties of an authenticated user principal, and it's roles. >> >> It also makes statements about what Containers must provide API wise, >> but it doesn't say how. > > Yes. Thats my point. It should be transparent. It is. You've still got to plug something into the back of the API to make it do what you want. If what you want is something complicated then maybe Tomcat won't do that without modification, as you've found. > I (or any developer) > that writes my app to the spec should not have to recode their > applicatoin because the container doesn't handle a common > configuration change such as externalizing authentication. You're talking about having to change your app, but you've only described having to make modifications to a Tomcat internal support class. You seem to be saying that Tomcat has a compliancy issue - IMO the problem with leaving that unchallenged is that it breeds misunderstanding that would land back here sometime later. I don't think it's reasonable to mix an argument about spec compliancy with an point about something that isn't covered by the spec - even if it is a common requirement. > I'd be happy to share how I was able to get this to work...where is > the best place, the wiki? Yep. p (Enough now.) > Marc > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: OpenPGP digital signature
