You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2010/03/31 00:05:04 UTC
Tomcat 7 and securityfilter [or A Love Letter to markt]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
One of the major architectural changes I've heard about coming in Tomcat
7 is the removal of the Valve interface in favor of using the standard
javax.servlet.Filter interface.
IIRC, the current implementation of container-managed authentication and
authorization is done using a Valve (or series of Valves).
If Tomcat is moving to Filters rather than Valves, does that mean that
Tomcat authentication will be done using Filters, or is there some other
strategy in the works?
I ask because a Filter-based authentication and authorization strategy
would duplicate the work of securityfilter (and probably be more
up-to-date, but that's beside the point).
I would actually prefer that Tomcat go with a Filter-based
authentication strategy because of the flexibility which can be achieved
by intercepting the call chain without having to dive into the internals
of Tomcat.
What's the plan for T7-auth?
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuydZAACgkQ9CaO5/Lv0PArvgCgnoUpBYS4i3HuCTSTrqiOLLkQ
RMoAnj96FWY4EzzVNQxeTVhqsuvUinz6
=sB2s
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat 7 and securityfilter [or A Love Letter to markt]
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: peter.crowther3@googlemail.com
> [mailto:peter.crowther3@googlemail.com] On Behalf Of Peter Crowther
> Subject: Re: Tomcat 7 and securityfilter [or A Love Letter to markt]
>
> "Baldrick, what starts with 'Come here!' and ends with 'Ouch'?"
> "Dunno"
> "Baldrick, come here!"
> <slap>
> "Ouch!"
>
> ... or was there a different moment you had in mind, Mark? :-)
It's just such a cunning plan...
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 and securityfilter [or A Love Letter to markt]
Posted by Peter Crowther <pe...@melandra.com>.
On 30 March 2010 23:50, Mark Thomas <ma...@apache.org> wrote:
> I feel a Baldrick[1] moment coming on.
>
"Baldrick, what starts with 'Come here!' and ends with 'Ouch'?"
"Dunno"
"Baldrick, come here!"
<slap>
"Ouch!"
... or was there a different moment you had in mind, Mark? :-)
- Peter
Re: Tomcat 7 and securityfilter [or A Love Letter to markt]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 3/31/2010 10:00 AM, Pid wrote:
> I'd be interested in (over)hearing that conversation, my specific
> interest being related to OAuth.
Sure. Since the Tomcat 5.x Realms broke sf's ability to use the Tomcat
Realms, I've found myself having to provide sample Realms (so far only
DataSourceRealm because it's the only one worth using... okay, maybe
JNDIRealm but I haven't written one of those yet) to users. Give that,
it would be nice to create a bunch of custom Realms (I hate that term,
though... it's really an Authenticator despite Tomcat's insistence that
gathering credentials is done by an "Authenticator") that will allow
users to connect to often-used authentication services like OpenID, and,
I guess, Oauth (which I had never heard of until just now).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuzWU8ACgkQ9CaO5/Lv0PCyzQCeIGiVWHP1Tk0tODePfKeuisu0
y9wAnAm3LK/tmxK+YHOhHQlD8V9Yru5n
=dVyU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 and securityfilter [or A Love Letter to markt]
Posted by Pid <pi...@pidster.com>.
On 31/03/2010 14:44, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark,
>
> On 3/30/2010 6:50 PM, Mark Thomas wrote:
>> On 30/03/2010 23:05, Christopher Schultz wrote:
>>> If Tomcat is moving to Filters rather than Valves, does that mean that
>>> Tomcat authentication will be done using Filters, or is there some other
>>> strategy in the works?
>>
>> The strategy is to move to filters. The tactics are somewhat lacking in
>> detail.
>
> Understood.
>
>>> I ask because a Filter-based authentication and authorization strategy
>>> would duplicate the work of securityfilter (and probably be more
>>> up-to-date, but that's beside the point).
>>
>> Potentially. I see security filter is essentially Apache licensed. Hmm.
>> I feel a Baldrick[1] moment coming on.
>
> Well, I'd have to talk to Max Cooper, the original owner of the project,
> but I suspect that we wouldn't mind if Tomcat just annexed the the sf
> code and eviscerated it as necessary.
>
> The cvs head is very stable, but I'm not happy with a lot of the stuff
> that's in there, such as the URL pattern matching code and the lack of
> extensibility in general (sure, you can plug-in your own Realms, but you
> can't really change the behavior of the Filter itself without just
> copying it and re-writing whatever you need).
>
> I'd be happy to have an off-list conversation about the current status,
> my thoughts on the possible direction(s) of the code, etc.
>
>>> I would actually prefer that Tomcat go with a Filter-based
>>> authentication strategy because of the flexibility which can be achieved
>>> by intercepting the call chain without having to dive into the internals
>>> of Tomcat.
>>>
>>> What's the plan for T7-auth?
>>
>> At the minute, implement JSR-196 once the Servlet 3.0 is completed (it
>> is very close) with a valve to filter move for authentication probably
>> pushed back to Tomcat 8.
>>
>> SecurityFilter is an obvious starting point. How do you feel about
>> contributing some patches with the aim of merging the SecurityFilter
>> code into Tomcat? Is it feasible to do this incrementally or would it
>> need to be in one big patch?
>
> Good question: Tomcat does a lot of stuff that sf doesn't. For example,
> we don't do CLIENT-AUTH, we don't do SSO, and the code hasn't been
> tested against the latest servlet spec (though little has changed in the
> last few versions relative to authentication and authorization). On the
> other hand, sf supports a lot of stuff Tomcat doesn't: "remember me",
> explicit after-login forward/redirect, pass-through request parameters
> to an explicit forward/redirect, drive-by authentication (i.e. no
> previous request for a protected resource is required in order to
> successfully login), and a Realm interface that is flexible enough to
> allow a Realm implementation to do all kinds of wonderful things like
> log the IP address of a failed login (because the Request object is
> passed-into the authentication method).
>
> So, I think the first thing to do would be to identify which feature set
> you want to target, and then decide if the code in sf is good enough
> and/or compatible for Tomcat's purposes.
>
> I'm not sure about the ASF's desires, but moving sf into the ASF proper
> and having Tomcat simply use it as its authentication and authorization
> strategy would be the best result for everyone: I would (probably) get
> more help with the code, Tomcat gets a shot in the arm in terms of
> functionality, and users retain the ability to use the library outside
> the context of Tomcat if they want to.
>
> Again, I'd be happy to talk off-list if you'd like to discuss this further.
I'd be interested in (over)hearing that conversation, my specific
interest being related to OAuth.
p
> Thanks,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkuzUasACgkQ9CaO5/Lv0PCUkgCeLmLSEm6lR6yfNDmTmIOATymz
> tJwAn3Jt6rrdzu7T8UrjPmAc69J2WBSt
> =wF6E
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> 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: Tomcat 7 and securityfilter [or A Love Letter to markt]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 3/31/2010 10:06 AM, Mark Thomas wrote:
> This is probably now a discussion for the dev list.
Okay, I'll join the dev list and post something soon.
> Note that any decision to move the code to the ASF would mean having to
> go via the incubator [1].
No problem: this thing is going to have to undergo lots of incubation
before it will be useful, anyway :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuzWZsACgkQ9CaO5/Lv0PBAhgCdGuuniEDpXBP0mQKbTX7czPno
kQ4Anj84wj7iSkLhtF0ejUNxRghxAEkq
=hMAe
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 and securityfilter [or A Love Letter to markt]
Posted by Mladen Turk <mt...@apache.org>.
On 03/31/2010 04:06 PM, Mark Thomas wrote:
> On 31/03/2010 14:44, Christopher Schultz wrote:
>
> Note that any decision to move the code to the ASF would mean having to
> go via the incubator [1].
>
Unless it gets part of some TLP project.
If it's a standalone component like, it can go to the Commons.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 and securityfilter [or A Love Letter to markt]
Posted by Mark Thomas <ma...@apache.org>.
On 31/03/2010 14:44, Christopher Schultz wrote:
> I'm not sure about the ASF's desires, but moving sf into the ASF proper
> and having Tomcat simply use it as its authentication and authorization
> strategy would be the best result for everyone: I would (probably) get
> more help with the code, Tomcat gets a shot in the arm in terms of
> functionality, and users retain the ability to use the library outside
> the context of Tomcat if they want to.
>
> Again, I'd be happy to talk off-list if you'd like to discuss this further.
I think this is a great idea. I'm not so sure about wholesale
replacement but bring together the best of both code bases while keeping
security filter as a separate module for those that want it to use it
elsewhere sounds like a win-win to me.
This is probably now a discussion for the dev list.
Note that any decision to move the code to the ASF would mean having to
go via the incubator [1].
Mark
[1] http://incubator.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 and securityfilter [or A Love Letter to markt]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark,
On 3/30/2010 6:50 PM, Mark Thomas wrote:
> On 30/03/2010 23:05, Christopher Schultz wrote:
>> If Tomcat is moving to Filters rather than Valves, does that mean that
>> Tomcat authentication will be done using Filters, or is there some other
>> strategy in the works?
>
> The strategy is to move to filters. The tactics are somewhat lacking in
> detail.
Understood.
>> I ask because a Filter-based authentication and authorization strategy
>> would duplicate the work of securityfilter (and probably be more
>> up-to-date, but that's beside the point).
>
> Potentially. I see security filter is essentially Apache licensed. Hmm.
> I feel a Baldrick[1] moment coming on.
Well, I'd have to talk to Max Cooper, the original owner of the project,
but I suspect that we wouldn't mind if Tomcat just annexed the the sf
code and eviscerated it as necessary.
The cvs head is very stable, but I'm not happy with a lot of the stuff
that's in there, such as the URL pattern matching code and the lack of
extensibility in general (sure, you can plug-in your own Realms, but you
can't really change the behavior of the Filter itself without just
copying it and re-writing whatever you need).
I'd be happy to have an off-list conversation about the current status,
my thoughts on the possible direction(s) of the code, etc.
>> I would actually prefer that Tomcat go with a Filter-based
>> authentication strategy because of the flexibility which can be achieved
>> by intercepting the call chain without having to dive into the internals
>> of Tomcat.
>>
>> What's the plan for T7-auth?
>
> At the minute, implement JSR-196 once the Servlet 3.0 is completed (it
> is very close) with a valve to filter move for authentication probably
> pushed back to Tomcat 8.
>
> SecurityFilter is an obvious starting point. How do you feel about
> contributing some patches with the aim of merging the SecurityFilter
> code into Tomcat? Is it feasible to do this incrementally or would it
> need to be in one big patch?
Good question: Tomcat does a lot of stuff that sf doesn't. For example,
we don't do CLIENT-AUTH, we don't do SSO, and the code hasn't been
tested against the latest servlet spec (though little has changed in the
last few versions relative to authentication and authorization). On the
other hand, sf supports a lot of stuff Tomcat doesn't: "remember me",
explicit after-login forward/redirect, pass-through request parameters
to an explicit forward/redirect, drive-by authentication (i.e. no
previous request for a protected resource is required in order to
successfully login), and a Realm interface that is flexible enough to
allow a Realm implementation to do all kinds of wonderful things like
log the IP address of a failed login (because the Request object is
passed-into the authentication method).
So, I think the first thing to do would be to identify which feature set
you want to target, and then decide if the code in sf is good enough
and/or compatible for Tomcat's purposes.
I'm not sure about the ASF's desires, but moving sf into the ASF proper
and having Tomcat simply use it as its authentication and authorization
strategy would be the best result for everyone: I would (probably) get
more help with the code, Tomcat gets a shot in the arm in terms of
functionality, and users retain the ability to use the library outside
the context of Tomcat if they want to.
Again, I'd be happy to talk off-list if you'd like to discuss this further.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuzUasACgkQ9CaO5/Lv0PCUkgCeLmLSEm6lR6yfNDmTmIOATymz
tJwAn3Jt6rrdzu7T8UrjPmAc69J2WBSt
=wF6E
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 7 and securityfilter [or A Love Letter to markt]
Posted by Mark Thomas <ma...@apache.org>.
On 30/03/2010 23:05, Christopher Schultz wrote:
> All,
>
> One of the major architectural changes I've heard about coming in Tomcat
> 7 is the removal of the Valve interface in favor of using the standard
> javax.servlet.Filter interface.
Getting Tomcat 7 to move from Valves towards Filters is one of my pet
projects. There is still a long way to go and it isn't at the top of my
todo list.
> IIRC, the current implementation of container-managed authentication and
> authorization is done using a Valve (or series of Valves).
It is currently a single Valve.
> If Tomcat is moving to Filters rather than Valves, does that mean that
> Tomcat authentication will be done using Filters, or is there some other
> strategy in the works?
The strategy is to move to filters. The tactics are somewhat lacking in
detail.
> I ask because a Filter-based authentication and authorization strategy
> would duplicate the work of securityfilter (and probably be more
> up-to-date, but that's beside the point).
Potentially. I see security filter is essentially Apache licensed. Hmm.
I feel a Baldrick[1] moment coming on.
> I would actually prefer that Tomcat go with a Filter-based
> authentication strategy because of the flexibility which can be achieved
> by intercepting the call chain without having to dive into the internals
> of Tomcat.
>
> What's the plan for T7-auth?
At the minute, implement JSR-196 once the Servlet 3.0 is completed (it
is very close) with a valve to filter move for authentication probably
pushed back to Tomcat 8.
SecurityFilter is an obvious starting point. How do you feel about
contributing some patches with the aim of merging the SecurityFilter
code into Tomcat? Is it feasible to do this incrementally or would it
need to be in one big patch?
Mark
[1] http://en.wikipedia.org/wiki/Baldrick
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org