I think we will add the roles to AD and use AD to do the authorization as well. Because of the naming convention applied in the agency, we need to map the role defined in AD to the security-role defined in the web application. What is the best approach? I am thinking about using security-role-ref, but I have to go to each web.xml and add the information over there.
Thanks John -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, September 16, 2009 5:24 PM To: Tomcat Users List Subject: Re: decouple authentication and authorization of TOMCAT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André, On 9/14/2009 3:33 PM, André Warnier wrote: > John Chen wrote: >> Apache front-end will do the authentication, does tomcat still use >> tomcat-users.xml for the authorization part? > > I am not quite sure. I'm not sure which is the important part of the above question, but if you configure Tomcat to accept httpd's user id, Tomcat will almost certainly NOT use tomcat-users.xml for any reason whatsoever: you will have to remove any role-name constraints from your web application's security constraints for this to work. Using the special role name '*' MAY work, but my interpretation of the specification is that treating '*' as "any authenticated user, regardless of role name" is not correct. Most implementations I have seen of servlet authentication + authorization *do* treat '*' to mean "any authenticated user, regardless of role name" but that's just due to pure laziness of the implementation. (I'm not pointing fingers... securityfilter also takes the lazy approach). > I believe Tomcat's integrated AAA is pretty much > an all-or-nothing proposition. It is. You can wrap securityfilter in your own filter that does AD authentication but then uses sf for authorization if you want, but I have to think there's a better way. What's wrong with adding group/roles to AD? Perhaps there is a way to use JNDIRealm to force a role that doesn't actually exist in AD. If you'd like to hack JNDIRealm, patches are always welcome. We've seen this kind of request before, so I suspect it would be a useful thing to add to the realm itself. > But maybe, if the request is authenticated by Apache beforehand, it > may work, since after all the request is authenticated before Tomcat > even hits the webapp. I think you'll find that adding httpd is more trouble than it's worth. YMMV. > What I do not know, is if Tomcat, having accepted the prior > Authentication of the request, would still anyway check if this user-id > is "in a role" which allows running the webapp, and if it would do this > using the tomcat-users.xml database, even though it did not use it to > authenticate the user. Tomcat doesn't get any role information from httpd. I think it basically just creates a Principal object whose 'name' is the thing that httpd asserts it is. Again, I suspect that checks for the '*' role will succeed, but the spec does not guarantee such behavior. > - then, at the Tomcat level, you would need to override the > "isUserInRole()" method, so that it would compare the webapp's required > role or roles, with these additional attributes or HTTP headers. This may be more difficult than it sounds, because you'd have to do it in a Valve that is installed /before/ the security valve (or whatever) used by Tomcat. I believe that, for obvious security reasons, this is not possible using normal configuration. > I guess we should have a look at the securityfilter servlet filter, > since it may already do something of the kind. It does. Our next version should be a bit more modular, and should allow a user to trivially build an authorization-only module out of the pieces we provide. > What I don't know and cannot comment on, is if the above kind of scheme > would be easier to implement than creating a new Tomcat Realm which does > all that. I am also not sure (because I'm too lazy to check right now) > if a Tomcat Realm is specific to Tomcat, or part of the Servlet Spec and > thus portable. Not portable :( > (*) and, to make this more efficient, you could save this in a cookie, > so that on subsequent requests you can re-use it without re-looking up > the AD record. Uh.... are you sure you want to trust authentication information asserted by a remote client? It would be safer to trust a cookie-encoded session id and cache the AD info in the session. Why? Because session ids are randomized so that guessing a valid one is difficult. Guessing usernames is not so difficult. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqxV2wACgkQ9CaO5/Lv0PA03QCdHmoNpyCpOIp7gmjMLNDo4Tow MFIAnjKDRpI+r2Cxy2HF1nxlqE+KPkmb =Vvcj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
