You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/06/09 18:15:58 UTC
message/transport level security [Re: SOAP streaming and faults,
security everywhere and performanceimplications [Re: opinion Axis' future
... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Sanjiva Weerawarana wrote:
>"Samuel Meder" <me...@mcs.anl.gov> writes:
>
>
>>I completely agree on Alex's point that security (and other QoS aspects)
>>are very important for us working in the Grid world. It is hard to
>>justify to users that turning on security will cause a 10x slowdown (it
>>is actually even worse with larger payloads) and since grid scenarios
>>are generally multi organization security is a ubiquitous requirement (I
>>would think that the same is true for B2B scenarios).
>>
>>
>
>Of course. However, that's a fundamental issue with XML security
>and not with the WS-* specs in particular. The XML sec stuff is
>defined in terms of DOMs and DOM hash's .. which can be computed
>in a streaming model for many XPaths ..
>
>
hi Sanjiva
i think that it is true for verification but not for signing as you need
to compute signature: you *can* compute it in a streaming fashion but
then you need to put signature in header so you have to buffer whole
stream output (why, oh why, there is no footer element in SOAP ...)
>Furthermore using WS-Security without WS-Secure Conversation is
>retarded (IMO).
>
>
there are many cases to consider and each situation is unique.
WS-SecConv does not buy you much if you do very coarse grained messaging
(only one message sent to service) still the overhead is small enough
that may be doable to do WS-SecConv for every message.
however there is a potential scalability problem as server needs to
remember all those opened sessions so implementation must be very
careful here (we did some testing and in one test setup after a thousand
or so connections server refused to accept any new connections ...)
>In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
>have to be any less performant than any other public key security
>technology IMO for many cases.
>
yes - if we do have better libs to do efficient
streaming/canonicalization/verification/signing and generally avoiding
excessive memory usage.
>There may be degenerate cases where
>it is, but if we can make those rare then we're in business.
>
>
that is still to be seen :)
currently SSL without keep alive (so it does key exchange each time) is
2-5x faster than WS-SecConv after first message (this is just estimate
...) and SSL with keep alive (no key exchange so it is comparable to
session in WS-SecConv) it is faster by *order of magnitude* than
WS-SecConv in what we tested (caveat emperor!)
plus with SSL you can easily by hardware accelerator and load balancers
that will understand SSL it will take some time before WS-SecConv is
real standard and has this kind of support ...
we are going to submit a paper (Satoshi did a great work on this) with
details on tests to Workshop on Grid Computing (Grid 2004) and hope that
it will lead to some discussion and ultimately faster (streaming?) code
in future :)
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: Re: message/transport level security [Re: SOAP streaming and
faults, security everywhere and performanceimplications [Re: opinion Axis'
future ... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Samuel Meder <me...@mcs.anl.gov>.
On Wed, 2004-06-09 at 15:13, Davanum Srinivas wrote:
> I just browsed their code....No, they don't have WS-SecConv support as
> far as i can tell.
We ended up implementing our own equivalent (for timing and other
reasons). So no, we don't have WS-SecConv. From a protocol performance
perspective the issues should be exactly the same though.
/Sam
>
> -- dims
>
> On Wed, 09 Jun 2004 15:10:37 -0500, Aleksander Slominski
> <as...@cs.indiana.edu> wrote:
> >
> > Davanum Srinivas wrote:
> >
> > >Do you have a WS-SecConv impl? (open source?)
> > >
> > >
> > we looked on Globus Toolkit 3.2 which i think is an early/prototype
> > implementation and i am not sure about its long term status.
> >
> > i am sure that Globus guys will have more definitve answer to that :)
> >
> > thanks,
> >
> > alek
> >
> >
> >
> > >On Wed, 09 Jun 2004 11:15:58 -0500, Aleksander Slominski
> > ><as...@cs.indiana.edu> wrote:
> > >
> > >
> > >>Sanjiva Weerawarana wrote:
> > >>
> > >>
> > >>
> > >>>"Samuel Meder" <me...@mcs.anl.gov> writes:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>I completely agree on Alex's point that security (and other QoS aspects)
> > >>>>are very important for us working in the Grid world. It is hard to
> > >>>>justify to users that turning on security will cause a 10x slowdown (it
> > >>>>is actually even worse with larger payloads) and since grid scenarios
> > >>>>are generally multi organization security is a ubiquitous requirement (I
> > >>>>would think that the same is true for B2B scenarios).
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>Of course. However, that's a fundamental issue with XML security
> > >>>and not with the WS-* specs in particular. The XML sec stuff is
> > >>>defined in terms of DOMs and DOM hash's .. which can be computed
> > >>>in a streaming model for many XPaths ..
> > >>>
> > >>>
> > >>>
> > >>>
> > >>hi Sanjiva
> > >>
> > >>i think that it is true for verification but not for signing as you need
> > >>to compute signature: you *can* compute it in a streaming fashion but
> > >>then you need to put signature in header so you have to buffer whole
> > >>stream output (why, oh why, there is no footer element in SOAP ...)
> > >>
> > >>
> > >>
> > >>>Furthermore using WS-Security without WS-Secure Conversation is
> > >>>retarded (IMO).
> > >>>
> > >>>
> > >>>
> > >>>
> > >>there are many cases to consider and each situation is unique.
> > >>
> > >>WS-SecConv does not buy you much if you do very coarse grained messaging
> > >>(only one message sent to service) still the overhead is small enough
> > >>that may be doable to do WS-SecConv for every message.
> > >>
> > >>however there is a potential scalability problem as server needs to
> > >>remember all those opened sessions so implementation must be very
> > >>careful here (we did some testing and in one test setup after a thousand
> > >>or so connections server refused to accept any new connections ...)
> > >>
> > >>
> > >>
> > >>>In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
> > >>>have to be any less performant than any other public key security
> > >>>technology IMO for many cases.
> > >>>
> > >>>
> > >>>
> > >>yes - if we do have better libs to do efficient
> > >>streaming/canonicalization/verification/signing and generally avoiding
> > >>excessive memory usage.
> > >>
> > >>
> > >>
> > >>>There may be degenerate cases where
> > >>>it is, but if we can make those rare then we're in business.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>that is still to be seen :)
> > >>
> > >>currently SSL without keep alive (so it does key exchange each time) is
> > >>2-5x faster than WS-SecConv after first message (this is just estimate
> > >>...) and SSL with keep alive (no key exchange so it is comparable to
> > >>session in WS-SecConv) it is faster by *order of magnitude* than
> > >>WS-SecConv in what we tested (caveat emperor!)
> > >>
> > >>plus with SSL you can easily by hardware accelerator and load balancers
> > >>that will understand SSL it will take some time before WS-SecConv is
> > >>real standard and has this kind of support ...
> > >>
> > >>we are going to submit a paper (Satoshi did a great work on this) with
> > >>details on tests to Workshop on Grid Computing (Grid 2004) and hope that
> > >>it will lead to some discussion and ultimately faster (streaming?) code
> > >>in future :)
> > >>
> > >>thanks,
> > >>
> > >>alek
> > >>
> > >>--
> > >>The best way to predict the future is to invent it - Alan Kay
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> >
> >
--
Sam Meder <me...@mcs.anl.gov>
The Globus Alliance - University of Chicago
630-252-1752
Re: Re: message/transport level security [Re: SOAP streaming and faults, security everywhere and performanceimplications [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Davanum Srinivas <da...@gmail.com>.
I just browsed their code....No, they don't have WS-SecConv support as
far as i can tell.
-- dims
On Wed, 09 Jun 2004 15:10:37 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
>
> Davanum Srinivas wrote:
>
> >Do you have a WS-SecConv impl? (open source?)
> >
> >
> we looked on Globus Toolkit 3.2 which i think is an early/prototype
> implementation and i am not sure about its long term status.
>
> i am sure that Globus guys will have more definitve answer to that :)
>
> thanks,
>
> alek
>
>
>
> >On Wed, 09 Jun 2004 11:15:58 -0500, Aleksander Slominski
> ><as...@cs.indiana.edu> wrote:
> >
> >
> >>Sanjiva Weerawarana wrote:
> >>
> >>
> >>
> >>>"Samuel Meder" <me...@mcs.anl.gov> writes:
> >>>
> >>>
> >>>
> >>>
> >>>>I completely agree on Alex's point that security (and other QoS aspects)
> >>>>are very important for us working in the Grid world. It is hard to
> >>>>justify to users that turning on security will cause a 10x slowdown (it
> >>>>is actually even worse with larger payloads) and since grid scenarios
> >>>>are generally multi organization security is a ubiquitous requirement (I
> >>>>would think that the same is true for B2B scenarios).
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Of course. However, that's a fundamental issue with XML security
> >>>and not with the WS-* specs in particular. The XML sec stuff is
> >>>defined in terms of DOMs and DOM hash's .. which can be computed
> >>>in a streaming model for many XPaths ..
> >>>
> >>>
> >>>
> >>>
> >>hi Sanjiva
> >>
> >>i think that it is true for verification but not for signing as you need
> >>to compute signature: you *can* compute it in a streaming fashion but
> >>then you need to put signature in header so you have to buffer whole
> >>stream output (why, oh why, there is no footer element in SOAP ...)
> >>
> >>
> >>
> >>>Furthermore using WS-Security without WS-Secure Conversation is
> >>>retarded (IMO).
> >>>
> >>>
> >>>
> >>>
> >>there are many cases to consider and each situation is unique.
> >>
> >>WS-SecConv does not buy you much if you do very coarse grained messaging
> >>(only one message sent to service) still the overhead is small enough
> >>that may be doable to do WS-SecConv for every message.
> >>
> >>however there is a potential scalability problem as server needs to
> >>remember all those opened sessions so implementation must be very
> >>careful here (we did some testing and in one test setup after a thousand
> >>or so connections server refused to accept any new connections ...)
> >>
> >>
> >>
> >>>In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
> >>>have to be any less performant than any other public key security
> >>>technology IMO for many cases.
> >>>
> >>>
> >>>
> >>yes - if we do have better libs to do efficient
> >>streaming/canonicalization/verification/signing and generally avoiding
> >>excessive memory usage.
> >>
> >>
> >>
> >>>There may be degenerate cases where
> >>>it is, but if we can make those rare then we're in business.
> >>>
> >>>
> >>>
> >>>
> >>that is still to be seen :)
> >>
> >>currently SSL without keep alive (so it does key exchange each time) is
> >>2-5x faster than WS-SecConv after first message (this is just estimate
> >>...) and SSL with keep alive (no key exchange so it is comparable to
> >>session in WS-SecConv) it is faster by *order of magnitude* than
> >>WS-SecConv in what we tested (caveat emperor!)
> >>
> >>plus with SSL you can easily by hardware accelerator and load balancers
> >>that will understand SSL it will take some time before WS-SecConv is
> >>real standard and has this kind of support ...
> >>
> >>we are going to submit a paper (Satoshi did a great work on this) with
> >>details on tests to Workshop on Grid Computing (Grid 2004) and hope that
> >>it will lead to some discussion and ultimately faster (streaming?) code
> >>in future :)
> >>
> >>thanks,
> >>
> >>alek
> >>
> >>--
> >>The best way to predict the future is to invent it - Alan Kay
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: message/transport level security [Re: SOAP streaming and faults,
security everywhere and performanceimplications [Re: opinion Axis' future
... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Davanum Srinivas wrote:
>Do you have a WS-SecConv impl? (open source?)
>
>
we looked on Globus Toolkit 3.2 which i think is an early/prototype
implementation and i am not sure about its long term status.
i am sure that Globus guys will have more definitve answer to that :)
thanks,
alek
>On Wed, 09 Jun 2004 11:15:58 -0500, Aleksander Slominski
><as...@cs.indiana.edu> wrote:
>
>
>>Sanjiva Weerawarana wrote:
>>
>>
>>
>>>"Samuel Meder" <me...@mcs.anl.gov> writes:
>>>
>>>
>>>
>>>
>>>>I completely agree on Alex's point that security (and other QoS aspects)
>>>>are very important for us working in the Grid world. It is hard to
>>>>justify to users that turning on security will cause a 10x slowdown (it
>>>>is actually even worse with larger payloads) and since grid scenarios
>>>>are generally multi organization security is a ubiquitous requirement (I
>>>>would think that the same is true for B2B scenarios).
>>>>
>>>>
>>>>
>>>>
>>>Of course. However, that's a fundamental issue with XML security
>>>and not with the WS-* specs in particular. The XML sec stuff is
>>>defined in terms of DOMs and DOM hash's .. which can be computed
>>>in a streaming model for many XPaths ..
>>>
>>>
>>>
>>>
>>hi Sanjiva
>>
>>i think that it is true for verification but not for signing as you need
>>to compute signature: you *can* compute it in a streaming fashion but
>>then you need to put signature in header so you have to buffer whole
>>stream output (why, oh why, there is no footer element in SOAP ...)
>>
>>
>>
>>>Furthermore using WS-Security without WS-Secure Conversation is
>>>retarded (IMO).
>>>
>>>
>>>
>>>
>>there are many cases to consider and each situation is unique.
>>
>>WS-SecConv does not buy you much if you do very coarse grained messaging
>>(only one message sent to service) still the overhead is small enough
>>that may be doable to do WS-SecConv for every message.
>>
>>however there is a potential scalability problem as server needs to
>>remember all those opened sessions so implementation must be very
>>careful here (we did some testing and in one test setup after a thousand
>>or so connections server refused to accept any new connections ...)
>>
>>
>>
>>>In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
>>>have to be any less performant than any other public key security
>>>technology IMO for many cases.
>>>
>>>
>>>
>>yes - if we do have better libs to do efficient
>>streaming/canonicalization/verification/signing and generally avoiding
>>excessive memory usage.
>>
>>
>>
>>>There may be degenerate cases where
>>>it is, but if we can make those rare then we're in business.
>>>
>>>
>>>
>>>
>>that is still to be seen :)
>>
>>currently SSL without keep alive (so it does key exchange each time) is
>>2-5x faster than WS-SecConv after first message (this is just estimate
>>...) and SSL with keep alive (no key exchange so it is comparable to
>>session in WS-SecConv) it is faster by *order of magnitude* than
>>WS-SecConv in what we tested (caveat emperor!)
>>
>>plus with SSL you can easily by hardware accelerator and load balancers
>>that will understand SSL it will take some time before WS-SecConv is
>>real standard and has this kind of support ...
>>
>>we are going to submit a paper (Satoshi did a great work on this) with
>>details on tests to Workshop on Grid Computing (Grid 2004) and hope that
>>it will lead to some discussion and ultimately faster (streaming?) code
>>in future :)
>>
>>thanks,
>>
>>alek
>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>
>>
>
>
>
>
--
The best way to predict the future is to invent it - Alan Kay
Re: message/transport level security [Re: SOAP streaming and faults, security everywhere and performanceimplications [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API tomodify the soap header/body content
Posted by Davanum Srinivas <da...@gmail.com>.
Alek,
Do you have a WS-SecConv impl? (open source?)
-- dims
On Wed, 09 Jun 2004 11:15:58 -0500, Aleksander Slominski
<as...@cs.indiana.edu> wrote:
>
> Sanjiva Weerawarana wrote:
>
> >"Samuel Meder" <me...@mcs.anl.gov> writes:
> >
> >
> >>I completely agree on Alex's point that security (and other QoS aspects)
> >>are very important for us working in the Grid world. It is hard to
> >>justify to users that turning on security will cause a 10x slowdown (it
> >>is actually even worse with larger payloads) and since grid scenarios
> >>are generally multi organization security is a ubiquitous requirement (I
> >>would think that the same is true for B2B scenarios).
> >>
> >>
> >
> >Of course. However, that's a fundamental issue with XML security
> >and not with the WS-* specs in particular. The XML sec stuff is
> >defined in terms of DOMs and DOM hash's .. which can be computed
> >in a streaming model for many XPaths ..
> >
> >
> hi Sanjiva
>
> i think that it is true for verification but not for signing as you need
> to compute signature: you *can* compute it in a streaming fashion but
> then you need to put signature in header so you have to buffer whole
> stream output (why, oh why, there is no footer element in SOAP ...)
>
> >Furthermore using WS-Security without WS-Secure Conversation is
> >retarded (IMO).
> >
> >
> there are many cases to consider and each situation is unique.
>
> WS-SecConv does not buy you much if you do very coarse grained messaging
> (only one message sent to service) still the overhead is small enough
> that may be doable to do WS-SecConv for every message.
>
> however there is a potential scalability problem as server needs to
> remember all those opened sessions so implementation must be very
> careful here (we did some testing and in one test setup after a thousand
> or so connections server refused to accept any new connections ...)
>
> >In summary, IMO there's no reason why WS-Security/WS-Secure Conversation
> >have to be any less performant than any other public key security
> >technology IMO for many cases.
> >
> yes - if we do have better libs to do efficient
> streaming/canonicalization/verification/signing and generally avoiding
> excessive memory usage.
>
> >There may be degenerate cases where
> >it is, but if we can make those rare then we're in business.
> >
> >
> that is still to be seen :)
>
> currently SSL without keep alive (so it does key exchange each time) is
> 2-5x faster than WS-SecConv after first message (this is just estimate
> ...) and SSL with keep alive (no key exchange so it is comparable to
> session in WS-SecConv) it is faster by *order of magnitude* than
> WS-SecConv in what we tested (caveat emperor!)
>
> plus with SSL you can easily by hardware accelerator and load balancers
> that will understand SSL it will take some time before WS-SecConv is
> real standard and has this kind of support ...
>
> we are going to submit a paper (Satoshi did a great work on this) with
> details on tests to Workshop on Grid Computing (Grid 2004) and hope that
> it will lead to some discussion and ultimately faster (streaming?) code
> in future :)
>
> thanks,
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/