Customise faults thrown from Ws Security

[Jason Pell <ja...@pellcorp.com>]

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.

Re: Customise faults thrown from Ws Security

[ja...@gmail.com]

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, <ja...@gmail.com> 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" <dk...@apache.org> wrote:
>
>>
>> On Oct 15, 2012, at 2:27 PM, jasonmpell@gmail.com 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, <ja...@gmail.com> 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" <dk...@apache.org> wrote:
>> >>
>> >>>
>> >>> On Oct 15, 2012, at 6:21 AM, Jason Pell <ja...@pellcorp.com> 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
>> >>> dkulp@apache.org - http://dankulp.com/blog
>> >>> Talend Community Coder - http://coders.talend.com
>> >>>
>> >>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>

Re: Customise faults thrown from Ws Security

[ja...@gmail.com]

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" <dk...@apache.org> wrote:

>
> On Oct 15, 2012, at 2:27 PM, jasonmpell@gmail.com 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, <ja...@gmail.com> 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" <dk...@apache.org> wrote:
> >>
> >>>
> >>> On Oct 15, 2012, at 6:21 AM, Jason Pell <ja...@pellcorp.com> 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
> >>> dkulp@apache.org - http://dankulp.com/blog
> >>> Talend Community Coder - http://coders.talend.com
> >>>
> >>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: Customise faults thrown from Ws Security

[Daniel Kulp <dk...@apache.org>]

On Oct 15, 2012, at 2:27 PM, jasonmpell@gmail.com 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, <ja...@gmail.com> 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" <dk...@apache.org> wrote:
>> 
>>> 
>>> On Oct 15, 2012, at 6:21 AM, Jason Pell <ja...@pellcorp.com> 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
>>> dkulp@apache.org - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>> 
>>> 

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: Customise faults thrown from Ws Security

[ja...@gmail.com]

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

Sent from my Galaxy S2
On Oct 16, 2012 5:15 AM, <ja...@gmail.com> 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" <dk...@apache.org> wrote:
>
>>
>> On Oct 15, 2012, at 6:21 AM, Jason Pell <ja...@pellcorp.com> 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
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>

Re: Customise faults thrown from Ws Security

[ja...@gmail.com]

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" <dk...@apache.org> wrote:

>
> On Oct 15, 2012, at 6:21 AM, Jason Pell <ja...@pellcorp.com> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>

Re: Customise faults thrown from Ws Security

[Daniel Kulp <dk...@apache.org>]

On Oct 15, 2012, at 6:21 AM, Jason Pell <ja...@pellcorp.com> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com