> 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).
The TransportToken assertion should be handled by the TransportBindingHandler. Or do you have a use-case where the TransportToken appears independently of the TransportBinding? > 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? I don't really understand the question. For the case that you are using the Transport Binding, then you can just assert the SignedSupportingTokens policy as the request is signed by the Transport layer. For the other bindings, your token interceptors would require some work to first add the token to the security header of the request, and then pass the WSEncryptionParts that reference the token to the binding handlers for signing, the latter would need to be updated to handle this scenario. Colm. On Mon, Mar 16, 2015 at 10:55 PM, dhogan <[email protected]> wrote: > 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. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
