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.
