axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Isuru Suriarachchi" <isur...@gmail.com>
Subject Re: WSS4J 1.5.4 Encryption Performance Question
Date Thu, 16 Oct 2008 16:14:28 GMT
Hi Werner,

On Thu, Oct 16, 2008 at 9:38 PM, Isuru Suriarachchi <isurues@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 <pzfreo@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> 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
>>> >> <dms@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
>>>
>>>
>>
>

Mime
View raw message