I got it working by getting access to soap message only. In cxf 2.7 if just using usernametoken only the binding operation info is already there so I don't need to parse the xml reader. The soap message appears to always be loaded when using wss4j interceptor
Sent from my Galaxy S2 On Oct 16, 2012 6:55 AM, <[email protected]> wrote: > We have usernametoken + transport policy with timestamp. > > I will take a look at this thanks > > Sent from my Galaxy S2 > On Oct 16, 2012 5:39 AM, "Daniel Kulp" <[email protected]> wrote: > >> >> On Oct 15, 2012, at 2:27 PM, [email protected] wrote: >> > Probably in that case I was thinking about getting access to the in >> message >> > SoapMessage and figuring out the operation based on the first element >> > inside body. It should still be there as that is what wss4j interceptor >> > uses I think >> >> Depends on the way the UsernameToken policy is defined and what other >> policies are in effect there. If there is ONLY a UsernameToken policy, >> there is a more optimized pathway that bypasses the full WSS4J handling and >> just handles the header directly. (UsernameTokenInterceptor) In this case, >> the Body may not have been read into an SAAJ model. However, you would be >> able to grab the XMLStreamReader from the in message and parse the next >> couple events to find the first child element and use that QName. >> >> Dan >> >> >> >> > Sent from my Galaxy S2 >> > On Oct 16, 2012 5:15 AM, <[email protected]> wrote: >> > >> >> Ah yep makes perfect sense for cases where body is encrypted what about >> >> when not like for usernametoken and ssl >> >> >> >> Sent from my Galaxy S2 >> >> On Oct 16, 2012 2:18 AM, "Daniel Kulp" <[email protected]> wrote: >> >> >> >>> >> >>> On Oct 15, 2012, at 6:21 AM, Jason Pell <[email protected]> wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> I have a interceptor registered to intercept exceptions thrown from >> >>>> WSS Interceptors and also the Callback to wrap them in a domain >> fault. >> >>>> However I hit a problem because the WebFaultOutInterceptor expects >> >>>> the BindingOperationInfo to be populated and this is not populated >> >>>> until DocLiteralInInterceptor is executed which is after ws security >> >>>> is populated. >> >>>> >> >>>> We are not enforcing the use of the SOAPAction which I suppose might >> >>>> solve this, but before I go there I wanted to know if it was possible >> >>>> to move the parsing of the DocLiteralInInterceptor earlier so that at >> >>>> least I know the operation name before I validate ws security. >> >>> >> >>> Likely not. If the soap:Body is encrypted, there wouldn't be a way to >> >>> determine the body until after the security stuff is handled. >> Likewise, if >> >>> there is a security exception trying to decrypt the body, there also >> >>> wouldn't be a way to determine the operation. >> >>> >> >>> >> >>> -- >> >>> Daniel Kulp >> >>> [email protected] - http://dankulp.com/blog >> >>> Talend Community Coder - http://coders.talend.com >> >>> >> >>> >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >>
