Re: decouple authentication and authorization of TOMCAT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John, On 9/16/2009 5:33 PM, John Chen wrote: 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. security-role-ref ought to do the trick. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqyaaQACgkQ9CaO5/Lv0PASGwCghm8OwK2z7emhAFqiISoOVNLE 7VQAniFDsd013gV2NswfuzLQnDMdAG9H =1Q+a -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
RE: decouple authentication and authorization of TOMCAT
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
Re: decouple authentication and authorization of TOMCAT
John Chen wrote: ... I am also thinking using Apache Web Server to do the authentication and use tomcat for authorization, do you think it would work? With the Apache/mod_jk/Tomcat combination it can, certainly. There exists (I believe in the Connector element of Tomcat), an attribute tomcatAuthentication, which when set to false makes Tomcat accept the user-id authenticated by Apache as its own. I do not know with other connectors. But if this would be the only reason to put Apache in front of your Tomcat, it would be a lot of complication for that sole purpose. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: decouple authentication and authorization of TOMCAT
John Chen wrote: Hi, We have installed a third-party software running on tomcat. Is there anyway to decouple tomcat authentication and authorization? We have to use AD for authentication and we are not encouraged to add groups to AD just for the new software. Any help would be appreciated. Since you said any, here is mine : I think you want to look at the following 2 things : 1) search Google for tomcat +securityfilter 2) http://www.ioplex.com, look at Jespa As I understand it, - Jespa will allow you to authenticate users based on their Windows Domain login - securityfilter should then allow you to allow access or not, based on that prior authentication (and, basically, you do not use Tomcat realm-based AAA) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: decouple authentication and authorization of TOMCAT
This would be new, I am just trying to find any solution and less pervasive. Thanks John -Original Message- From: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] On Behalf Of Peter Crowther Sent: Monday, September 14, 2009 12:09 PM To: Tomcat Users List Subject: Re: decouple authentication and authorization of TOMCAT 2009/9/14 John Chen jzc...@bstonetech.com I am also thinking using Apache Web Server to do the authentication and use tomcat for authorization, do you think it would work? Most things can be made to work - with sufficient thrust, pigs fly just fine. This approach was used for early Shibboleth implementations in a couple of Java LMSs, for example. Then a native Java Shibboleth implementation was developed, and life got easier. Are you already using Apache httpd in front of Tomcat for other purposes? Or would this be new? - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: decouple authentication and authorization of TOMCAT
Thanks I am also thinking using Apache Web Server to do the authentication and use tomcat for authorization, do you think it would work? John -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, September 14, 2009 11:52 AM To: Tomcat Users List Subject: Re: decouple authentication and authorization of TOMCAT John Chen wrote: Hi, We have installed a third-party software running on tomcat. Is there anyway to decouple tomcat authentication and authorization? We have to use AD for authentication and we are not encouraged to add groups to AD just for the new software. Any help would be appreciated. Since you said any, here is mine : I think you want to look at the following 2 things : 1) search Google for tomcat +securityfilter 2) http://www.ioplex.com, look at Jespa As I understand it, - Jespa will allow you to authenticate users based on their Windows Domain login - securityfilter should then allow you to allow access or not, based on that prior authentication (and, basically, you do not use Tomcat realm-based AAA) - 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
Re: decouple authentication and authorization of TOMCAT
2009/9/14 John Chen jzc...@bstonetech.com I am also thinking using Apache Web Server to do the authentication and use tomcat for authorization, do you think it would work? Most things can be made to work - with sufficient thrust, pigs fly just fine. This approach was used for early Shibboleth implementations in a couple of Java LMSs, for example. Then a native Java Shibboleth implementation was developed, and life got easier. Are you already using Apache httpd in front of Tomcat for other purposes? Or would this be new? - Peter
Re: decouple authentication and authorization of TOMCAT
On 14/09/2009 17:40, André Warnier wrote: John Chen wrote: ... I am also thinking using Apache Web Server to do the authentication and use tomcat for authorization, do you think it would work? With the Apache/mod_jk/Tomcat combination it can, certainly. There exists (I believe in the Connector element of Tomcat), an attribute tomcatAuthentication, which when set to false makes Tomcat accept the user-id authenticated by Apache as its own. I do not know with other connectors. But if this would be the only reason to put Apache in front of your Tomcat, it would be a lot of complication for that sole purpose. ... especially as we haven't established what the problem actually is. There is a JNDIRealm and the topic of an ActiveDirectory compatible Realm comes up not infrequently on this list. p - 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
RE: decouple authentication and authorization of TOMCAT
Apache front-end will do the authentication, does tomcat still use tomcat-users.xml for the authorization part? Thanks John -Original Message- From: André Warnier [mailto:a...@ice-sa.com] Sent: Monday, September 14, 2009 12:41 PM To: Tomcat Users List Subject: Re: decouple authentication and authorization of TOMCAT John Chen wrote: ... I am also thinking using Apache Web Server to do the authentication and use tomcat for authorization, do you think it would work? With the Apache/mod_jk/Tomcat combination it can, certainly. There exists (I believe in the Connector element of Tomcat), an attribute tomcatAuthentication, which when set to false makes Tomcat accept the user-id authenticated by Apache as its own. I do not know with other connectors. But if this would be the only reason to put Apache in front of your Tomcat, it would be a lot of complication for that sole purpose. - 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
Re: decouple authentication and authorization of TOMCAT
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 believe Tomcat's integrated AAA is pretty much an all-or-nothing proposition. 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. 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. Need an expert to confirm this. Anyway, for production usage, it is not recommended to use tomcat-users.xml, and it would also be rather unpractical if you have many users : you would still need to list all your expected user-id's in tomcat-users.xml, with their respective roles. I have been having this same kind of issue myself, fortunately with a very low ratio of users/tomcat, so I could find other workarounds. But I am interested also in a more general solution, in case the need ever crops up. Basically, I would present the problem as follows; (sorry if this is not very rigorous in Java or Servlet Spec or Tomcat terms) : - in Tomcat's flavor of AAA, one can specify, in the web-xml of a webapp, which role a user has to belong to, to be allowed to run the webapp. I suppose this is quite efficient, because Tomcat can read this in advance (when the webapp is deployed), and buffer it, so it does not have to check an external source at each request. - however, this notion of role does not really extend beyond Tomcat, so one would have to map it to, for example, some attribute of the AD (or LDAP) record of the user, and then arrange for Tomcat to be able to determine if the current user-id is in that role. (I believe there exists a method like ServletRequest.getRemoteUser().isUserInRole(role) or something of the kind). If the answer is positive, the request gets through, otherwise it doesn't. So the way I would see a practical solution, in a Windows Domain context (and in a platform-independent way) would be : - first you need to authenticate the user and obtain a user-id. This could be done via a front-end Apache, or via a servlet filter such as jCIFS or Jespa. - then you would need something which, on the base of the user-id, obtains a list of attributes of this user which can be mapped to Tomcat roles. For example, this could also be done at the front-end Apache stage, by accessing the user's AD directory record directly, and passing the corresponding attributes to Tomcat via request attributes or via added HTTP headers in the request. (*) - 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. Of course, since by that time you are not really using the Tomcat AAA much anyway, you might as well bypass it completely and do your own form of authorization (via e.g. a servlet filter), based on any sort of group list your filter has access to. I guess we should have a look at the securityfilter servlet filter, since it may already do something of the kind. 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. (*) 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. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
