The is no client public key in the truststore of the server in this
article, because the issuer of the client's public key is in the truststore
(or keystore in this article):
But in this demo we do not need any truststore. You may be wondering,
why? Well, in simple cases, like this demo, we
If in request message there is timestamp validate it
If in request message there is no timestamp just handle this message
without
validation.
The old way of configuring WS-Security which you are using is not flexible
to handle this scenario. You need to switch to using WS-SecurityPolicy:
I don't think there is a way to handle this at the moment. You could plug
in a custom Validator for (WS-Security) UsernameTokens and do some
container-specific validation I guess.
Colm.
On Fri, Nov 30, 2012 at 4:51 PM, Glen Mazza glen.ma...@gmail.com wrote:
Hi folks, I just confirmed by
Will configuring WSS4JInInterceptor to skip validating the token
(ws-security.validate.token property set to false) and using
JAASLoginInterceptor do it ?
http://cxf.apache.org/docs/security.html#Security-JAASLoginInterceptor
This path might work for UT only I guess
Cheers, Sergey
On
Just FYI another related discussion:
http://mail-archives.apache.org/mod_mbox/cxf-users/200903.mbox/%3c200903061306.02909.dk...@apache.org%3E
My conclusion is this is JAXWS spec. problem.
I found nice blog what users can do in this particular use case:
