> FINE: An exception was thrown when verifying that the effective policy for
> this request was satisfied. However, this exception will not result in a
> fault. The exception raised is: org.apache.cxf.ws.policy.PolicyException:
> These policy alternatives can not be satisfied:
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
Ok I can see what the problem is here, the token wrapper is not being
asserted in the TransportBindingHandler. This is already fixed on CXF
3.0.x. I'm not inclined to fix it for CXF 2.7.x, as it's a minor (logging)
issue.
> 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?
I was talking about CXF 3.0.x. Actually thinking about it, I think the
"serialize" stuff is not used by the security runtime.
Colm.
On Fri, Mar 20, 2015 at 3:14 PM, dhogan <[email protected]> wrote:
> Hi Colm-
> A couple of additional data points: the exact same log entries I encounter
> when consuming an STS issue protected by the OpenAMSessionToken over the
> TransportBinding are logged when I consume an STS issue protected by a UNT
> over the TransportBinding. The logs appear client-side and server-side:
>
> FINE: An exception was thrown when verifying that the effective policy for
> this request was satisfied. However, this exception will not result in a
> fault. The exception raised is: org.apache.cxf.ws.policy.PolicyException:
> These policy alternatives can not be satisfied:
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TransportToken
>
> Debugging TransportBindingHandler#handleBinding for the UNT case is the
> same
> as the OpenAMSessionToken case - the HttpsToken is not an IssuedToken, so
> the TransportToken is never asserted. I see the same logic in the 3.0.4
> TransportBindingHandler (I'm currently working on the 2.7.8 release). I
> don't see when a HttpsToken could ever be an IssuedToken.
>
> I also don't see the
> org.apache.cxf.ws.security.policy.model.UsernameToken#serialize ever being
> called, neither when the STS instance is being exposed, nor when it is
> consumed.
>
> Thanks
>
> Dirk
>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Custom-SecurityPolicy-Assertions-and-the-Symmetric-binding-tp5754879p5755303.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com