Isuru,
thanks for the info. I've read the article - good stuff.
What I'm missing however - can you use this model also to create WSS
messages?
For my understanding:
For example a use case where the WsSec policy requires to first sign a
SOAP body then encrypt it. In this case you would need to first create
a full security header with Signature information, then modify the XML
document to replace the original Body with the encrypted Body.
Regards,
Werner
________________________________
From: ext Isuru Suriarachchi [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 16, 2008 1:46 PM
To: [EMAIL PROTECTED]
Cc: Dittmann, Werner (NSN - DE/Munich); Dennis Sosnoski; Colm O
hEigeartaigh; Werner Dittmann; jimmy Zhang; [EMAIL PROTECTED];
[email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: WSS4J 1.5.4 Encryption Performance Question
Hi,
As paul has explained, we have developed a new WS-Security
implementation totally on Axiom. Our intention was to find a solution
for the well known performance drawbacks of Rampart. According to
performance results we obtained at the end of our project, I can say
that we have achieved our goal.
One of the main reasons for Rampart performacne drawbacks is the
usage of DOM as the object model in WSS4J and XML-Sec implementations.
As top Rampart layer uses Axiom, DOOM conversion is done to convert the
object model into DOM. So we have implemented WS-Security and
XML-Security entirely using Axiom and that removes the requirement for
DOOM. And also as Axiom is pull based, it saves lot of memory when it
comes to invalid messages if they are rejected without building the
whole message.
The other major problem with Rampart is that WSS4J is not
WS-SecurityPolicy aware. So the policy based validations of secured SOAP
messages are done after going through all the WS-Security validations
steps in WSS4J. This wastes both memory and processing power if the
message is not according to policy. In order to remove this drawback, we
have made our WS-Security implementation policy aware. So the token
proccessors can do policy validations themselves.
In addition to above mentioned improvements, we have done
various code level improvements as well. Specially in invalid message
cases like DOS attacks, our implementation performs extremely
efficiently than Rampart. In other words, it rejects the messages far
earlier than Rampart.
I have explained our WS-Security model in the article at
http://wso2.org/library/articles/ws-security-processing-models-along-ws-
securitypolicy-1.
Thanks,
Isuru
On Thu, Oct 16, 2008 at 2:19 PM, Paul Fremantle
<[EMAIL PROTECTED]> wrote:
Werner
A group of four students from the University of Morutuwa
built a
WS-Security implementation architected directly on top
of Axiom as
their final year project. Saliya (copied) is one of
them, plus
Sameera, Isuru and Kalani. (Forgive me for excluding
their surnames).
They called this "Rampart2" as a code-name, but of
course naming would
need to be decided by the community. AFAIK they intend
to contribute
this to the WS project - and the contribution of
canonicalization into
Axiom is the first step they have taken.
My understanding is that they have submitted a paper on
this to the
IITC conference, so the paper will be published at the
end of the
month. In the meantime, if you contact Saliya, I'm sure
he can share a
pre-press version. Saliya also mentioned he is planning
to share some
results in a blog.
Paul
On Thu, Oct 16, 2008 at 7:49 AM, Dittmann, Werner (NSN -
DE/Munich)
<[EMAIL PROTECTED]> wrote:
> Paul,
>
> a link to this work would be nice :-) ,
>
> Regards,
> Werner
>
>> -----Original Message-----
>> From: ext Paul Fremantle [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, October 16, 2008 8:37 AM
>> To: Dennis Sosnoski
>> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy
Zhang;
>> [EMAIL PROTECTED]; [email protected];
[EMAIL PROTECTED]
>> Subject: Re: WSS4J 1.5.4 Encryption Performance
Question
>>
>> Dennis
>>
>> I don't know about *just* canonicalization, but the
team built a
>> complete version of WS-Security on top of Axiom and
in their tests the
>> overall speedup ranged from 1.7-3x faster on various
scenarios and
>> message sizes.
>>
>> Paul
>>
>> On Thu, Oct 16, 2008 at 7:29 AM, Dennis Sosnoski
>> <[EMAIL PROTECTED]> wrote:
>> > Hi Paul,
>> >
>> > I don't think that C14N support in Axiom is likely
to be of
>> much direct
>> > benefit for performance. Axiom is slower and more
>> memory-intensive than
>> > standard DOM implementations when a document model
needs to
>> be build - its
>> > advantage is that barring signing and such, most
times you
>> can get away
>> > without the need for a document model - so I don't
see that
>> using Axiom
>> > rather than a standard DOM is really going to help.
>> >
>> > The exception would be cases where only some tokens
in the
>> header are being
>> > signed, which is actually the case that started
this
>> discussion. If the
>> > Axiom+Rampart+WSS4J combination is smart enough to
only
>> build the Axiom DOM
>> > for the header tokens that are being signed, this
should
>> give much better
>> > performance than when the entire message has to be
>> converted to a DOM.
>> >
>> > I look forward to comparing the performance using
Axiom
>> C14N vs. using
>> > standard DOM, and will give this a try as soon as
it
>> becomes an option in
>> > the configuration.
>> >
>> > - Dennis
>> >
>> >
>> > Paul Fremantle wrote:
>> >>>
>> >>> IMO
>> >>> C14N (in the case of signature) and DOM are the
main culprits for
>> >>> performance as far as WSS4J is concerned, not
PKC.
>> >>>
>> >>
>> >> I believe that some students have built out C14N
directly
>> in Axiom and
>> >> are planning to contribute it to Axiom shortly.
That
>> should make a big
>> >> difference.
>> >>
>> >> Paul
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> [EMAIL PROTECTED]
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail:
[EMAIL PROTECTED]
>> For additional commands, e-mail:
[EMAIL PROTECTED]
>>
>>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]