Canonicalization is definitely a time hog, especially since it's done
using a DOM - and DOMs are expensive in terms of both memory and
construction time. I've also seen that WSS4J may canonicalize the
message unnecessarily, at least in some cases.
But it seems unlike that canonicalization would be the cause of Shawn's
performance hit in this case. Shawn said his performance was not
significantly effected by turning on signing of the username token, but
was effected by encrypting the username token. Signing is the part that
requires canonicalization, not encrypting.
My own tests of Axis2 performance with WS-Security turned on have given
much worse results than reported by Shawn, but I was looking at signing
and/or encrypting the entire message.
- Dennis
Werner Dittmann wrote:
jimmy Zhang schrieb:
The latest performance reports point to canonicalization as the major
CPU eater...
that part needs to be virtually completely redone...
Wow - never thought that :-). Unfortunately we cannot influence this
part easily be changing the way how to encrypt/select keys. C14n is
nearly always needed, at least for signature and for serialization into
the real message (XML stream).
Regards,
Werner
----- Original Message ----- From: "Werner Dittmann"
<[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Friday, October 10, 2008 11:58 PM
Subject: Re: WSS4J 1.5.4 Encryption Performance Question
Shawn,
the most expensive part during encryption (and in some cases also
Signature) is the asymmetric encryption part. Several years ago (in
the beginning of WSS4J :-) ) I did some performance tests to detect
where time is lost.
I assume you use the standard way to encrypt/decrypt data, thus the
following process is used:
- get information about the public key of the receiver (usually using
the receiver's x.500 certificate)
- generate a random key that WSS4J uses to symmetrically encrypt the
content, for example the SOAP body on in your case the user name
token
- encrypt this random key a using public key algorithm, for example RSA
(which public key algo will be used depends on the contents of the
certificate)
- build up the Security header.
The step to encrypt the random key is the most expensive. Your
configuration shows that you are using UsernameTokenSignature thus you
do not do a "real" Signature using a x.500 certificate bu a specific
variant where data of the user name token is used to compute a
signature.
This explains why the signature processing is fast in your test frame.
During the tests I could speed up the public key processing by using
another security provider - Apache JuiCE which is a Java JCE wrapper
that uses openSSL as crpyto engine that gave me between 30-50% better
performance compared with bouncy castle.
Thus to speed up this you may consider using keys that do not depend on
certificates - AFAIK there is also a way to send keys using user name
token, but this needs to be confirmed.
Regards,
Werner
Shawn McKinney schrieb:
Hello,
<SNIP ---- SNAP>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
