Hi Colm- I am back on CXF 2.7.8 - I ran into https://issues.apache.org/jira/browse/CXF-5894, and did not have the option of updating my jaxb dependencies.
I have things working with the older cxf/wss4j library set, but I have a few questions: Regarding subclassing AbstractTokenInterceptor, much of my implementation was modeled after the org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor. I noted how the UsernameTokenInterceptor asserts the SUPPORTING_TOKEN and SIGNED_SUPPORTING_TOKEN, and I do the same in my AbstractTokenInterceptor subclass, but assert SUPPORTING_TOKEN and TRANSPORT_TOKEN (when isTLSInUse). I have not had the time to go after the symmetric/asymmetric binding with custom tokens - I’m hoping that the transport binding will be sufficient. Do you suggest subclassing a different class when handling non-bare SupportingTokens? So the logic in the UsernameTokenInterceptor (and in the AbstractTokenInterceptor) asserting the SIGNED_SUPPORTING_TOKEN would never really be engaged in an outbound request (addToken case) when a symmetric/asymmetric/transport binding were in the policy? Finally, one change in the cxf-3.04->cxf-2.7.8 change perplexes me: the org.apache.cxf.ws.security.policy.model.Token#serialize method (inherited via the org.apache.neethi.Assertion interface). It is never called for my Token subclass. Searching the source, I see it called from ‘higher-level’ SecurityPolicy abstractions - e.g. the TransportBinding, TransportToken, or RecipientSignatureToken, etc. Perhaps this is part of the answer to my question at the end of the previous paragraph: the functionality of AbstractTokenInterceptor#addToken is handled by the Token#serialize methods when standard tokens are presented as part of the symmetric/asymmetric/transport binding? And my subclassing of the AbstractTokenInterceptor and commenting-out of the WSS4JInInterceptor.SECURITY_PROCESSED (server-side interceptor) and PolicyBasedWSS4JOutInterceptor.SECURITY_PROCESSED (client-side interceptor) is not a dirty hack because custom token types are more difficult to integrate into the standard bindings, and thus are best handled as AbstractTokenInterceptor subclasses? So it would be OK to e.g. throw an IllegalStateException in the serialize method of my custom assertion, pending the more profound integration necessary to support e.g. a SignedSupportingToken in a symmetric/asymmetric binding? Apologies for the cascade of questions, but getting things working is one thing - actually understanding (somewhat) is another thing altogether. Thanks Dirk -- View this message in context: http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755146.html Sent from the cxf-user mailing list archive at Nabble.com.
