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 Paul Fremantle <pz...@gmail.com> on 2008/10/16 10:49:50 UTC
Re: WSS4J 1.5.4 Encryption Performance Question
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)
<we...@nsn.com> wrote:
> Paul,
>
> a link to this work would be nice :-) ,
>
> Regards,
> Werner
>
>> -----Original Message-----
>> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
>> Sent: Thursday, October 16, 2008 8:37 AM
>> To: Dennis Sosnoski
>> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
>> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
>> 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
>> <dm...@sosnoski.com> 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
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Plus .. JAXB is a data binding standard - a way to map XML to Java
objects. AXIOM is an XML Infoset representation, which is what's needed
for WS-Sec etc. and not a data bound set of objects. In fact, you can't do
it with the data bound stuff because you lose information items in the
binding.
Sanjiva.
Isuru Suriarachchi wrote:
> Hi Oliver,
>
> On Thu, Oct 16, 2008 at 5:58 PM, Oliver Wulff <ol...@zurich.ch>
> wrote:
>
> Hi Isuru
>
> What was the reason to use Axiom instead of the JAXB standard?
>
>
> First I have to say that I'm not much familiar with JAXB standard. But
> as we are developing a security module for Axis2, it is the best to use
> the same object model as Axis2. Because it will avoid overheads of
> object model conversions (like DOOM). Axis2 uses Axiom and also Axiom is
> pull based and light weight. So it was a straight forward decision for
> us to use Axiom.
>
> Thanks,
> Isuru
>
>
>
>
> Thanks
> Oliver
>
>
>
>
> "Isuru
> Suriarachchi" An:
> axis-dev@ws.apache.org <ma...@ws.apache.org>
> <isurues@gmail.co <ma...@gmail.co>
> Kopie: "Dittmann, Werner (NSN - DE/Munich)"
> <werner.dittmann@nsn.com <ma...@nsn.com>>, "Dennis
> m> Sosnoski"
> <dms@sosnoski.com <ma...@sosnoski.com>>, "Colm O hEigeartaigh"
> <coheigea@progress.com <ma...@progress.com>>, "Werner
> Dittmann"
> <Werner.Dittmann@t-online.de <ma...@t-online.de>>,
> "jimmy Zhang" <jzhang@ximpleware.com <ma...@ximpleware.com>>,
> 16.10.2008 13:46 smmtech@sbcglobal.net
> <ma...@sbcglobal.net>, wss4j-dev@ws.apache.org
> <ma...@ws.apache.org>, saliya@wso2.com
> <ma...@wso2.com>, sameera@wso2.com <ma...@wso2.com>,
> kalani@wso2.com
> <ma...@wso2.com>, (Blindkopie: Oliver Wulff/CHK/External/Zurich)
> Thema: 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 <pzfreo@gmail.com
> <ma...@gmail.com>> 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)
> <werner.dittmann@nsn.com <ma...@nsn.com>> wrote:
> > Paul,
> >
> > a link to this work would be nice :-) ,
> >
> > Regards,
> > Werner
> >
> >> -----Original Message-----
> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com
> <ma...@gmail.com>]
> >> Sent: Thursday, October 16, 2008 8:37 AM
> >> To: Dennis Sosnoski
> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
> >> smmtech@sbcglobal.net <ma...@sbcglobal.net>;
> wss4j-dev@ws.apache.org <ma...@ws.apache.org>;
> saliya@wso2.com <ma...@wso2.com>
> >> 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
> >> <dms@sosnoski.com <ma...@sosnoski.com>> 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
> >> paul@wso2.com <ma...@wso2.com>
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> <http://www.wso2.com>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> <ma...@ws.apache.org>
> >>
> >>
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com <ma...@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com
> <http://www.wso2.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
>
>
>
>
>
> ******************* BITTE BEACHTEN *******************
> Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
> möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
> Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
> genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
> irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
> Ausschluss jeder Reproduktion zu zerstören und die absendende Person
> umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Plus .. JAXB is a data binding standard - a way to map XML to Java
objects. AXIOM is an XML Infoset representation, which is what's needed
for WS-Sec etc. and not a data bound set of objects. In fact, you can't do
it with the data bound stuff because you lose information items in the
binding.
Sanjiva.
Isuru Suriarachchi wrote:
> Hi Oliver,
>
> On Thu, Oct 16, 2008 at 5:58 PM, Oliver Wulff <ol...@zurich.ch>
> wrote:
>
> Hi Isuru
>
> What was the reason to use Axiom instead of the JAXB standard?
>
>
> First I have to say that I'm not much familiar with JAXB standard. But
> as we are developing a security module for Axis2, it is the best to use
> the same object model as Axis2. Because it will avoid overheads of
> object model conversions (like DOOM). Axis2 uses Axiom and also Axiom is
> pull based and light weight. So it was a straight forward decision for
> us to use Axiom.
>
> Thanks,
> Isuru
>
>
>
>
> Thanks
> Oliver
>
>
>
>
> "Isuru
> Suriarachchi" An:
> axis-dev@ws.apache.org <ma...@ws.apache.org>
> <isurues@gmail.co <ma...@gmail.co>
> Kopie: "Dittmann, Werner (NSN - DE/Munich)"
> <werner.dittmann@nsn.com <ma...@nsn.com>>, "Dennis
> m> Sosnoski"
> <dms@sosnoski.com <ma...@sosnoski.com>>, "Colm O hEigeartaigh"
> <coheigea@progress.com <ma...@progress.com>>, "Werner
> Dittmann"
> <Werner.Dittmann@t-online.de <ma...@t-online.de>>,
> "jimmy Zhang" <jzhang@ximpleware.com <ma...@ximpleware.com>>,
> 16.10.2008 13:46 smmtech@sbcglobal.net
> <ma...@sbcglobal.net>, wss4j-dev@ws.apache.org
> <ma...@ws.apache.org>, saliya@wso2.com
> <ma...@wso2.com>, sameera@wso2.com <ma...@wso2.com>,
> kalani@wso2.com
> <ma...@wso2.com>, (Blindkopie: Oliver Wulff/CHK/External/Zurich)
> Thema: 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 <pzfreo@gmail.com
> <ma...@gmail.com>> 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)
> <werner.dittmann@nsn.com <ma...@nsn.com>> wrote:
> > Paul,
> >
> > a link to this work would be nice :-) ,
> >
> > Regards,
> > Werner
> >
> >> -----Original Message-----
> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com
> <ma...@gmail.com>]
> >> Sent: Thursday, October 16, 2008 8:37 AM
> >> To: Dennis Sosnoski
> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
> >> smmtech@sbcglobal.net <ma...@sbcglobal.net>;
> wss4j-dev@ws.apache.org <ma...@ws.apache.org>;
> saliya@wso2.com <ma...@wso2.com>
> >> 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
> >> <dms@sosnoski.com <ma...@sosnoski.com>> 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
> >> paul@wso2.com <ma...@wso2.com>
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> <http://www.wso2.com>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> <ma...@ws.apache.org>
> >>
> >>
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com <ma...@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com
> <http://www.wso2.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
>
>
>
>
>
>
>
> ******************* BITTE BEACHTEN *******************
> Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
> möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
> Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
> genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
> irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
> Ausschluss jeder Reproduktion zu zerstören und die absendende Person
> umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Isuru Suriarachchi <is...@gmail.com>.
Hi Oliver,
On Thu, Oct 16, 2008 at 5:58 PM, Oliver Wulff <ol...@zurich.ch>wrote:
> Hi Isuru
>
> What was the reason to use Axiom instead of the JAXB standard?
First I have to say that I'm not much familiar with JAXB standard. But as we
are developing a security module for Axis2, it is the best to use the same
object model as Axis2. Because it will avoid overheads of object model
conversions (like DOOM). Axis2 uses Axiom and also Axiom is pull based and
light weight. So it was a straight forward decision for us to use Axiom.
Thanks,
Isuru
>
>
> Thanks
> Oliver
>
>
>
>
> "Isuru
> Suriarachchi" An:
> axis-dev@ws.apache.org
> <isurues@gmail.co Kopie: "Dittmann, Werner
> (NSN - DE/Munich)" <we...@nsn.com>, "Dennis
> m> Sosnoski" <dm...@sosnoski.com>,
> "Colm O hEigeartaigh" <co...@progress.com>, "Werner
> Dittmann" <
> Werner.Dittmann@t-online.de>, "jimmy Zhang" <jz...@ximpleware.com>,
> 16.10.2008 13:46 smmtech@sbcglobal.net,
> wss4j-dev@ws.apache.org, saliya@wso2.com, sameera@wso2.com,
> kalani@wso2.com,
> (Blindkopie: Oliver Wulff/CHK/External/Zurich)
> Thema: 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 <pz...@gmail.com> 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)
> <we...@nsn.com> wrote:
> > Paul,
> >
> > a link to this work would be nice :-) ,
> >
> > Regards,
> > Werner
> >
> >> -----Original Message-----
> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
> >> Sent: Thursday, October 16, 2008 8:37 AM
> >> To: Dennis Sosnoski
> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
> >> 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
> >> <dm...@sosnoski.com> 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
> >> paul@wso2.com
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
>
>
>
>
>
> ******************* BITTE BEACHTEN *******************
> Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
> möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
> Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
> genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
> irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
> Ausschluss jeder Reproduktion zu zerstören und die absendende Person
> umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.
>
>
Re: Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Isuru Suriarachchi <is...@gmail.com>.
Hi Oliver,
On Thu, Oct 16, 2008 at 5:58 PM, Oliver Wulff <ol...@zurich.ch>wrote:
> Hi Isuru
>
> What was the reason to use Axiom instead of the JAXB standard?
First I have to say that I'm not much familiar with JAXB standard. But as we
are developing a security module for Axis2, it is the best to use the same
object model as Axis2. Because it will avoid overheads of object model
conversions (like DOOM). Axis2 uses Axiom and also Axiom is pull based and
light weight. So it was a straight forward decision for us to use Axiom.
Thanks,
Isuru
>
>
> Thanks
> Oliver
>
>
>
>
> "Isuru
> Suriarachchi" An:
> axis-dev@ws.apache.org
> <isurues@gmail.co Kopie: "Dittmann, Werner
> (NSN - DE/Munich)" <we...@nsn.com>, "Dennis
> m> Sosnoski" <dm...@sosnoski.com>,
> "Colm O hEigeartaigh" <co...@progress.com>, "Werner
> Dittmann" <
> Werner.Dittmann@t-online.de>, "jimmy Zhang" <jz...@ximpleware.com>,
> 16.10.2008 13:46 smmtech@sbcglobal.net,
> wss4j-dev@ws.apache.org, saliya@wso2.com, sameera@wso2.com,
> kalani@wso2.com,
> (Blindkopie: Oliver Wulff/CHK/External/Zurich)
> Thema: 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 <pz...@gmail.com> 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)
> <we...@nsn.com> wrote:
> > Paul,
> >
> > a link to this work would be nice :-) ,
> >
> > Regards,
> > Werner
> >
> >> -----Original Message-----
> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
> >> Sent: Thursday, October 16, 2008 8:37 AM
> >> To: Dennis Sosnoski
> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
> >> 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
> >> <dm...@sosnoski.com> 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
> >> paul@wso2.com
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
>
>
>
>
>
>
>
> ******************* BITTE BEACHTEN *******************
> Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
> möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
> Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
> genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
> irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
> Ausschluss jeder Reproduktion zu zerstören und die absendende Person
> umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.
>
>
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Shawn,
I think performance graphs of Rampart2 was quite good compared to
Rampart/WSS4J/Xmlsec and IFAIK, all the four scenarios you tested are
possible with Rampart2 at the moment and the configuration is almost
similar to Apache Rampart. One thing you can do is to run the benchmark
against the new implementation on AXIOM and observe the performance
improvements.
thanks,
nandana
On Thu, Oct 16, 2008 at 5:53 PM, Dittmann, Werner (NSN - DE/Munich) <
werner.dittmann@nsn.com> wrote:
> 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:isurues@gmail.com]
> *Sent:* Thursday, October 16, 2008 1:46 PM
> *To:* axis-dev@ws.apache.org
> *Cc:* Dittmann, Werner (NSN - DE/Munich); Dennis Sosnoski; Colm O
> hEigeartaigh; Werner Dittmann; jimmy Zhang; smmtech@sbcglobal.net;
> wss4j-dev@ws.apache.org; saliya@wso2.com; sameera@wso2.com;
> kalani@wso2.com
>
> *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 <pz...@gmail.com> 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)
>> <we...@nsn.com> wrote:
>> > Paul,
>> >
>> > a link to this work would be nice :-) ,
>> >
>> > Regards,
>> > Werner
>> >
>> >> -----Original Message-----
>> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
>> >> Sent: Thursday, October 16, 2008 8:37 AM
>> >> To: Dennis Sosnoski
>> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
>> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
>> >> 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
>> >> <dm...@sosnoski.com> 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
>> >> paul@wso2.com
>> >>
>> >> "Oxygenating the Web Service Platform", www.wso2.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
Hi Shawn,
I think performance graphs of Rampart2 was quite good compared to
Rampart/WSS4J/Xmlsec and IFAIK, all the four scenarios you tested are
possible with Rampart2 at the moment and the configuration is almost
similar to Apache Rampart. One thing you can do is to run the benchmark
against the new implementation on AXIOM and observe the performance
improvements.
thanks,
nandana
On Thu, Oct 16, 2008 at 5:53 PM, Dittmann, Werner (NSN - DE/Munich) <
werner.dittmann@nsn.com> wrote:
> 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:isurues@gmail.com]
> *Sent:* Thursday, October 16, 2008 1:46 PM
> *To:* axis-dev@ws.apache.org
> *Cc:* Dittmann, Werner (NSN - DE/Munich); Dennis Sosnoski; Colm O
> hEigeartaigh; Werner Dittmann; jimmy Zhang; smmtech@sbcglobal.net;
> wss4j-dev@ws.apache.org; saliya@wso2.com; sameera@wso2.com;
> kalani@wso2.com
>
> *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 <pz...@gmail.com> 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)
>> <we...@nsn.com> wrote:
>> > Paul,
>> >
>> > a link to this work would be nice :-) ,
>> >
>> > Regards,
>> > Werner
>> >
>> >> -----Original Message-----
>> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
>> >> Sent: Thursday, October 16, 2008 8:37 AM
>> >> To: Dennis Sosnoski
>> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
>> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
>> >> 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
>> >> <dm...@sosnoski.com> 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
>> >> paul@wso2.com
>> >>
>> >> "Oxygenating the Web Service Platform", www.wso2.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Isuru Suriarachchi <is...@gmail.com>.
Hi Werner,
On Thu, Oct 16, 2008 at 9:38 PM, Isuru Suriarachchi <is...@gmail.com>wrote:
> Hi Werner,
>
> On Thu, Oct 16, 2008 at 5:53 PM, Dittmann, Werner (NSN - DE/Munich) <
> werner.dittmann@nsn.com> wrote:
>
>> 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?
>>
>
In the previous reply I've missed your word *create* :-) You mean message
building right?? When it comes to building, Rampart and Rampart2 are almost
the same. This model is only for processing. But we have done some design
and implementation level improvements to our building side as well.
Thanks,
Isuru
>
> Of course yes.. We can use this for WSS and we designed it for WSS. Through
> our research what we found was that most of the policy validations of WSS
> can be done within WS-Security processors themselves.
>
>
>>
>> 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.
>>
>
> Are you asking about message building? If so when it comes to message
> building, Rampart and Rampart2 functionaliities are almost the same. What we
> are trying to do is to improve the performance of message processing.
>
> Lets consider the scenario of processing a type of message you have
> explained. Just like WSS4J, Rampart2 WS-Sec processing model also calls the
> appropreate token processor according to the order of tokens of the Security
> header.
>
> <Timestamp> --> TimestampProcessor
> <UsernameToken> --> UsernameTokenProcessor
> ...
> <Signature> --> SignatureProcessor
> <Encryption> --> EncryptionProcessor
>
> So according to this, in your example, as the receiving message should be
> decrytped before verifying signature when the execution comes to
> EncryptedKeyProcessor, it decrypts all encrytped parts. Interesting thing is
> that if some error found in encryption according to policy (say
> EncryptSignature is not done) Rampart2 will reject the message immediatedly
> without going into SignatureProcessor as processor are policy aware.
>
> If you are talking about the building of object tree, of course we have to
> build the message body to decrypt the message. That's something we can't
> avoid. But through our design, we have delayed building message body until
> it is really needed. But WSS4J always builds the whole memory tree as soon
> as it receives the message.
>
> And also there are extreme cases where we can't do policy validations
> within WS-Sec processors. But its only about 10% of the cases. Even for that
> kind of scenarios, Rampart2 still performs better than Rampart through its
> improved design.
>
> Thanks,
> Isuru
>
>
>>
>> Regards,
>> Werner
>>
>> ------------------------------
>> *From:* ext Isuru Suriarachchi [mailto:isurues@gmail.com]
>> *Sent:* Thursday, October 16, 2008 1:46 PM
>> *To:* axis-dev@ws.apache.org
>> *Cc:* Dittmann, Werner (NSN - DE/Munich); Dennis Sosnoski; Colm O
>> hEigeartaigh; Werner Dittmann; jimmy Zhang; smmtech@sbcglobal.net;
>> wss4j-dev@ws.apache.org; saliya@wso2.com; sameera@wso2.com;
>> kalani@wso2.com
>>
>> *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 <pz...@gmail.com> 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)
>>> <we...@nsn.com> wrote:
>>> > Paul,
>>> >
>>> > a link to this work would be nice :-) ,
>>> >
>>> > Regards,
>>> > Werner
>>> >
>>> >> -----Original Message-----
>>> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
>>> >> Sent: Thursday, October 16, 2008 8:37 AM
>>> >> To: Dennis Sosnoski
>>> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
>>> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
>>> >> 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
>>> >> <dm...@sosnoski.com> 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
>>> >> paul@wso2.com
>>> >>
>>> >> "Oxygenating the Web Service Platform", www.wso2.com
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Paul Fremantle
>>> Co-Founder and CTO, WSO2
>>> Apache Synapse PMC Chair
>>> OASIS WS-RX TC Co-chair
>>>
>>> blog: http://pzf.fremantle.org
>>> paul@wso2.com
>>>
>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>
>>>
>>
>
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Isuru Suriarachchi <is...@gmail.com>.
Hi Werner,
On Thu, Oct 16, 2008 at 9:38 PM, Isuru Suriarachchi <is...@gmail.com>wrote:
> Hi Werner,
>
> On Thu, Oct 16, 2008 at 5:53 PM, Dittmann, Werner (NSN - DE/Munich) <
> werner.dittmann@nsn.com> wrote:
>
>> 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?
>>
>
In the previous reply I've missed your word *create* :-) You mean message
building right?? When it comes to building, Rampart and Rampart2 are almost
the same. This model is only for processing. But we have done some design
and implementation level improvements to our building side as well.
Thanks,
Isuru
>
> Of course yes.. We can use this for WSS and we designed it for WSS. Through
> our research what we found was that most of the policy validations of WSS
> can be done within WS-Security processors themselves.
>
>
>>
>> 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.
>>
>
> Are you asking about message building? If so when it comes to message
> building, Rampart and Rampart2 functionaliities are almost the same. What we
> are trying to do is to improve the performance of message processing.
>
> Lets consider the scenario of processing a type of message you have
> explained. Just like WSS4J, Rampart2 WS-Sec processing model also calls the
> appropreate token processor according to the order of tokens of the Security
> header.
>
> <Timestamp> --> TimestampProcessor
> <UsernameToken> --> UsernameTokenProcessor
> ...
> <Signature> --> SignatureProcessor
> <Encryption> --> EncryptionProcessor
>
> So according to this, in your example, as the receiving message should be
> decrytped before verifying signature when the execution comes to
> EncryptedKeyProcessor, it decrypts all encrytped parts. Interesting thing is
> that if some error found in encryption according to policy (say
> EncryptSignature is not done) Rampart2 will reject the message immediatedly
> without going into SignatureProcessor as processor are policy aware.
>
> If you are talking about the building of object tree, of course we have to
> build the message body to decrypt the message. That's something we can't
> avoid. But through our design, we have delayed building message body until
> it is really needed. But WSS4J always builds the whole memory tree as soon
> as it receives the message.
>
> And also there are extreme cases where we can't do policy validations
> within WS-Sec processors. But its only about 10% of the cases. Even for that
> kind of scenarios, Rampart2 still performs better than Rampart through its
> improved design.
>
> Thanks,
> Isuru
>
>
>>
>> Regards,
>> Werner
>>
>> ------------------------------
>> *From:* ext Isuru Suriarachchi [mailto:isurues@gmail.com]
>> *Sent:* Thursday, October 16, 2008 1:46 PM
>> *To:* axis-dev@ws.apache.org
>> *Cc:* Dittmann, Werner (NSN - DE/Munich); Dennis Sosnoski; Colm O
>> hEigeartaigh; Werner Dittmann; jimmy Zhang; smmtech@sbcglobal.net;
>> wss4j-dev@ws.apache.org; saliya@wso2.com; sameera@wso2.com;
>> kalani@wso2.com
>>
>> *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 <pz...@gmail.com> 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)
>>> <we...@nsn.com> wrote:
>>> > Paul,
>>> >
>>> > a link to this work would be nice :-) ,
>>> >
>>> > Regards,
>>> > Werner
>>> >
>>> >> -----Original Message-----
>>> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
>>> >> Sent: Thursday, October 16, 2008 8:37 AM
>>> >> To: Dennis Sosnoski
>>> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
>>> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
>>> >> 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
>>> >> <dm...@sosnoski.com> 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
>>> >> paul@wso2.com
>>> >>
>>> >> "Oxygenating the Web Service Platform", www.wso2.com
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Paul Fremantle
>>> Co-Founder and CTO, WSO2
>>> Apache Synapse PMC Chair
>>> OASIS WS-RX TC Co-chair
>>>
>>> blog: http://pzf.fremantle.org
>>> paul@wso2.com
>>>
>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>>
>>>
>>
>
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Isuru Suriarachchi <is...@gmail.com>.
Hi Werner,
On Thu, Oct 16, 2008 at 5:53 PM, Dittmann, Werner (NSN - DE/Munich) <
werner.dittmann@nsn.com> wrote:
> 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?
>
Of course yes.. We can use this for WSS and we designed it for WSS. Through
our research what we found was that most of the policy validations of WSS
can be done within WS-Security processors themselves.
>
> 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.
>
Are you asking about message building? If so when it comes to message
building, Rampart and Rampart2 functionaliities are almost the same. What we
are trying to do is to improve the performance of message processing.
Lets consider the scenario of processing a type of message you have
explained. Just like WSS4J, Rampart2 WS-Sec processing model also calls the
appropreate token processor according to the order of tokens of the Security
header.
<Timestamp> --> TimestampProcessor
<UsernameToken> --> UsernameTokenProcessor
...
<Signature> --> SignatureProcessor
<Encryption> --> EncryptionProcessor
So according to this, in your example, as the receiving message should be
decrytped before verifying signature when the execution comes to
EncryptedKeyProcessor, it decrypts all encrytped parts. Interesting thing is
that if some error found in encryption according to policy (say
EncryptSignature is not done) Rampart2 will reject the message immediatedly
without going into SignatureProcessor as processor are policy aware.
If you are talking about the building of object tree, of course we have to
build the message body to decrypt the message. That's something we can't
avoid. But through our design, we have delayed building message body until
it is really needed. But WSS4J always builds the whole memory tree as soon
as it receives the message.
And also there are extreme cases where we can't do policy validations within
WS-Sec processors. But its only about 10% of the cases. Even for that kind
of scenarios, Rampart2 still performs better than Rampart through its
improved design.
Thanks,
Isuru
>
> Regards,
> Werner
>
> ------------------------------
> *From:* ext Isuru Suriarachchi [mailto:isurues@gmail.com]
> *Sent:* Thursday, October 16, 2008 1:46 PM
> *To:* axis-dev@ws.apache.org
> *Cc:* Dittmann, Werner (NSN - DE/Munich); Dennis Sosnoski; Colm O
> hEigeartaigh; Werner Dittmann; jimmy Zhang; smmtech@sbcglobal.net;
> wss4j-dev@ws.apache.org; saliya@wso2.com; sameera@wso2.com;
> kalani@wso2.com
>
> *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 <pz...@gmail.com> 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)
>> <we...@nsn.com> wrote:
>> > Paul,
>> >
>> > a link to this work would be nice :-) ,
>> >
>> > Regards,
>> > Werner
>> >
>> >> -----Original Message-----
>> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
>> >> Sent: Thursday, October 16, 2008 8:37 AM
>> >> To: Dennis Sosnoski
>> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
>> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
>> >> 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
>> >> <dm...@sosnoski.com> 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
>> >> paul@wso2.com
>> >>
>> >> "Oxygenating the Web Service Platform", www.wso2.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Saliya Ekanayake <sa...@wso2.com>.
Please find the performance comparison of Rampart Vs our solution at
http://wssecforaxis2.blogspot.com/2008/10/axis2-performance-with-ws-security.html
Thanks,
Saliya
Dittmann, Werner (NSN - DE/Munich) wrote:
> 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:isurues@gmail.com]
> *Sent:* Thursday, October 16, 2008 1:46 PM
> *To:* axis-dev@ws.apache.org
> *Cc:* Dittmann, Werner (NSN - DE/Munich); Dennis Sosnoski; Colm O
> hEigeartaigh; Werner Dittmann; jimmy Zhang; smmtech@sbcglobal.net;
> wss4j-dev@ws.apache.org; saliya@wso2.com; sameera@wso2.com;
> kalani@wso2.com
> *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 <pzfreo@gmail.com
> <ma...@gmail.com>> 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)
> <werner.dittmann@nsn.com <ma...@nsn.com>> wrote:
> > Paul,
> >
> > a link to this work would be nice :-) ,
> >
> > Regards,
> > Werner
> >
> >> -----Original Message-----
> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com
> <ma...@gmail.com>]
> >> Sent: Thursday, October 16, 2008 8:37 AM
> >> To: Dennis Sosnoski
> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
> >> smmtech@sbcglobal.net <ma...@sbcglobal.net>;
> wss4j-dev@ws.apache.org <ma...@ws.apache.org>;
> saliya@wso2.com <ma...@wso2.com>
> >> 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
> >> <dms@sosnoski.com <ma...@sosnoski.com>> 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
> >> paul@wso2.com <ma...@wso2.com>
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> <http://www.wso2.com>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> >> For additional commands, e-mail:
> wss4j-dev-help@ws.apache.org <ma...@ws.apache.org>
> >>
> >>
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com <ma...@wso2.com>
>
> "Oxygenating the Web Service Platform", www.wso2.com
> <http://www.wso2.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> <ma...@ws.apache.org>
> For additional commands, e-mail: axis-dev-help@ws.apache.org
> <ma...@ws.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Isuru Suriarachchi <is...@gmail.com>.
Hi Werner,
On Thu, Oct 16, 2008 at 5:53 PM, Dittmann, Werner (NSN - DE/Munich) <
werner.dittmann@nsn.com> wrote:
> 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?
>
Of course yes.. We can use this for WSS and we designed it for WSS. Through
our research what we found was that most of the policy validations of WSS
can be done within WS-Security processors themselves.
>
> 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.
>
Are you asking about message building? If so when it comes to message
building, Rampart and Rampart2 functionaliities are almost the same. What we
are trying to do is to improve the performance of message processing.
Lets consider the scenario of processing a type of message you have
explained. Just like WSS4J, Rampart2 WS-Sec processing model also calls the
appropreate token processor according to the order of tokens of the Security
header.
<Timestamp> --> TimestampProcessor
<UsernameToken> --> UsernameTokenProcessor
...
<Signature> --> SignatureProcessor
<Encryption> --> EncryptionProcessor
So according to this, in your example, as the receiving message should be
decrytped before verifying signature when the execution comes to
EncryptedKeyProcessor, it decrypts all encrytped parts. Interesting thing is
that if some error found in encryption according to policy (say
EncryptSignature is not done) Rampart2 will reject the message immediatedly
without going into SignatureProcessor as processor are policy aware.
If you are talking about the building of object tree, of course we have to
build the message body to decrypt the message. That's something we can't
avoid. But through our design, we have delayed building message body until
it is really needed. But WSS4J always builds the whole memory tree as soon
as it receives the message.
And also there are extreme cases where we can't do policy validations within
WS-Sec processors. But its only about 10% of the cases. Even for that kind
of scenarios, Rampart2 still performs better than Rampart through its
improved design.
Thanks,
Isuru
>
> Regards,
> Werner
>
> ------------------------------
> *From:* ext Isuru Suriarachchi [mailto:isurues@gmail.com]
> *Sent:* Thursday, October 16, 2008 1:46 PM
> *To:* axis-dev@ws.apache.org
> *Cc:* Dittmann, Werner (NSN - DE/Munich); Dennis Sosnoski; Colm O
> hEigeartaigh; Werner Dittmann; jimmy Zhang; smmtech@sbcglobal.net;
> wss4j-dev@ws.apache.org; saliya@wso2.com; sameera@wso2.com;
> kalani@wso2.com
>
> *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 <pz...@gmail.com> 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)
>> <we...@nsn.com> wrote:
>> > Paul,
>> >
>> > a link to this work would be nice :-) ,
>> >
>> > Regards,
>> > Werner
>> >
>> >> -----Original Message-----
>> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
>> >> Sent: Thursday, October 16, 2008 8:37 AM
>> >> To: Dennis Sosnoski
>> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
>> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
>> >> 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
>> >> <dm...@sosnoski.com> 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
>> >> paul@wso2.com
>> >>
>> >> "Oxygenating the Web Service Platform", www.wso2.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> Paul Fremantle
>> Co-Founder and CTO, WSO2
>> Apache Synapse PMC Chair
>> OASIS WS-RX TC Co-chair
>>
>> blog: http://pzf.fremantle.org
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-dev-help@ws.apache.org
>>
>>
>
RE: WSS4J 1.5.4 Encryption Performance Question
Posted by "Dittmann, Werner (NSN - DE/Munich)" <we...@nsn.com>.
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:isurues@gmail.com]
Sent: Thursday, October 16, 2008 1:46 PM
To: axis-dev@ws.apache.org
Cc: Dittmann, Werner (NSN - DE/Munich); Dennis Sosnoski; Colm O
hEigeartaigh; Werner Dittmann; jimmy Zhang; smmtech@sbcglobal.net;
wss4j-dev@ws.apache.org; saliya@wso2.com; sameera@wso2.com;
kalani@wso2.com
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
<pz...@gmail.com> 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)
<we...@nsn.com> wrote:
> Paul,
>
> a link to this work would be nice :-) ,
>
> Regards,
> Werner
>
>> -----Original Message-----
>> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
>> Sent: Thursday, October 16, 2008 8:37 AM
>> To: Dennis Sosnoski
>> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy
Zhang;
>> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org;
saliya@wso2.com
>> 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
>> <dm...@sosnoski.com> 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
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail:
wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail:
wss4j-dev-help@ws.apache.org
>>
>>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail:
axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail:
axis-dev-help@ws.apache.org
Antwort: Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Oliver Wulff <ol...@zurich.ch>.
Hi Isuru
What was the reason to use Axiom instead of the JAXB standard?
Thanks
Oliver
"Isuru
Suriarachchi" An: axis-dev@ws.apache.org
<isurues@gmail.co Kopie: "Dittmann, Werner (NSN - DE/Munich)" <we...@nsn.com>, "Dennis
m> Sosnoski" <dm...@sosnoski.com>, "Colm O hEigeartaigh" <co...@progress.com>, "Werner
Dittmann" <We...@t-online.de>, "jimmy Zhang" <jz...@ximpleware.com>,
16.10.2008 13:46 smmtech@sbcglobal.net, wss4j-dev@ws.apache.org, saliya@wso2.com, sameera@wso2.com,
kalani@wso2.com, (Blindkopie: Oliver Wulff/CHK/External/Zurich)
Thema: 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 <pz...@gmail.com> 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)
<we...@nsn.com> wrote:
> Paul,
>
> a link to this work would be nice :-) ,
>
> Regards,
> Werner
>
>> -----Original Message-----
>> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
>> Sent: Thursday, October 16, 2008 8:37 AM
>> To: Dennis Sosnoski
>> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
>> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
>> 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
>> <dm...@sosnoski.com> 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
>> paul@wso2.com
>>
>> "Oxygenating the Web Service Platform", www.wso2.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>
>>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
******************* BITTE BEACHTEN *******************
Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
Ausschluss jeder Reproduktion zu zerstören und die absendende Person
umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Isuru Suriarachchi <is...@gmail.com>.
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 <pz...@gmail.com> 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)
> <we...@nsn.com> wrote:
> > Paul,
> >
> > a link to this work would be nice :-) ,
> >
> > Regards,
> > Werner
> >
> >> -----Original Message-----
> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
> >> Sent: Thursday, October 16, 2008 8:37 AM
> >> To: Dennis Sosnoski
> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
> >> 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
> >> <dm...@sosnoski.com> 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
> >> paul@wso2.com
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: WSS4J 1.5.4 Encryption Performance Question
Posted by Isuru Suriarachchi <is...@gmail.com>.
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 <pz...@gmail.com> 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)
> <we...@nsn.com> wrote:
> > Paul,
> >
> > a link to this work would be nice :-) ,
> >
> > Regards,
> > Werner
> >
> >> -----Original Message-----
> >> From: ext Paul Fremantle [mailto:pzfreo@gmail.com]
> >> Sent: Thursday, October 16, 2008 8:37 AM
> >> To: Dennis Sosnoski
> >> Cc: Colm O hEigeartaigh; Werner Dittmann; jimmy Zhang;
> >> smmtech@sbcglobal.net; wss4j-dev@ws.apache.org; saliya@wso2.com
> >> 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
> >> <dm...@sosnoski.com> 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
> >> paul@wso2.com
> >>
> >> "Oxygenating the Web Service Platform", www.wso2.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >>
> >>
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>