axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject 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
Date Wed, 09 Jun 2004 20:13:08 GMT
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
<aslom@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
> ><aslom@cs.indiana.edu> wrote:
> >
> >
> >>Sanjiva Weerawarana wrote:
> >>
> >>
> >>
> >>>"Samuel Meder" <meder@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/

Mime
View raw message