cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mayank Mishra <>
Subject Re: Symmetric, UserToken encryption and signature
Date Mon, 17 Dec 2007 10:27:15 GMT
I am assuming you are using WSS4J only with CXF and not Rampart.

qvall wrote:
> I've been struggling with that for a while and I've failed. Is there any way
> to use symmetric (especially usertoken) key to mentioned operations?
For Symmetric Binding, (assuming you want to use behavior same as 
SignatureToken and EncryptionToken) you require to use the specify same 
Signature and Encryption Key Identifier strategy on the client and 
server (both Signature and Encryption KI Strategies will be same in case 
you require behavior as of Protection token)

Also, the same applies for CryptoProperties (read as Crypto Properties 
instead of Key Identifier Strategies).

Also IMO, Username Tokens are not suppose to do Integrity and 
Confidentiality operations as their entropies very low. Hence, above can 
very well be used with X509 Certificates.

>  I've
> found out that WSS specification allows this but does CXF support this
> somehow? I have tried to do something with embeddedKey but google doesn't
> provide much information how to use it. 

> Anyway there is a couple of examples how to achieve this using asymetric
> keys. As far as i understand (correct me if I'm wrong) there is no way of
> delivering public key for encryption other than knowing public key in
> advance (there is SAML and Kerberos but that would be overuse for my
> purposes). 
This can work if you use WS-Trust implementation.
Public key is reference inside the message in case of using internal 
DirectReference KI for Signature operations and X509KeyIdentifier KI for 
Encryption operations.
> Or maybe there is a way to cache key if i'm using only signed request as
> well as signed and encrypted response). I'm wondering what is the point in
> managing this all keys mess in case your web service is used only inside a
> company and when you can use credentials from database. The latter way looks
> rather more transparent and doesn't require adding yet another public key to
> server keystore when new client is made.

It is fair and practical assumption that a client can add public key of 
server hosting the service it require to consume in it's truststore. But 
server adding client's public key is a bad assumption.

With Regards,

View raw message