You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Marc Boorshtein <mb...@gmail.com> on 2010/06/16 13:16:59 UTC
Setting JK_REMOTE_USER help
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. Here is my
httpd configuration:
JkWorkerProperty worker.list=worker1
JkWorkerProperty worker.worker1.type=ajp13
JkWorkerProperty worker.worker1.host=localhost
JkWorkerProperty worker.worker1.port=8009
JkShmFile /home/sys/oracle/oaam/apache/tmp/mod_jk.shm
JkLogFile /home/sys/oracle/oaam/apache/logs/mod_jk.log
JkLogLevel debug
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
#JkEnvVar REMOTE_USER worker1
JkEnvVar JK_REMOTE_USER %{remoteUser}e
<Location /oarm/* >
AuthType Basic
AuthName "OARM - Apache"
# (Following line optional)
AuthBasicProvider file
AuthUserFile /home/sys/oracle/oaam/apache/conf/oarm.pwd
Require user oaamadmin
#SetEnv JK_REMOTE_USER REMOTE_USER
#JkEnvVar JK_REMOTE_USER %{remoteUser}e
JkMount worker1
</Location>
Any help would be greatly appreciated
Thanks
Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by André Warnier <aw...@ice-sa.com>.
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 <Connector> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Marc Boorshtein <mb...@gmail.com>.
Sent from my iPhone
On Jun 16, 2010, at 11:12 AM, David kerber <dc...@verizon.net> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by David kerber <dc...@verizon.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Marc Boorshtein <mb...@gmail.com>.
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Pid <pi...@pidster.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Setting JK_REMOTE_USER help
Posted by Marc Boorshtein <mb...@gmail.com>.
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Pid <pi...@pidster.com>.
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 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 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!
>>
>> You can always contribute it back.
>>
>>
> 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.
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.
> 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.
> 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.
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.
> A naive linked question : is the <Realm> a purely Tomcat thing, or is it
> mandated by the Servlet Spec ?
It's a Tomcat thing, as are the Authenticators and Valves.
p
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Setting JK_REMOTE_USER help
Posted by Marc Boorshtein <mb...@gmail.com>.
On Thu, Jun 17, 2010 at 9:11 AM, Mark Thomas <ma...@apache.org> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Mark Thomas <ma...@apache.org>.
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 <Realm> a purely Tomcat thing, or is it
> mandated by the Servlet Spec ?
100% pure Tomcat.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by André Warnier <aw...@ice-sa.com>.
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 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!
>
> You can always contribute it back.
>
>
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.
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.
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 <Realm> a purely Tomcat thing, or is it mandated by the
Servlet Spec ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Pid <pi...@pidster.com>.
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 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!
You can always contribute it back.
p
> Thanks
> Marc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Setting JK_REMOTE_USER help
Posted by Marc Boorshtein <mb...@gmail.com>.
>>
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Pid <pi...@pidster.com>.
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
Re: Setting JK_REMOTE_USER help
Posted by Marc Boorshtein <mb...@gmail.com>.
>>
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Pid <pi...@pidster.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Setting JK_REMOTE_USER help
Posted by Marc Boorshtein <mb...@gmail.com>.
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Marc Boorshtein <mb...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by André Warnier <aw...@ice-sa.com>.
Marc Boorshtein wrote:
>> You should not need to do that, it should be automatic.
>> Just make sure that in the Tomcat <Connector> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by Marc Boorshtein <mb...@gmail.com>.
>
> You should not need to do that, it should be automatic.
> Just make sure that in the Tomcat <Connector> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Setting JK_REMOTE_USER help
Posted by André Warnier <aw...@ice-sa.com>.
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 <Connector> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org