What's the stacktrace of the exception? I would expect it to fail on the BST in the security header, and disabling BSP validation should work there.
Colm. On Thu, Jul 27, 2017 at 2:03 AM, NicholaiX <[email protected]> wrote: > Thanks Colm, > > Actually it's an entire different namespace, not just the capitalization of > the suffix: > > > EncodingType="http://docs.oasis-open.org/wss/2004/01/ > oasis-200401-wss-wssecurity-secext-1.0.xsd#base64binary"> > > Note the secext namespace rather than the expected one. > > And yes, it's different than the spec. How would I proceed? > > As a side node, when I was using a regular cxf endpoint, I was able to set > is-bsp-compliant to false to suppress the validation, in hopes I can > intercept it later. But that suppression does not seem to work when using > STS. > > At this point, my needs are fairly basic, so I can use STS or just a > regular > CXF soap endpoint, but I'm still not clear how I should proceed in either > case. It would be helpful if I could find an example of what I need to do > to > handle a custom token in CXF 3.x, to give me an idea of which parts I > should > be prepared to write. > > > > > > -- > View this message in context: http://cxf.547215.n5.nabble. > com/STS-How-to-handle-BinarySecurityToken-when-it-s-not-as-expected- > tp5782018p5782075.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
