You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Brian Stansberry <br...@wanconcepts.com> on 2003/12/09 07:56:13 UTC
Re: Tomcat authorization handling seems not to function
according to Servlet 2.4 Spec
At 10:03 PM 12/8/2003 -0800, you wrote:
>The decision on whether to change the Realm interface, or
>move the header processing to AuthenticatorBase is still open.
So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms....
Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest.
Brian Stansberry
WAN Concepts, Inc.
www.wanconcepts.com
Tel: (510) 894-0114 x 116
Fax: (510) 797-3005
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
Posted by Remy Maucherat <re...@apache.org>.
Brian Stansberry wrote:
> At 10:03 PM 12/8/2003 -0800, you wrote:
>
>> The decision on whether to change the Realm interface, or move the
>> header processing to AuthenticatorBase is still open.
>
> So soon after such a major release it seems foolhardy to bring this
> up, but Phillipe's post seems to have opened a can of worms....
>
> Are there any plans to do anything about JSR-115? As it's part of
> the J2EE 1.4 spec, I would think that for a compliant appserver to
> embed Tomcat (any others besides JBoss??), Tomcat would need to
> comply. I bring this up because if there is consideration of API
> changes to deal w/ the Servlet 2.4 authorization handling, it might
> be a good time to look into it. I'd be happy to help in such an
> effort if there is any interest.
I'll be looking into this. I don't know yet if the web related parts
belong more to the appserver (JBoss), or more to the servlet container.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
Posted by Remy Maucherat <re...@apache.org>.
Jeanfrancois Arcand wrote:
> Remy Maucherat wrote:
>
>> Jeanfrancois Arcand wrote:
>>>
>>> Brian Stansberry wrote:
>>>
>>>> At 10:03 PM 12/8/2003 -0800, you wrote:
>>>>
>>>>> The decision on whether to change the Realm interface, or
>>>>> move the header processing to AuthenticatorBase is still open.
>>>>
>>>> So soon after such a major release it seems foolhardy to bring this
>>>> up, but Phillipe's post seems to have opened a can of worms....
>>>>
>>>> Are there any plans to do anything about JSR-115? As it's part of
>>>> the J2EE 1.4 spec, I would think that for a compliant appserver to
>>>> embed Tomcat (any others besides JBoss??), Tomcat would need to
>>>> comply. I bring this up because if there is consideration of API
>>>> changes to deal w/ the Servlet 2.4 authorization handling, it might
>>>> be a good time to look into it. I'd be happy to help in such an
>>>> effort if there is any interest.
>>>
>>> All you have to do to comply with jsr115 is to extends RealmBase and
>>> override:
>>>
>>> - hasUserDataPermission
>>> - hasRole
>>> - hasResourcePermission
>>> - findSecurityConstraint
>>>
>>> A couple of months ago (search the tomcat-dev list) we have discussed
>>> the possibility of implementing jsr115 directly into Tomcat. Still on
>>> my plate (don't know when)....
>>>
>>> J2EE 1.4 RI contains Tomcat 5 "powered by" jsr 115. The problem with
>>> jsr115 is you have to run under a Security Manager, and this is for
>>> sure slower than the current "native" implementation.
>>
>> I think you'll have an opportunity to make your changes if you want
>> to, since we'll have some refactoring to do on the realm before the
>> next stable 5.0.x release occurs.
>
> That's a pretty good opportunity....For reference, here is the link to
> my original proposal
>
> http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg39894.html
>
> My original idea was to remove the current Authenticator <-> Realm
> dependency. Currently, the Realm is doing Authorization and
> Authentication, which I think should be splitted.
>
>> Did you do benches ?
>> Comparing (4.1.x) vs (5.0.x) vs (5.0.x + sec manager), for example.
>>
>> I wouldn't be surprised if the last one benches as well as the first
>> one (which would be really cool).
>
> Not yet, but it is one of the thing I want to do when I've found spare
> time. For sure (5.0.x + sec manager) is faster than (5.0.x + sec manager
> + jsr115) since with 115, the policy provider is called everytime
> hasUser/ResourcePermission are called, and this approach cannot beat the
> current way of doing.
>
> On the original topic, I think I've missed the spec change from pfd3 and
> fcs. I was under the wrong impression that Bill's last changes on the
> RealmAdapter was related to that changes (I was completely wrong). I
> will try to find the reason whythe change was make...
>
> Now the only problem I'm seeing with Phillipe's work is Strings are used
> everywhere and that may have a performance impact. It may be time to
> start using MessageByte.....
That's the idea. If you're inside the container and you consider it a
critical section for whatever reason, then strings are really evil, and
you should use MessageBytes instead (or even ByteChunks if manipulating
header values) ;-)
I see supporing JSR 115 would be good, but making it disabled by default
when there's a security manager would be the most reasonable.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
Posted by Remy Maucherat <re...@apache.org>.
Jeanfrancois Arcand wrote:
>> Now the big question: do we plan to have that JSR 115 support for the
>> next stable release, or is it too early to have it done ?
>
> Since there is still some gray area I need to think of, I would say no.
> But let me think of it :-)
Well, since we don't have any really urgent issues to fix in 5.0.16
(ahhhh, a quality initial release at last), we don't have to release
5.0.17 within two weeks ;-)
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according to
Servlet 2.4 Spec
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Remy Maucherat wrote:
> Jeanfrancois Arcand wrote:
>
>>> Mmm, ok. I'm not quite following very well, since I didn't read the
>>> spec yet ;-) If I understand, you would implement something which
>>> would work as the JSR 115 security policy provider, but (likely :) )
>>> simpler ?
>>
>>
>> Yes, as a first steps. It will also works without a security manager
>> (Costin was asking for that if I remember correctly). It is a
>> required steps to supports jsr115 anyway.
>
>
> Good :)
>
>>> Would it be equivalent performance wise to the current solution if
>>> JSR 115 support is disabled ?
>>
>>
>> Yes, it could be if ByteChunk/MessageByte etc. are used ( can be
>> slower also, probably the first implementation will be slower ). One
>> way to do that will be to create our own Permission collections that
>> re-use what we already have. I still have to think of it...I would
>> like to do something similar to what you have done with the Mapper (
>> avoiding String etc.)
>
>
> Depending on what you're trying to match and if you can have multiple
> matches, String.regionMatcher (currently used) works good, since it
> uses the internal char array of the two String objects. It's the same
> as using a CharChunk, obviously.
>
> Very good plan overall.
>
> Now the big question: do we plan to have that JSR 115 support for the
> next stable release, or is it too early to have it done ?
Since there is still some gray area I need to think of, I would say no.
But let me think of it :-)
-- Jeanfrancois
>
> Rémy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
Posted by Remy Maucherat <re...@apache.org>.
Jeanfrancois Arcand wrote:
>> Mmm, ok. I'm not quite following very well, since I didn't read the
>> spec yet ;-) If I understand, you would implement something which
>> would work as the JSR 115 security policy provider, but (likely :) )
>> simpler ?
>
> Yes, as a first steps. It will also works without a security manager
> (Costin was asking for that if I remember correctly). It is a required
> steps to supports jsr115 anyway.
Good :)
>> Would it be equivalent performance wise to the current solution if JSR
>> 115 support is disabled ?
>
> Yes, it could be if ByteChunk/MessageByte etc. are used ( can be slower
> also, probably the first implementation will be slower ). One way to do
> that will be to create our own Permission collections that re-use what
> we already have. I still have to think of it...I would like to do
> something similar to what you have done with the Mapper ( avoiding
> String etc.)
Depending on what you're trying to match and if you can have multiple
matches, String.regionMatcher (currently used) works good, since it uses
the internal char array of the two String objects. It's the same as
using a CharChunk, obviously.
Very good plan overall.
Now the big question: do we plan to have that JSR 115 support for the
next stable release, or is it too early to have it done ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according to
Servlet 2.4 Spec
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Remy Maucherat wrote:
> Jeanfrancois Arcand wrote:
>
>> Zzzzoui :-)
>>
>> I will do that (on my own time unfortunalty, so may take a couple of
>> weeks....)
>>
>> First, it would be easier just to convert the web.xml into security
>> permissions, and to keep internal collections, for unchecked,
>> excluded, and role permissions than to do all this constraint
>> processing work. A simple call to collection.implies, could then be
>> used for the decision logic (which would be just one step short of
>> integrating with an external jsr 115 policy provider).
>>
>> Then a full jsr115 implementation can happen once I'm sure step one
>> works :-)
>
>
> Mmm, ok. I'm not quite following very well, since I didn't read the
> spec yet ;-) If I understand, you would implement something which
> would work as the JSR 115 security policy provider, but (likely :) )
> simpler ?
Yes, as a first steps. It will also works without a security manager
(Costin was asking for that if I remember correctly). It is a required
steps to supports jsr115 anyway.
> Would it be equivalent performance wise to the current solution if JSR
> 115 support is disabled ?
Yes, it could be if ByteChunk/MessageByte etc. are used ( can be slower
also, probably the first implementation will be slower ). One way to do
that will be to create our own Permission collections that re-use what
we already have. I still have to think of it...I would like to do
something similar to what you have done with the Mapper ( avoiding
String etc.)
-- Jeanfrancois
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
Posted by Remy Maucherat <re...@apache.org>.
Jeanfrancois Arcand wrote:
> Zzzzoui :-)
>
> I will do that (on my own time unfortunalty, so may take a couple of
> weeks....)
>
> First, it would be easier just to convert the web.xml into security
> permissions, and to keep internal collections, for unchecked, excluded,
> and role permissions than to do all this constraint processing work. A
> simple call to collection.implies, could then be used for the decision
> logic (which would be just one step short of integrating with an
> external jsr 115 policy provider).
>
> Then a full jsr115 implementation can happen once I'm sure step one
> works :-)
Mmm, ok. I'm not quite following very well, since I didn't read the spec
yet ;-) If I understand, you would implement something which would work
as the JSR 115 security policy provider, but (likely :) ) simpler ?
Would it be equivalent performance wise to the current solution if JSR
115 support is disabled ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according to
Servlet 2.4 Spec
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Remy Maucherat wrote:
> Jeanfrancois Arcand wrote:
>
>> Not yet, but it is one of the thing I want to do when I've found
>> spare time. For sure (5.0.x + sec manager) is faster than (5.0.x +
>> sec manager + jsr115) since with 115, the policy provider is called
>> everytime hasUser/ResourcePermission are called, and this approach
>> cannot beat the current way of doing.
>>
>> On the original topic, I think I've missed the spec change from pfd3
>> and fcs. I was under the wrong impression that Bill's last changes on
>> the RealmAdapter was related to that changes (I was completely
>> wrong). I will try to find the reason whythe change was make...
>>
>> Now the only problem I'm seeing with Phillipe's work is Strings are
>> used everywhere and that may have a performance impact. It may be
>> time to start using MessageByte.....
>
>
> So, now that the problems have been resolved (even the performance
> ones :) ), can you plan to add your JSR 115 (with a flag somewhere to
> enable it, likely on the realm :) ) stuff on top of Bill's stuff ?
Zzzzoui :-)
I will do that (on my own time unfortunalty, so may take a couple of
weeks....)
First, it would be easier just to convert the web.xml into security
permissions, and to keep internal collections, for unchecked, excluded,
and role permissions than to do all this constraint processing work. A
simple call to collection.implies, could then be used for the decision
logic (which would be just one step short of integrating with an
external jsr 115 policy provider).
Then a full jsr115 implementation can happen once I'm sure step one
works :-)
-- Jeanfrancois
>
> Rémy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
Posted by Remy Maucherat <re...@apache.org>.
Jeanfrancois Arcand wrote:
> Not yet, but it is one of the thing I want to do when I've found spare
> time. For sure (5.0.x + sec manager) is faster than (5.0.x + sec manager
> + jsr115) since with 115, the policy provider is called everytime
> hasUser/ResourcePermission are called, and this approach cannot beat the
> current way of doing.
>
> On the original topic, I think I've missed the spec change from pfd3 and
> fcs. I was under the wrong impression that Bill's last changes on the
> RealmAdapter was related to that changes (I was completely wrong). I
> will try to find the reason whythe change was make...
>
> Now the only problem I'm seeing with Phillipe's work is Strings are used
> everywhere and that may have a performance impact. It may be time to
> start using MessageByte.....
So, now that the problems have been resolved (even the performance ones
:) ), can you plan to add your JSR 115 (with a flag somewhere to enable
it, likely on the realm :) ) stuff on top of Bill's stuff ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according to
Servlet 2.4 Spec
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Remy Maucherat wrote:
> Jeanfrancois Arcand wrote:
>
>>
>>
>> Brian Stansberry wrote:
>>
>>> At 10:03 PM 12/8/2003 -0800, you wrote:
>>>
>>>
>>>> The decision on whether to change the Realm interface, or
>>>> move the header processing to AuthenticatorBase is still open.
>>>>
>>>
>>>
>>>
>>> So soon after such a major release it seems foolhardy to bring this
>>> up, but Phillipe's post seems to have opened a can of worms....
>>>
>>> Are there any plans to do anything about JSR-115? As it's part of
>>> the J2EE 1.4 spec, I would think that for a compliant appserver to
>>> embed Tomcat (any others besides JBoss??), Tomcat would need to
>>> comply. I bring this up because if there is consideration of API
>>> changes to deal w/ the Servlet 2.4 authorization handling, it might
>>> be a good time to look into it. I'd be happy to help in such an
>>> effort if there is any interest.
>>>
>>
>> All you have to do to comply with jsr115 is to extends RealmBase and
>> override:
>>
>> - hasUserDataPermission
>> - hasRole
>> - hasResourcePermission
>> - findSecurityConstraint
>>
>> A couple of months ago (search the tomcat-dev list) we have discussed
>> the possibility of implementing jsr115 directly into Tomcat. Still on
>> my plate (don't know when)....
>>
>> J2EE 1.4 RI contains Tomcat 5 "powered by" jsr 115. The problem with
>> jsr115 is you have to run under a Security Manager, and this is for
>> sure slower than the current "native" implementation.
>
>
> I think you'll have an opportunity to make your changes if you want
> to, since we'll have some refactoring to do on the realm before the
> next stable 5.0.x release occurs.
That's a pretty good opportunity....For reference, here is the link to
my original proposal
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg39894.html
My original idea was to remove the current Authenticator <-> Realm
dependency. Currently, the Realm is doing Authorization and
Authentication, which I think should be splitted.
>
> Did you do benches ?
> Comparing (4.1.x) vs (5.0.x) vs (5.0.x + sec manager), for example.
>
> I wouldn't be surprised if the last one benches as well as the first
> one (which would be really cool).
Not yet, but it is one of the thing I want to do when I've found spare
time. For sure (5.0.x + sec manager) is faster than (5.0.x + sec manager
+ jsr115) since with 115, the policy provider is called everytime
hasUser/ResourcePermission are called, and this approach cannot beat the
current way of doing.
On the original topic, I think I've missed the spec change from pfd3 and
fcs. I was under the wrong impression that Bill's last changes on the
RealmAdapter was related to that changes (I was completely wrong). I
will try to find the reason whythe change was make...
Now the only problem I'm seeing with Phillipe's work is Strings are used
everywhere and that may have a performance impact. It may be time to
start using MessageByte.....
-- Jeanfrancois
>
> Rémy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according
to Servlet 2.4 Spec
Posted by Remy Maucherat <re...@apache.org>.
Jeanfrancois Arcand wrote:
>
>
> Brian Stansberry wrote:
>
>> At 10:03 PM 12/8/2003 -0800, you wrote:
>>
>>
>>> The decision on whether to change the Realm interface, or
>>> move the header processing to AuthenticatorBase is still open.
>>>
>>
>>
>> So soon after such a major release it seems foolhardy to bring this
>> up, but Phillipe's post seems to have opened a can of worms....
>>
>> Are there any plans to do anything about JSR-115? As it's part of the
>> J2EE 1.4 spec, I would think that for a compliant appserver to embed
>> Tomcat (any others besides JBoss??), Tomcat would need to comply. I
>> bring this up because if there is consideration of API changes to deal
>> w/ the Servlet 2.4 authorization handling, it might be a good time to
>> look into it. I'd be happy to help in such an effort if there is any
>> interest.
>>
> All you have to do to comply with jsr115 is to extends RealmBase and
> override:
>
> - hasUserDataPermission
> - hasRole
> - hasResourcePermission
> - findSecurityConstraint
>
> A couple of months ago (search the tomcat-dev list) we have discussed
> the possibility of implementing jsr115 directly into Tomcat. Still on my
> plate (don't know when)....
>
> J2EE 1.4 RI contains Tomcat 5 "powered by" jsr 115. The problem with
> jsr115 is you have to run under a Security Manager, and this is for sure
> slower than the current "native" implementation.
I think you'll have an opportunity to make your changes if you want to,
since we'll have some refactoring to do on the realm before the next
stable 5.0.x release occurs.
Did you do benches ?
Comparing (4.1.x) vs (5.0.x) vs (5.0.x + sec manager), for example.
I wouldn't be surprised if the last one benches as well as the first one
(which would be really cool).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Tomcat authorization handling seems not to function according to
Servlet 2.4 Spec
Posted by Jeanfrancois Arcand <jf...@apache.org>.
Brian Stansberry wrote:
>At 10:03 PM 12/8/2003 -0800, you wrote:
>
>
>>The decision on whether to change the Realm interface, or
>>move the header processing to AuthenticatorBase is still open.
>>
>>
>
>So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms....
>
>Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest.
>
>
All you have to do to comply with jsr115 is to extends RealmBase and
override:
- hasUserDataPermission
- hasRole
- hasResourcePermission
- findSecurityConstraint
A couple of months ago (search the tomcat-dev list) we have discussed
the possibility of implementing jsr115 directly into Tomcat. Still on my
plate (don't know when)....
J2EE 1.4 RI contains Tomcat 5 "powered by" jsr 115. The problem with
jsr115 is you have to run under a Security Manager, and this is for sure
slower than the current "native" implementation.
-- Jeanfrancois
>
>Brian Stansberry
>WAN Concepts, Inc.
>www.wanconcepts.com
>Tel: (510) 894-0114 x 116
>Fax: (510) 797-3005
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org