>It's asserted via "policyAsserted(transportToken);" in the >TransportBindingHandler.
A bit of context: I am setting my custom AssertionBuilder and PolicyInterceptorProvider with the bus associated with my STS client, and with the bus associated with my STS instance. I saw this call to policyAsserted, but the surrounding branch is never entered, as the Token returned from the transportTokenWrapper is an instance of the HttpsToken class, which is not an IssuedToken subclass. When I step through the TransportBindingHandler#handleNonEndorsingSupportingTokens method, I can see my custom token in the tokens ArrayList in the SupportingToken (line 207), so it is definitely being included. I can also see a BST containing my custom assertion in the RST invocation, which my registered policy interceptors on my STS can extract and validate. >I would put a breakpoint in WSS4J's SupportingTokens.parseNestedPolicy to see what is going on. I don't see a SupportingTokens class in wss4j 1.6.13, and the SupportingToken class in cxf 2.7.8 does not have a parseNestedPolicy method. What am I missing? Thanks Dirk -- View this message in context: http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755272.html Sent from the cxf-user mailing list archive at Nabble.com.
