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:
http://io.typepad.com/eben_hewitt_on_java/2
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 04/12/
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 wrote:
> Hi folks, I just confirmed by testing Metro w/UsernameTo
> 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:
ht
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 hav
Here is the problem:
>
>
The "action" list must match on both the outbound and inbound sides.
Colm.
On Mon, Dec 3, 2012 at 10:14 AM, marcin.kasinski
wrote:
> My client configuration:
>
>
>class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
>
>
