You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2004/05/24 21:12:09 UTC
[J2] JAAS Authentication on Tomcat 5 problem
Yesterday I succeeded in enabling JAAS Authentication on Tomcat 4:
http://issues.apache.org/jira/browse/JS2-52
The problem is, it isn't working on Tomcat 5 because of a change in
classloading introduced with Tomcat 5 for the JAASRealm.
The JAASRealm implementation on Tomcat 5 is different from the one on
Tomcat 4 in that it sets the current Thread ClassLoaderContext to that
of the Catalina core itself before accessing a LoginModule.
The developer adding this *feature* himself seemingly thought it might
result in problems because it contains as inline comment:
"What if the LoginModule is in the container class loader ?".
I don't know if this is according to the JAAS specs or not but it is a
nasty problem with the current Jetspeed architecture.
I've looked into the Tomcat 5 Bug Database and found issue 26475:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26475
This issue exactly describes our problem.
But, Remy Maucherat, one of the lead developers, simply didn't find the
issue a problem (2004-01-27 23:31):
"Obviously, the realm is a server component. As a result, all its
dependent classes must reside in the server classloader. I do not see
anything wrong with this."
And (2004-01-28 09:07):
"/WEB-INF is the application classloader, not the server classloader.
This does not convince me at all. If somehow the realm can look up
stuff, the conext CL is the webapp CL during the realm initialization.
If nobody looks at this report within a week, I'll close it again."
And finally (2004-02-02 20:08):
"As there has been no activity, and I think the classloading behavior
is the right one, I am closing this bug. Please use tomcat-user if you
are still experiencing problems."
So it seems we're toast.
To be able to use JAAS Authentication on Tomcat 5 we are required to put
the RdbmsLoginModule in the server classpath. This can't be done right
now: it requires most of the persistence, rdbms and security classes and
putting them all there won't do either (leads to other classloader
issues and if it were working it would lead to two different OJB caches
in which changes made through the portal won't be seen by the
LoginModule or no cache should be used for the login).
As far as I can see there are three possible solutions:
1) Remodel Jetspeed in such a way that the RdbmsLoginModule can be used
from the Tomcat 5 server classpath. I guess this will take a lot of work
but I'm not the designer of the security component so maybe others see a
short way out?
2) Try to convince the Tomcat crew to revert to the old Tomcat 4
behavior. Maybe conditionally with an additional realm parameter?
I have a gut feeling they are not open to this but maybe Jetspeed is
important enough to make a difference???
3) Create an extended JAASRealm implementation or patch the current one
without the new Tomcat 5 ContextClassLoader problems. This would be a
short and simple solution (I tried it out: 5 minutes work) but it
creates a dependency on the current Tomcat 5 implementation and requires
putting the hacked/extended class in the server classpath.
Please comment.
Regards,
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] JAAS Authentication on Tomcat 5 problem
Posted by Roger Ruttimann <ro...@apache.org>.
Ate Douma wrote:
<snip>
>>>2) Try to convince the Tomcat crew to revert to the old Tomcat 4
>>>behavior. Maybe conditionally with an additional realm parameter?
>>>I have a gut feeling they are not open to this but maybe Jetspeed is
>>>important enough to make a difference???
>>>
>>>
>>>
>>Well there is an obvious issue:
>>You have one behavior in Tomcat 4, and another behavior in Tomcat 5
>>One would think the Tomcat team would want to minimize these kind of
>>issues.
>>I think we should try to make an argument
>>
>>
>>
>>>3) Create an extended JAASRealm implementation or patch the current
>>>one without the new Tomcat 5 ContextClassLoader problems. This would
>>>be a short and simple solution (I tried it out: 5 minutes work) but it
>>>creates a dependency on the current Tomcat 5 implementation and
>>>requires putting the hacked/extended class in the server classpath.
>>>
>>>
>>>
>>This sounds like the solution for now, until we can sort out #2
>>
>>
>That's +3 (including mine) for option #3.
>If nobody is going to object I will create a new issue and a patch this
>evening for this solution.
>
>I'm also +1 for option #2: sorting it out with the Tomcat Team. But even
>if they are willing to revert back to the Tomcat 4 behaviour, I expect it
>will take to long to have no solution for now. Solution #3 will cover
>that.
>
>
>
Sounds like a good strategy. Having solution #3 in place until the
Tomcat team might implement Tomcat 4 behavior in Tomcat 5. This allows
us to continue with the J2 development for tomcat 4 and 5.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] JAAS Authentication on Tomcat 5 problem
Posted by Ate Douma <at...@douma.nu>.
David Sean Taylor said:
>
> On May 24, 2004, at 12:12 PM, Ate Douma wrote:
>
>> Yesterday I succeeded in enabling JAAS Authentication on Tomcat 4:
>> http://issues.apache.org/jira/browse/JS2-52
>>
>> The problem is, it isn't working on Tomcat 5 because of a change in
>> classloading introduced with Tomcat 5 for the JAASRealm.
>>
>> The JAASRealm implementation on Tomcat 5 is different from the one on
>> Tomcat 4 in that it sets the current Thread ClassLoaderContext to that
>> of the Catalina core itself before accessing a LoginModule.
>>
>> The developer adding this *feature* himself seemingly thought it might
>> result in problems because it contains as inline comment:
>> "What if the LoginModule is in the container class loader ?".
>>
>> I don't know if this is according to the JAAS specs or not but it is a
>> nasty problem with the current Jetspeed architecture.
>>
>> I've looked into the Tomcat 5 Bug Database and found issue 26475:
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26475
>>
>> This issue exactly describes our problem.
>> But, Remy Maucherat, one of the lead developers, simply didn't find
>> the issue a problem (2004-01-27 23:31):
>> "Obviously, the realm is a server component. As a result, all its
>> dependent classes must reside in the server classloader. I do not see
>> anything wrong with this."
>>
>> And (2004-01-28 09:07):
>> "/WEB-INF is the application classloader, not the server
>> classloader. This does not convince me at all. If somehow the realm
>> can look up stuff, the conext CL is the webapp CL during the realm
>> initialization. If nobody looks at this report within a week, I'll
>> close it again."
>>
>> And finally (2004-02-02 20:08):
>> "As there has been no activity, and I think the classloading
>> behavior is the right one, I am closing this bug. Please use
>> tomcat-user if you are still experiencing problems."
>>
>> So it seems we're toast.
>> To be able to use JAAS Authentication on Tomcat 5 we are required to
>> put the RdbmsLoginModule in the server classpath. This can't be done
>> right now: it requires most of the persistence, rdbms and security
>> classes and putting them all there won't do either (leads to other
>> classloader issues and if it were working it would lead to two
>> different OJB caches in which changes made through the portal won't be
>> seen by the LoginModule or no cache should be used for the login).
>>
>> As far as I can see there are three possible solutions:
>> 1) Remodel Jetspeed in such a way that the RdbmsLoginModule can be
>> used from the Tomcat 5 server classpath. I guess this will take a lot
>> of work but I'm not the designer of the security component so maybe
>> others see a short way out?
>>
> Yes, we would need a scaled down light weight version, perhaps using
> JDBC only
>
>> 2) Try to convince the Tomcat crew to revert to the old Tomcat 4
>> behavior. Maybe conditionally with an additional realm parameter?
>> I have a gut feeling they are not open to this but maybe Jetspeed is
>> important enough to make a difference???
>>
> Well there is an obvious issue:
> You have one behavior in Tomcat 4, and another behavior in Tomcat 5
> One would think the Tomcat team would want to minimize these kind of
> issues.
> I think we should try to make an argument
>
>> 3) Create an extended JAASRealm implementation or patch the current
>> one without the new Tomcat 5 ContextClassLoader problems. This would
>> be a short and simple solution (I tried it out: 5 minutes work) but it
>> creates a dependency on the current Tomcat 5 implementation and
>> requires putting the hacked/extended class in the server classpath.
>>
> This sounds like the solution for now, until we can sort out #2
That's +3 (including mine) for option #3.
If nobody is going to object I will create a new issue and a patch this
evening for this solution.
I'm also +1 for option #2: sorting it out with the Tomcat Team. But even
if they are willing to revert back to the Tomcat 4 behaviour, I expect it
will take to long to have no solution for now. Solution #3 will cover
that.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] JAAS Authentication on Tomcat 5 problem
Posted by David Sean Taylor <da...@bluesunrise.com>.
On May 24, 2004, at 12:12 PM, Ate Douma wrote:
> Yesterday I succeeded in enabling JAAS Authentication on Tomcat 4:
> http://issues.apache.org/jira/browse/JS2-52
>
> The problem is, it isn't working on Tomcat 5 because of a change in
> classloading introduced with Tomcat 5 for the JAASRealm.
>
> The JAASRealm implementation on Tomcat 5 is different from the one on
> Tomcat 4 in that it sets the current Thread ClassLoaderContext to that
> of the Catalina core itself before accessing a LoginModule.
>
> The developer adding this *feature* himself seemingly thought it might
> result in problems because it contains as inline comment:
> "What if the LoginModule is in the container class loader ?".
>
> I don't know if this is according to the JAAS specs or not but it is a
> nasty problem with the current Jetspeed architecture.
>
> I've looked into the Tomcat 5 Bug Database and found issue 26475:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26475
>
> This issue exactly describes our problem.
> But, Remy Maucherat, one of the lead developers, simply didn't find
> the issue a problem (2004-01-27 23:31):
> "Obviously, the realm is a server component. As a result, all its
> dependent classes must reside in the server classloader. I do not see
> anything wrong with this."
>
> And (2004-01-28 09:07):
> "/WEB-INF is the application classloader, not the server
> classloader. This does not convince me at all. If somehow the realm
> can look up stuff, the conext CL is the webapp CL during the realm
> initialization. If nobody looks at this report within a week, I'll
> close it again."
>
> And finally (2004-02-02 20:08):
> "As there has been no activity, and I think the classloading
> behavior is the right one, I am closing this bug. Please use
> tomcat-user if you are still experiencing problems."
>
> So it seems we're toast.
> To be able to use JAAS Authentication on Tomcat 5 we are required to
> put the RdbmsLoginModule in the server classpath. This can't be done
> right now: it requires most of the persistence, rdbms and security
> classes and putting them all there won't do either (leads to other
> classloader issues and if it were working it would lead to two
> different OJB caches in which changes made through the portal won't be
> seen by the LoginModule or no cache should be used for the login).
>
> As far as I can see there are three possible solutions:
> 1) Remodel Jetspeed in such a way that the RdbmsLoginModule can be
> used from the Tomcat 5 server classpath. I guess this will take a lot
> of work but I'm not the designer of the security component so maybe
> others see a short way out?
>
Yes, we would need a scaled down light weight version, perhaps using
JDBC only
> 2) Try to convince the Tomcat crew to revert to the old Tomcat 4
> behavior. Maybe conditionally with an additional realm parameter?
> I have a gut feeling they are not open to this but maybe Jetspeed is
> important enough to make a difference???
>
Well there is an obvious issue:
You have one behavior in Tomcat 4, and another behavior in Tomcat 5
One would think the Tomcat team would want to minimize these kind of
issues.
I think we should try to make an argument
> 3) Create an extended JAASRealm implementation or patch the current
> one without the new Tomcat 5 ContextClassLoader problems. This would
> be a short and simple solution (I tried it out: 5 minutes work) but it
> creates a dependency on the current Tomcat 5 implementation and
> requires putting the hacked/extended class in the server classpath.
>
This sounds like the solution for now, until we can sort out #2
btw -- speaking of class loader issues, I've started investigating the
NodeImpl/class loader issue on the UserInfoTest portlet (logged on)
Tried a number of different combinations of moving around jars from the
webapp to shared/lib.
Not much luck there.
Then I tried infusing the class path in JetspeedContainerServlet ... no
success there either
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: [J2] JAAS Authentication on Tomcat 5 problem
Posted by David Le Strat <dl...@yahoo.com>.
Ate,
See comments below.
>
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26475
>
> This issue exactly describes our problem.
> But, Remy Maucherat, one of the lead developers,
> simply didn't find the
> issue a problem (2004-01-27 23:31):
> "Obviously, the realm is a server component. As a
> result, all its
> dependent classes must reside in the server
> classloader. I do not see
> anything wrong with this."
Right, so if you want to use any kind of persistence
layer, where do you put your persistence components,
in the server classloader? The example you give with
OJB is a good one...
> As far as I can see there are three possible
> solutions:
> 1) Remodel Jetspeed in such a way that the
> RdbmsLoginModule can be used
> from the Tomcat 5 server classpath. I guess this
> will take a lot of work
> but I'm not the designer of the security component
> so maybe others see a
> short way out?
If we were to redesign the RdbmsLoginModule, we would
still need persistence wouldn't we? Would we end up
using straight JDBC (for instance) and become database
bound! Doesn't make much sense to me.
>
> 2) Try to convince the Tomcat crew to revert to the
> old Tomcat 4
> behavior. Maybe conditionally with an additional
> realm parameter?
> I have a gut feeling they are not open to this but
> maybe Jetspeed is
> important enough to make a difference???
Well, I wouldn't get my hopes up on this one but it
does not hurt to try. Anyone knows some of the Tomcat
developers? An intelligent argumentation may be able
to convince them.
>
> 3) Create an extended JAASRealm implementation or
> patch the current one
> without the new Tomcat 5 ContextClassLoader
> problems. This would be a
> short and simple solution (I tried it out: 5 minutes
> work) but it
> creates a dependency on the current Tomcat 5
> implementation and requires
> putting the hacked/extended class in the server
> classpath.
This is the solution I prefer so far.
Regards,
David.
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org