Re: Setting JK_REMOTE_USER help
> > 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. > We can agree to disagree on this one. Either way Tomcat 6 can not support a very common pattern in application deployment. I think it would be valuable for Tomcat to support this model and will work on I'll take a look at the 7 code to see how I can help. Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
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
Re: Setting JK_REMOTE_USER help
>> 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. >> 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. > 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. 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. I'd be happy to share how I was able to get this to work...where is the best place, the wiki? Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
On Thu, Jun 17, 2010 at 9:11 AM, Mark Thomas wrote: > On 17/06/2010 13:26, André Warnier wrote: >> 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. > > That is how Tomcat Realms are designed. This is consistent with the > Servlet sepc that leaves the implementation details entirely to the > container. If Tomcat required all authentication requests to be made via > carrier pigeon then that would be spec complaint providing the correct > information was exposed via the API defined in the spec. > Yes, it is as long as Tomcat is not combined with Apache or IIS. Once Tomcat offloads the authentication to Apache/IIS there should be a mechanism in place to still continue the authorization framework. >> 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. > > Easier said than done. The Realms deliberately have no visibility of the > request or the response. The Authenticators extract the username and > password, pass them to the realm to obtain an authenticated Principal > (with roles) and then the Authenitcators populate the attributes that > then support the calls in the Servlet API. > > The way to handle this (probably) is to modify the Authenticators > (hopefully just the base class) to check for an already authenticated > user. If one is found, use the realms just to get the roles. The > implementation for that is already in place. It just needs adding to the > interface and the visibility changed. Then you just need to figure out > how to merge the existing Principal (that may have roles) with the new > one that has the roles from the Realm. > > Tomcat 7's internal API has deliberately been declared as volatile inthe > docs so now is the time to make these changes. Patches welcome. > > Note this won't get ported back to 6 due to the API changes required. I'll take a look at the tomcat 7 api and see what I can do. Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
On 17/06/2010 13:26, André Warnier wrote: > Pid wrote: >> On 17/06/2010 12:34, Marc Boorshtein wrote: > I'm not looking to start a holy war here, but is there anything > incorrect in what I said? Tomcat is a servlet container, the servlet Yes. You made a sweeping statement about container managed security which implied that things should just work. Someone has to make them work. As an app developer you might not have to worry about how the bits behind the API work, but some admin has to configure it properly. >>> No argument there. Thats what I started trying to figure out. As I >>> said this is a Commercial Off The Shelf application that was built to >>> the Servlet API specification. I didn't develop the app but given the >>> app is written to the Servlet API there are certain expectations do to >>> how the api is written. >>> >>> > API is a contract between the container and the developer, the > contract specifies how a developer would access role information > regardless of the implementation. Since the Realm implementation > assumes that Tomcat is doing the authentication and breaks when it > isn't Tomcat, isn't that a violation of the contract? No. I don't think it is. Your specific need might not be handled by the Realm implementations supplied with Tomcat, but that's not proof that either design of Realms is flawed or that Tomcat isn't spec compliant. >>> The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the >>> authentication unless you do a 100% custom realm. This is ultimately >>> how I solved my issue (I make a copy of JNDIRealm and took out the >>> credential check). Why I feel this is an issue with Tomcat's >>> implementation is explained below. >>> > It's open > source, so I'm not complaining or demanding anything. I think I know > how to do what I need however that doesn't change the facts of the > situation that Tomcat does not have the built in capability for a > standard realm to simply retrieve user infomation as opposed to > authentication AND user retrieval that would enable Tomcat to maintain > its compliance while being fronted by Apache. The explanation you provided in your 3rd email doesn't sound like 'simply' to me. You also state that other servlet containers need a 3rd party agent to achieve the desired result. If your complaint is accurate then the other 3 servers you name must also 'violate the contract' because they don't provide what you need out of the box. >>> The way WebSphere and Weblogic work (I've not done this integration >>> with JBoss so I can't speak to it) there is a security subsystem that >>> seperates user & group retrieval from actual authentication. The >>> reason for this is to allow third party authentication providers to be >>> plugged into the system without changing how the application server >>> retrieves user information. >> >> So is the problem that Tomcat doesn't provide the same pluggability that >> the other (full JEE servers) do? >> >>> Here's the flow of how WebSphere with SiteMinder integrates: >>> >>> 1. User accesses URL pointing to IHS (an apache variant) >>> 2. SiteMinder "agent" in IHS authenticates and authorizes the user >>> 3. WebSphere plugin (which would be a peer to mod_jk) forwards the >>> request to WebSphere >>> 4. WebSphere executes a "TAI" (I forget what the acronym stands for) >>> that is provided by the vendor (in this case CA) validate the request >>> and provide WebSphere with the user's principal. Websphere also >>> exposes its API to the TAI for retrieving user information for >>> building the Principal object. >>> 5. WebSphere executes it's security configuration as it executes the >>> request >>> >>> It is a similar process for Oracle Access Manager and IBM Tivoli >>> Access Manager as well with Oracle Weblogic. The critical point here >>> is that if you swapped out any of the above Web Access Managers (or >>> even replace them with Federation systems like Ping) you don't change >>> how WebSphere RETRIEVES user information and do not need to recode the >>> application. The only portion that gets changed is the third party >>> integration tool. This was the intent of including security >>> components in the Servlet API. >> >> Because the pluggable 3rd party agent handles that for you? >> >> >>> So do I think Tomcat needs to support every WAM or Federation system? >>> No, that would be completely unreasonable. Do I think that Tomcat >>> should not require a re-coding of a component that has nothing to do >>> with authentication when changing authentication systems? Yes. I do >>> think that is reasonable. I think its reasonable that if I provide >>> the authentication mechanism that Tomcat should be able to accept it >>> and retrieve the user information without being forced to do the >>> authentication on i
Re: Setting JK_REMOTE_USER help
On 17/06/2010 13:26, André Warnier wrote: > 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. That is how Tomcat Realms are designed. This is consistent with the Servlet sepc that leaves the implementation details entirely to the container. If Tomcat required all authentication requests to be made via carrier pigeon then that would be spec complaint providing the correct information was exposed via the API defined in the spec. > 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. Easier said than done. The Realms deliberately have no visibility of the request or the response. The Authenticators extract the username and password, pass them to the realm to obtain an authenticated Principal (with roles) and then the Authenitcators populate the attributes that then support the calls in the Servlet API. The way to handle this (probably) is to modify the Authenticators (hopefully just the base class) to check for an already authenticated user. If one is found, use the realms just to get the roles. The implementation for that is already in place. It just needs adding to the interface and the visibility changed. Then you just need to figure out how to merge the existing Principal (that may have roles) with the new one that has the roles from the Realm. Tomcat 7's internal API has deliberately been declared as volatile inthe docs so now is the time to make these changes. Patches welcome. Note this won't get ported back to 6 due to the API changes required. > 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. > > A naive linked question : is the a purely Tomcat thing, or is it > mandated by the Servlet Spec ? 100% pure Tomcat. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Pid wrote: On 17/06/2010 12:34, Marc Boorshtein wrote: I'm not looking to start a holy war here, but is there anything incorrect in what I said? Tomcat is a servlet container, the servlet Yes. You made a sweeping statement about container managed security which implied that things should just work. Someone has to make them work. As an app developer you might not have to worry about how the bits behind the API work, but some admin has to configure it properly. No argument there. Thats what I started trying to figure out. As I said this is a Commercial Off The Shelf application that was built to the Servlet API specification. I didn't develop the app but given the app is written to the Servlet API there are certain expectations do to how the api is written. API is a contract between the container and the developer, the contract specifies how a developer would access role information regardless of the implementation. Since the Realm implementation assumes that Tomcat is doing the authentication and breaks when it isn't Tomcat, isn't that a violation of the contract? No. I don't think it is. Your specific need might not be handled by the Realm implementations supplied with Tomcat, but that's not proof that either design of Realms is flawed or that Tomcat isn't spec compliant. The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the authentication unless you do a 100% custom realm. This is ultimately how I solved my issue (I make a copy of JNDIRealm and took out the credential check). Why I feel this is an issue with Tomcat's implementation is explained below. It's open source, so I'm not complaining or demanding anything. I think I know how to do what I need however that doesn't change the facts of the situation that Tomcat does not have the built in capability for a standard realm to simply retrieve user infomation as opposed to authentication AND user retrieval that would enable Tomcat to maintain its compliance while being fronted by Apache. The explanation you provided in your 3rd email doesn't sound like 'simply' to me. You also state that other servlet containers need a 3rd party agent to achieve the desired result. If your complaint is accurate then the other 3 servers you name must also 'violate the contract' because they don't provide what you need out of the box. The way WebSphere and Weblogic work (I've not done this integration with JBoss so I can't speak to it) there is a security subsystem that seperates user & group retrieval from actual authentication. The reason for this is to allow third party authentication providers to be plugged into the system without changing how the application server retrieves user information. So is the problem that Tomcat doesn't provide the same pluggability that the other (full JEE servers) do? Here's the flow of how WebSphere with SiteMinder integrates: 1. User accesses URL pointing to IHS (an apache variant) 2. SiteMinder "agent" in IHS authenticates and authorizes the user 3. WebSphere plugin (which would be a peer to mod_jk) forwards the request to WebSphere 4. WebSphere executes a "TAI" (I forget what the acronym stands for) that is provided by the vendor (in this case CA) validate the request and provide WebSphere with the user's principal. Websphere also exposes its API to the TAI for retrieving user information for building the Principal object. 5. WebSphere executes it's security configuration as it executes the request It is a similar process for Oracle Access Manager and IBM Tivoli Access Manager as well with Oracle Weblogic. The critical point here is that if you swapped out any of the above Web Access Managers (or even replace them with Federation systems like Ping) you don't change how WebSphere RETRIEVES user information and do not need to recode the application. The only portion that gets changed is the third party integration tool. This was the intent of including security components in the Servlet API. Because the pluggable 3rd party agent handles that for you? So do I think Tomcat needs to support every WAM or Federation system? No, that would be completely unreasonable. Do I think that Tomcat should not require a re-coding of a component that has nothing to do with authentication when changing authentication systems? Yes. I do think that is reasonable. I think its reasonable that if I provide the authentication mechanism that Tomcat should be able to accept it and retrieve the user information without being forced to do the authentication on its own. Surely that's subjective, it depends entirely on the authentication & authorization mechanism you want to use. I wouldn't expect Tomcat to be able to effect authorization when I've authenticated by Internet Telepathy(tm). (To pick a wildly unreasonable alternative) I want to be clear. I think Tomcat is a great product and like all great products it has it's strengths and weaknesses. Even between the 1/2 hour of coding I ha
Re: Setting JK_REMOTE_USER help
On 17/06/2010 12:34, Marc Boorshtein wrote: >>> >>> I'm not looking to start a holy war here, but is there anything >>> incorrect in what I said? Tomcat is a servlet container, the servlet >> >> Yes. >> >> You made a sweeping statement about container managed security which >> implied that things should just work. Someone has to make them work. >> >> As an app developer you might not have to worry about how the bits >> behind the API work, but some admin has to configure it properly. >> > > No argument there. Thats what I started trying to figure out. As I > said this is a Commercial Off The Shelf application that was built to > the Servlet API specification. I didn't develop the app but given the > app is written to the Servlet API there are certain expectations do to > how the api is written. > > >> >>> API is a contract between the container and the developer, the >>> contract specifies how a developer would access role information >>> regardless of the implementation. Since the Realm implementation >>> assumes that Tomcat is doing the authentication and breaks when it >>> isn't Tomcat, isn't that a violation of the contract? >> >> No. I don't think it is. >> >> Your specific need might not be handled by the Realm implementations >> supplied with Tomcat, but that's not proof that either design of Realms >> is flawed or that Tomcat isn't spec compliant. >> > > The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the > authentication unless you do a 100% custom realm. This is ultimately > how I solved my issue (I make a copy of JNDIRealm and took out the > credential check). Why I feel this is an issue with Tomcat's > implementation is explained below. > >>> It's open >>> source, so I'm not complaining or demanding anything. I think I know >>> how to do what I need however that doesn't change the facts of the >>> situation that Tomcat does not have the built in capability for a >>> standard realm to simply retrieve user infomation as opposed to >>> authentication AND user retrieval that would enable Tomcat to maintain >>> its compliance while being fronted by Apache. >> >> The explanation you provided in your 3rd email doesn't sound like >> 'simply' to me. You also state that other servlet containers need a 3rd >> party agent to achieve the desired result. >> >> If your complaint is accurate then the other 3 servers you name must >> also 'violate the contract' because they don't provide what you need out >> of the box. >> >> > > The way WebSphere and Weblogic work (I've not done this integration > with JBoss so I can't speak to it) there is a security subsystem that > seperates user & group retrieval from actual authentication. The > reason for this is to allow third party authentication providers to be > plugged into the system without changing how the application server > retrieves user information. So is the problem that Tomcat doesn't provide the same pluggability that the other (full JEE servers) do? > Here's the flow of how WebSphere with SiteMinder integrates: > > 1. User accesses URL pointing to IHS (an apache variant) > 2. SiteMinder "agent" in IHS authenticates and authorizes the user > 3. WebSphere plugin (which would be a peer to mod_jk) forwards the > request to WebSphere > 4. WebSphere executes a "TAI" (I forget what the acronym stands for) > that is provided by the vendor (in this case CA) validate the request > and provide WebSphere with the user's principal. Websphere also > exposes its API to the TAI for retrieving user information for > building the Principal object. > 5. WebSphere executes it's security configuration as it executes the request > > It is a similar process for Oracle Access Manager and IBM Tivoli > Access Manager as well with Oracle Weblogic. The critical point here > is that if you swapped out any of the above Web Access Managers (or > even replace them with Federation systems like Ping) you don't change > how WebSphere RETRIEVES user information and do not need to recode the > application. The only portion that gets changed is the third party > integration tool. This was the intent of including security > components in the Servlet API. Because the pluggable 3rd party agent handles that for you? > So do I think Tomcat needs to support every WAM or Federation system? > No, that would be completely unreasonable. Do I think that Tomcat > should not require a re-coding of a component that has nothing to do > with authentication when changing authentication systems? Yes. I do > think that is reasonable. I think its reasonable that if I provide > the authentication mechanism that Tomcat should be able to accept it > and retrieve the user information without being forced to do the > authentication on its own. Surely that's subjective, it depends entirely on the authentication & authorization mechanism you want to use. I wouldn't expect Tomcat to be able to effect authorization when I've authenticated by Internet Telepathy(tm).
Re: Setting JK_REMOTE_USER help
>> >> I'm not looking to start a holy war here, but is there anything >> incorrect in what I said? Tomcat is a servlet container, the servlet > > Yes. > > You made a sweeping statement about container managed security which > implied that things should just work. Someone has to make them work. > > As an app developer you might not have to worry about how the bits > behind the API work, but some admin has to configure it properly. > No argument there. Thats what I started trying to figure out. As I said this is a Commercial Off The Shelf application that was built to the Servlet API specification. I didn't develop the app but given the app is written to the Servlet API there are certain expectations do to how the api is written. > >> API is a contract between the container and the developer, the >> contract specifies how a developer would access role information >> regardless of the implementation. Since the Realm implementation >> assumes that Tomcat is doing the authentication and breaks when it >> isn't Tomcat, isn't that a violation of the contract? > > No. I don't think it is. > > Your specific need might not be handled by the Realm implementations > supplied with Tomcat, but that's not proof that either design of Realms > is flawed or that Tomcat isn't spec compliant. > The design of the Tomcat Realm api is DEPENDENT on Tomcat doing the authentication unless you do a 100% custom realm. This is ultimately how I solved my issue (I make a copy of JNDIRealm and took out the credential check). Why I feel this is an issue with Tomcat's implementation is explained below. >> It's open >> source, so I'm not complaining or demanding anything. I think I know >> how to do what I need however that doesn't change the facts of the >> situation that Tomcat does not have the built in capability for a >> standard realm to simply retrieve user infomation as opposed to >> authentication AND user retrieval that would enable Tomcat to maintain >> its compliance while being fronted by Apache. > > The explanation you provided in your 3rd email doesn't sound like > 'simply' to me. You also state that other servlet containers need a 3rd > party agent to achieve the desired result. > > If your complaint is accurate then the other 3 servers you name must > also 'violate the contract' because they don't provide what you need out > of the box. > > The way WebSphere and Weblogic work (I've not done this integration with JBoss so I can't speak to it) there is a security subsystem that seperates user & group retrieval from actual authentication. The reason for this is to allow third party authentication providers to be plugged into the system without changing how the application server retrieves user information. Here's the flow of how WebSphere with SiteMinder integrates: 1. User accesses URL pointing to IHS (an apache variant) 2. SiteMinder "agent" in IHS authenticates and authorizes the user 3. WebSphere plugin (which would be a peer to mod_jk) forwards the request to WebSphere 4. WebSphere executes a "TAI" (I forget what the acronym stands for) that is provided by the vendor (in this case CA) validate the request and provide WebSphere with the user's principal. Websphere also exposes its API to the TAI for retrieving user information for building the Principal object. 5. WebSphere executes it's security configuration as it executes the request It is a similar process for Oracle Access Manager and IBM Tivoli Access Manager as well with Oracle Weblogic. The critical point here is that if you swapped out any of the above Web Access Managers (or even replace them with Federation systems like Ping) you don't change how WebSphere RETRIEVES user information and do not need to recode the application. The only portion that gets changed is the third party integration tool. This was the intent of including security components in the Servlet API. So do I think Tomcat needs to support every WAM or Federation system? No, that would be completely unreasonable. Do I think that Tomcat should not require a re-coding of a component that has nothing to do with authentication when changing authentication systems? Yes. I do think that is reasonable. I think its reasonable that if I provide the authentication mechanism that Tomcat should be able to accept it and retrieve the user information without being forced to do the authentication on its own. I want to be clear. I think Tomcat is a great product and like all great products it has it's strengths and weaknesses. Even between the 1/2 hour of coding I had to do to get the solution working, the bit more coding I'll have to do once I move from Basic authentication to form based and the very interesting conversation on this list it still took me less time to do it in tomcat then to get Weblogic setup, installed and configured! Thanks Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.o
Re: Setting JK_REMOTE_USER help
On 17/06/2010 02:41, Marc Boorshtein wrote: >>> >>> The problem with the Realm system is its designed with the assumption >>> that tomcat is doing the authentication which is not a valid >>> assumption in an environment where the authentication is seperated >>> from authorization. The entire point of container security is that as >>> a coder I don't have to worry about how any of this is implemented. >> >> The problem with Tomcat is that all too often it doesn't do what people >> expect it should do*. >> >> >> p >> >> * Or maybe the problem isn't Tomcat. > > I'm not looking to start a holy war here, but is there anything > incorrect in what I said? Tomcat is a servlet container, the servlet Yes. You made a sweeping statement about container managed security which implied that things should just work. Someone has to make them work. As an app developer you might not have to worry about how the bits behind the API work, but some admin has to configure it properly. > API is a contract between the container and the developer, the > contract specifies how a developer would access role information > regardless of the implementation. Since the Realm implementation > assumes that Tomcat is doing the authentication and breaks when it > isn't Tomcat, isn't that a violation of the contract? No. I don't think it is. Your specific need might not be handled by the Realm implementations supplied with Tomcat, but that's not proof that either design of Realms is flawed or that Tomcat isn't spec compliant. > It's open > source, so I'm not complaining or demanding anything. I think I know > how to do what I need however that doesn't change the facts of the > situation that Tomcat does not have the built in capability for a > standard realm to simply retrieve user infomation as opposed to > authentication AND user retrieval that would enable Tomcat to maintain > its compliance while being fronted by Apache. The explanation you provided in your 3rd email doesn't sound like 'simply' to me. You also state that other servlet containers need a 3rd party agent to achieve the desired result. If your complaint is accurate then the other 3 servers you name must also 'violate the contract' because they don't provide what you need out of the box. p signature.asc Description: OpenPGP digital signature
Re: Setting JK_REMOTE_USER help
>> >> The problem with the Realm system is its designed with the assumption >> that tomcat is doing the authentication which is not a valid >> assumption in an environment where the authentication is seperated >> from authorization. The entire point of container security is that as >> a coder I don't have to worry about how any of this is implemented. > > The problem with Tomcat is that all too often it doesn't do what people > expect it should do*. > > > p > > * Or maybe the problem isn't Tomcat. I'm not looking to start a holy war here, but is there anything incorrect in what I said? Tomcat is a servlet container, the servlet API is a contract between the container and the developer, the contract specifies how a developer would access role information regardless of the implementation. Since the Realm implementation assumes that Tomcat is doing the authentication and breaks when it isn't Tomcat, isn't that a violation of the contract? It's open source, so I'm not complaining or demanding anything. I think I know how to do what I need however that doesn't change the facts of the situation that Tomcat does not have the built in capability for a standard realm to simply retrieve user infomation as opposed to authentication AND user retrieval that would enable Tomcat to maintain its compliance while being fronted by Apache. Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
On 16/06/2010 18:27, Marc Boorshtein wrote: >> >> To look at this from a very strict point of view, the whole area is already >> a bit stretched. Tomcat has this notion of "roles" (because the Servlet >> Spec has this same notion). But if you look at common authentication >> schemes, like NTLM or LDAP, they do not have this notion. It is possible >> that some authentication "Realm" (another servlet-engine specific use of the >> term) "translates" the NTLM notion of "user group" (or some LDAP attribute) >> into Tomcat's notion of "role" (and in fact they often do). But that is a >> stretch. Unavoidable, because servlet engines do not know about "user >> groups", but stretch nevertheless. >> >> I suppose it would be boring if everyone agreed on the same notions all the >> time. > > The issue here is that the servlet specification specifies a way to > check what "role" a user is in. How that role is implemented (LDAP > group, user attribute, pulled out of a hat) doesn't really matter. An > application's code can write "if (request.isUserInRole("X")..." and > should work. It should also work whether you are using tomcat to do > authentication or something else (ie Apache+mod_jk or federation). > > The problem with the Realm system is its designed with the assumption > that tomcat is doing the authentication which is not a valid > assumption in an environment where the authentication is seperated > from authorization. The entire point of container security is that as > a coder I don't have to worry about how any of this is implemented. The problem with Tomcat is that all too often it doesn't do what people expect it should do*. p * Or maybe the problem isn't Tomcat. >> Basically, nobody stops you from retrieving some LDAP attributes of the user >> at the Apache level, and passing them over to Tomcat by adding one or more >> custom HTTP headers to the request (or a request attribute, as explained >> here : http://tomcat.apache.org/connectors-doc/reference/apache.html >> search for "JkEnvVar"). >> And then at the Tomcat level, adding a servlet filter which retrieves these >> header/attributes and stuffs them inside the UserPrincipal object, to >> satisfy Tomcat's isUserInRole() call (with some approximation due to my >> incomplete knowledge in these matters). >> >> Just an idea to avoid having to access LDAP twice. >> > > > LDAP as a service is generally fast enough to be a negligable part of > the AAA process. It looks like subclassing the JNDIRealm is going to > be the easiest way here. I don't need perfect, just working for this > POC. Spending 20 min on some code is still easier then getting > weblogic up and running. > > Thanks everyone! > > 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
Re: Setting JK_REMOTE_USER help
> > To look at this from a very strict point of view, the whole area is already > a bit stretched. Tomcat has this notion of "roles" (because the Servlet > Spec has this same notion). But if you look at common authentication > schemes, like NTLM or LDAP, they do not have this notion. It is possible > that some authentication "Realm" (another servlet-engine specific use of the > term) "translates" the NTLM notion of "user group" (or some LDAP attribute) > into Tomcat's notion of "role" (and in fact they often do). But that is a > stretch. Unavoidable, because servlet engines do not know about "user > groups", but stretch nevertheless. > > I suppose it would be boring if everyone agreed on the same notions all the > time. The issue here is that the servlet specification specifies a way to check what "role" a user is in. How that role is implemented (LDAP group, user attribute, pulled out of a hat) doesn't really matter. An application's code can write "if (request.isUserInRole("X")..." and should work. It should also work whether you are using tomcat to do authentication or something else (ie Apache+mod_jk or federation). The problem with the Realm system is its designed with the assumption that tomcat is doing the authentication which is not a valid assumption in an environment where the authentication is seperated from authorization. The entire point of container security is that as a coder I don't have to worry about how any of this is implemented. > > Basically, nobody stops you from retrieving some LDAP attributes of the user > at the Apache level, and passing them over to Tomcat by adding one or more > custom HTTP headers to the request (or a request attribute, as explained > here : http://tomcat.apache.org/connectors-doc/reference/apache.html > search for "JkEnvVar"). > And then at the Tomcat level, adding a servlet filter which retrieves these > header/attributes and stuffs them inside the UserPrincipal object, to > satisfy Tomcat's isUserInRole() call (with some approximation due to my > incomplete knowledge in these matters). > > Just an idea to avoid having to access LDAP twice. > LDAP as a service is generally fast enough to be a negligable part of the AAA process. It looks like subclassing the JNDIRealm is going to be the easiest way here. I don't need perfect, just working for this POC. Spending 20 min on some code is still easier then getting weblogic up and running. Thanks everyone! Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Marc Boorshtein wrote: OK, come context first: What I'm trying to do is integrate a Commercial Off The Shelf (COTS) application that relies on container security into a Web Access Manager (WAM). In a typical WAM deployment there are AAA is broken up into multiple layers: Web Server - Authentication (via the WAM) and course grained Authorization (can the user access this app?) Application - Fine grained Authorization aka Entitlements (can the user perform task x?) Since the authentication is done at the web server but the entitlements are done by the application the web server needs to tell the application server who the user is and the application server then needs to fulfill the J2EE contract by providing information about the user to the application. In commercial application servers (Weblogic, WebSphere, JBoss) this is done with an agent of some kind that satisfies the application server's security requirements (usually by phoning home to the WAM to validate the request). However commercial WAM products (SiteMinder, OAM, etc) don't provide an "agent" for Tomcat. Given that what I'm working on is a POC I'm not overly concerned with security as in production this app will likely run on weblogic but for my purposes Tomcat is a better pick for now. That being said, the sequence of events should be: 1. Web server authenticates the user (works) 2. Pass the context to Tomcat (works) Well, no. It passes a user-id to Tomcat. For Tomcat, the user-id may be part of a "context" (although I believe that for Tomcat also, the word "context" means "an application".) 3. Tomcat calls the realm to retrieve the user information and set the context (doesn't presently occur) Probably, more like yes. Tomcat, as far as I know, creates a userPrincipal object, which contains the user-id and other information if available. #3 appears to be the issue. Authenticaiton and Authorization should be separate steps entirely in order to satisfy the J2EE contract in an enterprise environment (which often involves WAMs). So it doesn't sound like there is a configuration way to handle this. I think I'll try hacking around to see if I can solve this with some kind of custom Realm. To look at this from a very strict point of view, the whole area is already a bit stretched. Tomcat has this notion of "roles" (because the Servlet Spec has this same notion). But if you look at common authentication schemes, like NTLM or LDAP, they do not have this notion. It is possible that some authentication "Realm" (another servlet-engine specific use of the term) "translates" the NTLM notion of "user group" (or some LDAP attribute) into Tomcat's notion of "role" (and in fact they often do). But that is a stretch. Unavoidable, because servlet engines do not know about "user groups", but stretch nevertheless. I suppose it would be boring if everyone agreed on the same notions all the time. Basically, nobody stops you from retrieving some LDAP attributes of the user at the Apache level, and passing them over to Tomcat by adding one or more custom HTTP headers to the request (or a request attribute, as explained here : http://tomcat.apache.org/connectors-doc/reference/apache.html search for "JkEnvVar"). And then at the Tomcat level, adding a servlet filter which retrieves these header/attributes and stuffs them inside the UserPrincipal object, to satisfy Tomcat's isUserInRole() call (with some approximation due to my incomplete knowledge in these matters). Just an idea to avoid having to access LDAP twice. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Sent from my iPhone On Jun 16, 2010, at 11:12 AM, David kerber wrote: On 6/16/2010 10:58 AM, Marc Boorshtein wrote: ... That being said, the sequence of events should be: 1. Web server authenticates the user (works) 2. Pass the context to Tomcat (works) 3. Tomcat calls the realm to retrieve the user information and set the context (doesn't presently occur) #3 appears to be the issue. Authenticaiton and Authorization should be separate steps entirely in order to satisfy the J2EE contract in an enterprise environment (which often involves WAMs). So it doesn't sound like there is a configuration way to handle this. I think I'll try hacking around to see if I can solve this with some kind of custom Realm. Keep in mind that Tomcat is not a full j2ee server; it's a "servlet container", so may not meet some of the requirements you have for your app if they are part of higher-level j2ee specs. D Yes, however there are security methods in the sevrlet spec (getPrincip, isUserInRole). Tomcat+mod_jk should satisfy these contracts Thanks Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
On 6/16/2010 10:58 AM, Marc Boorshtein wrote: ... That being said, the sequence of events should be: 1. Web server authenticates the user (works) 2. Pass the context to Tomcat (works) 3. Tomcat calls the realm to retrieve the user information and set the context (doesn't presently occur) #3 appears to be the issue. Authenticaiton and Authorization should be separate steps entirely in order to satisfy the J2EE contract in an enterprise environment (which often involves WAMs). So it doesn't sound like there is a configuration way to handle this. I think I'll try hacking around to see if I can solve this with some kind of custom Realm. Keep in mind that Tomcat is not a full j2ee server; it's a "servlet container", so may not meet some of the requirements you have for your app if they are part of higher-level j2ee specs. D - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
OK, come context first: What I'm trying to do is integrate a Commercial Off The Shelf (COTS) application that relies on container security into a Web Access Manager (WAM). In a typical WAM deployment there are AAA is broken up into multiple layers: Web Server - Authentication (via the WAM) and course grained Authorization (can the user access this app?) Application - Fine grained Authorization aka Entitlements (can the user perform task x?) Since the authentication is done at the web server but the entitlements are done by the application the web server needs to tell the application server who the user is and the application server then needs to fulfill the J2EE contract by providing information about the user to the application. In commercial application servers (Weblogic, WebSphere, JBoss) this is done with an agent of some kind that satisfies the application server's security requirements (usually by phoning home to the WAM to validate the request). However commercial WAM products (SiteMinder, OAM, etc) don't provide an "agent" for Tomcat. Given that what I'm working on is a POC I'm not overly concerned with security as in production this app will likely run on weblogic but for my purposes Tomcat is a better pick for now. That being said, the sequence of events should be: 1. Web server authenticates the user (works) 2. Pass the context to Tomcat (works) 3. Tomcat calls the realm to retrieve the user information and set the context (doesn't presently occur) #3 appears to be the issue. Authenticaiton and Authorization should be separate steps entirely in order to satisfy the J2EE contract in an enterprise environment (which often involves WAMs). So it doesn't sound like there is a configuration way to handle this. I think I'll try hacking around to see if I can solve this with some kind of custom Realm. >> >> As for the versions, thanks for the reminder: >> Tomcat 6.0.26 >> Apache 2.2.15 >> mod_jk 1.2 <== you are missing a number here, and for some things it >> really matters >> CentOS 5.5 >> > mod_jk 1.2.30 > - > 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: Setting JK_REMOTE_USER help
Marc Boorshtein wrote: You should not need to do that, it should be automatic. Just make sure that in the Tomcat for AJP (in server.xml), you set the attribute tomcatAuthentication="false" If the request is authenticated by Apache, mod_jk will (always) pass it internally to Tomcat, along with the request. If the above attribute is set, then Tomcat will also "believe" this user-id, and not try itself to authenticate the user. OK, so the good news is that setting tomcatAuthentication="false" did get tomcat to not prompt me for authentication. The bad news is that it looks like that this doesn't actually set the user's context it does, but maybe not with everything you were expecting because I am receiving unauthorized messages from the application which relies on container security. When Apache authenticates a user, it gets a user-id, like "marcb". That is what mod_jk passes to Tomcat, nothing else. That is one "A" of "AAA", which stands for Authentication, Authorization and Access-control. Authorization is another step, which can only be done by Tomcat in this case, because the concepts do not really match between Apache httpd and Tomcat (Apache has users and groups, Tomcat uses "roles"). I have an LDAP realm setup, is there a configuration to bridge this gap? If not I THINK I can write a "wrapper" realm that will take the user id attribute and "fake" it. Any thoughts? Since you have Apache in front already, you could do the whole AAA under Apache, and remove anything you do not really need from Tomcat. What do you really need to know about a user at the Tomcat application level, apart from his user-id ? (Or you could do the total opposite : do the whole AAA in Tomcat) The whole thing is rather flexible, and what you choose to do where is very much depending on your circumstances. (Like : do all accesses to Tomcat go through Apache first ? is the link between Apache and Tomcat secure ? are there resources served by Apache directly, and do some of them need AAA ? etc..) As for the versions, thanks for the reminder: Tomcat 6.0.26 Apache 2.2.15 mod_jk 1.2 <== you are missing a number here, and for some things it really matters CentOS 5.5 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
> > You should not need to do that, it should be automatic. > Just make sure that in the Tomcat for AJP (in server.xml), you > set the attribute > tomcatAuthentication="false" > > If the request is authenticated by Apache, mod_jk will (always) pass it > internally to Tomcat, along with the request. If the above attribute is > set, then Tomcat will also "believe" this user-id, and not try itself to > authenticate the user. > OK, so the good news is that setting tomcatAuthentication="false" did get tomcat to not prompt me for authentication. The bad news is that it looks like that this doesn't actually set the user's context because I am receiving unauthorized messages from the application which relies on container security. I have an LDAP realm setup, is there a configuration to bridge this gap? If not I THINK I can write a "wrapper" realm that will take the user id attribute and "fake" it. Any thoughts? As for the versions, thanks for the reminder: Tomcat 6.0.26 Apache 2.2.15 mod_jk 1.2 CentOS 5.5 Thanks Marc - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Also, it is *really really really* helpful, when you post a question, that you would specify the precise versions of software you are talking about. Like : Apache httpd version : 2.2.3 Tomcat version : 5.5.21 mod_jk version : 1.2.18 .. the documentation .. : the documentation page at : http://tomcat.apache.org/. It helps people here figure out if you have a real problem, or if your are using an old version with a know bug, or if you are looking at some incorrect instructions etc... It helps them getter a better idea, quickly, of where the issue may be. And it shows that you have at least done some homework yourself, before asking other people to spend their time trying to help you. All of the above have the indirect effect of motivating more people to help you faster, so it is also to your own advantage. André Warnier wrote: Marc Boorshtein wrote: All, I'm trying to setup apache in front of tomcat and have apache do the authentication for access and pass the user's context back to tomcat. I've seen documentation that says that I should set the JK_REMOTE_USER environment variable but it doesn't seem to be working. You should not need to do that, it should be automatic. Just make sure that in the Tomcat for AJP (in server.xml), you set the attribute tomcatAuthentication="false" see here : http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html (at the end) (if of course you are using Tomcat 6.0) If the request is authenticated by Apache, mod_jk will (always) pass it internally to Tomcat, along with the request. If the above attribute is set, then Tomcat will also "believe" this user-id, and not try itself to authenticate the user. - 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: Setting JK_REMOTE_USER help
Marc Boorshtein wrote: All, I'm trying to setup apache in front of tomcat and have apache do the authentication for access and pass the user's context back to tomcat. I've seen documentation that says that I should set the JK_REMOTE_USER environment variable but it doesn't seem to be working. You should not need to do that, it should be automatic. Just make sure that in the Tomcat for AJP (in server.xml), you set the attribute tomcatAuthentication="false" If the request is authenticated by Apache, mod_jk will (always) pass it internally to Tomcat, along with the request. If the above attribute is set, then Tomcat will also "believe" this user-id, and not try itself to authenticate the user. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org