You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Ted <r6...@gmail.com> on 2014/01/30 20:16:21 UTC
WSSecurityException turns into generic SOAPFaultException on client side
Hi I'm on cxf 2.7.4,
On the server, in the UsernameTokenValidator.verifyPlaintextPassword(),
if the user/password is invalid I'm throwing a
new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
The problem is on the client side, all I'm getting is :
javax.xml.ws.soap.SOAPFaultException: The security token could not
be authenticated or authorized
...
Caused by: org.apache.cxf.binding.soap.SoapFault: The security token could
not be authenticated or authorized
So I can see the logic is all working properly, however, on the client side,
short of parsing some random text "could not be authenticated" and
hoping it doesn't change, there's no way for me to determine that it
was a failed authentication v.s. any other soap fault.
i.e. on the client side I want to od (but can't do) "catch
(WSSecurityException e)".
Does anyone know if there's a configuration or something I can change
so the exception makes it over to the client side so I can properly
determine that it was actually security exception?
--
Ted.
RE: WSSecurityException turns into generic SOAPFaultException on
client side
Posted by Andrei Shakirin <as...@talend.com>.
Hi,
Is the problem recognizing of security relevant SOAP fault on the client side, correct?
If it is so, you can try to resolve this particular case using custom interceptor.
Regards,
Andrei.
> -----Original Message-----
> From: Ted [mailto:r6squeegee@gmail.com]
> Sent: Freitag, 31. Januar 2014 19:07
> To: users@cxf.apache.org; coheigea@apache.org
> Subject: Re: WSSecurityException turns into generic SOAPFaultException on
> client side
>
> I wouldn't have thought the basic WSSecurityException would have been
> that sensitive but I haven't thought it through too much.
>
> As an example if the username/password is wrong, I'd rather tell the user
> their user/password is wrong and or their session has timed out rather than
> telling the user "an error occurred on the server".
>
> Also, conversely if any other type of exception occurrs on the server (not
> sure what other off hand, just making this up) like a NullPointerException, it
> might mean there's just bad data on my server and there's no need to make
> the client re-login due to invalid user/password or timed out session etc...
>
>
>
> On 1/31/14, Colm O hEigeartaigh <co...@apache.org> wrote:
> > There is no way of returning the actual underlying exception to the
> > client, as this could leak sensitive information to an attacker. Why
> > do you need to differentiate between different exception types on the
> client end?
> >
> > Colm.
> >
> >
> > On Thu, Jan 30, 2014 at 7:16 PM, Ted <r6...@gmail.com> wrote:
> >
> >> Hi I'm on cxf 2.7.4,
> >>
> >> On the server, in the
> >> UsernameTokenValidator.verifyPlaintextPassword(),
> >> if the user/password is invalid I'm throwing a
> >> new
> WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
> >>
> >> The problem is on the client side, all I'm getting is :
> >> javax.xml.ws.soap.SOAPFaultException: The security token could not
> >> be authenticated or authorized
> >> ...
> >> Caused by: org.apache.cxf.binding.soap.SoapFault: The security
> >> token could
> >> not be authenticated or authorized
> >>
> >> So I can see the logic is all working properly, however, on the
> >> client side, short of parsing some random text "could not be
> >> authenticated" and hoping it doesn't change, there's no way for me to
> >> determine that it was a failed authentication v.s. any other soap
> >> fault.
> >>
> >> i.e. on the client side I want to od (but can't do) "catch
> >> (WSSecurityException e)".
> >>
> >> Does anyone know if there's a configuration or something I can change
> >> so the exception makes it over to the client side so I can properly
> >> determine that it was actually security exception?
> >> --
> >> Ted.
> >>
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
> --
> Ted.
Re: WSSecurityException turns into generic SOAPFaultException on
client side
Posted by Ted <r6...@gmail.com>.
Andrei : yes that's correct, can you elaborate on this a little? I'm
not sure why I would need a custom interceptor? unless you're saying
it's the client side which is converting WSSecurityException into
SoapFaultException... is that the case? I think it's done on the
server side, specifically near
WSS4JInInterceptor.createSoapFault(WSS4JInInterceptor.java:778) (in
cxf v2.7.4) or... is that the interceptor you're telling me to change?
Colm, I just has a look at the code and I'm wondering if I may not
have explained it properly. Specifically I'm looking at :
808 if (returnSecurityError) {
809 errorMessage = e.getMessage();
810 } else {
811 errorMessage = e.getSafeExceptionMessage();
812 }
Right now the client does already receives a sufficient String message
for me to determine it was a security related exception. The client
side currently receives :
javax.xml.ws.soap.SOAPFaultException: The security token could not
be authenticated or authorized
...
Caused by: org.apache.cxf.binding.soap.SoapFault: The security
token could not be authenticated or authorized
The message is already sufficient, all I wanted was to receive a
WSSecurityException instead of the SOAPFaultException/SoapFault
because I didn't want to parse the text message to determine it was a
security exception. (or at least have the WSSecurityException in the
cause chain). That's why I was unsure as to why it would cause a
security concern to throw a WSSecurityException, you wouldn't get any
more information than you already receive right now. It wouldn't even
have to be the same WSSecurityException thrown on the server side, it
could be a new one so internal information is not passed to the
client.
Ted.
On 2/4/14, Colm O hEigeartaigh <co...@apache.org> wrote:
> I've created a new JIRA (https://issues.apache.org/jira/browse/CXF-5540) to
> be fixed for CXF 3.0.0. There is a new security property
> ("ws-security.return.security.error") which defaults to false, which will
> return the underlying error message if set to true.
>
> Colm.
>
>
> On Fri, Jan 31, 2014 at 6:06 PM, Ted <r6...@gmail.com> wrote:
>
>> I wouldn't have thought the basic WSSecurityException would have been
>> that sensitive but I haven't thought it through too much.
>>
>> As an example if the username/password is wrong, I'd rather tell the
>> user their user/password is wrong and or their session has timed out
>> rather than telling the user "an error occurred on the server".
>>
>> Also, conversely if any other type of exception occurrs on the server
>> (not sure what other off hand, just making this up) like a
>> NullPointerException, it might mean there's just bad data on my server
>> and there's no need to make the client re-login due to invalid
>> user/password or timed out session etc...
>>
>>
>>
>> On 1/31/14, Colm O hEigeartaigh <co...@apache.org> wrote:
>> > There is no way of returning the actual underlying exception to the
>> client,
>> > as this could leak sensitive information to an attacker. Why do you
>> > need
>> to
>> > differentiate between different exception types on the client end?
>> >
>> > Colm.
>> >
>> >
>> > On Thu, Jan 30, 2014 at 7:16 PM, Ted <r6...@gmail.com> wrote:
>> >
>> >> Hi I'm on cxf 2.7.4,
>> >>
>> >> On the server, in the
>> >> UsernameTokenValidator.verifyPlaintextPassword(),
>> >> if the user/password is invalid I'm throwing a
>> >> new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
>> >>
>> >> The problem is on the client side, all I'm getting is :
>> >> javax.xml.ws.soap.SOAPFaultException: The security token could not
>> >> be authenticated or authorized
>> >> ...
>> >> Caused by: org.apache.cxf.binding.soap.SoapFault: The security
>> >> token
>> >> could
>> >> not be authenticated or authorized
>> >>
>> >> So I can see the logic is all working properly, however, on the client
>> >> side,
>> >> short of parsing some random text "could not be authenticated" and
>> >> hoping it doesn't change, there's no way for me to determine that it
>> >> was a failed authentication v.s. any other soap fault.
>> >>
>> >> i.e. on the client side I want to od (but can't do) "catch
>> >> (WSSecurityException e)".
>> >>
>> >> Does anyone know if there's a configuration or something I can change
>> >> so the exception makes it over to the client side so I can properly
>> >> determine that it was actually security exception?
>> >> --
>> >> Ted.
>> >>
>> >
>> >
>> >
>> > --
>> > Colm O hEigeartaigh
>> >
>> > Talend Community Coder
>> > http://coders.talend.com
>> >
>>
>>
>> --
>> Ted.
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Ted.
Re: WSSecurityException turns into generic SOAPFaultException on
client side
Posted by Colm O hEigeartaigh <co...@apache.org>.
I've created a new JIRA (https://issues.apache.org/jira/browse/CXF-5540) to
be fixed for CXF 3.0.0. There is a new security property
("ws-security.return.security.error") which defaults to false, which will
return the underlying error message if set to true.
Colm.
On Fri, Jan 31, 2014 at 6:06 PM, Ted <r6...@gmail.com> wrote:
> I wouldn't have thought the basic WSSecurityException would have been
> that sensitive but I haven't thought it through too much.
>
> As an example if the username/password is wrong, I'd rather tell the
> user their user/password is wrong and or their session has timed out
> rather than telling the user "an error occurred on the server".
>
> Also, conversely if any other type of exception occurrs on the server
> (not sure what other off hand, just making this up) like a
> NullPointerException, it might mean there's just bad data on my server
> and there's no need to make the client re-login due to invalid
> user/password or timed out session etc...
>
>
>
> On 1/31/14, Colm O hEigeartaigh <co...@apache.org> wrote:
> > There is no way of returning the actual underlying exception to the
> client,
> > as this could leak sensitive information to an attacker. Why do you need
> to
> > differentiate between different exception types on the client end?
> >
> > Colm.
> >
> >
> > On Thu, Jan 30, 2014 at 7:16 PM, Ted <r6...@gmail.com> wrote:
> >
> >> Hi I'm on cxf 2.7.4,
> >>
> >> On the server, in the UsernameTokenValidator.verifyPlaintextPassword(),
> >> if the user/password is invalid I'm throwing a
> >> new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
> >>
> >> The problem is on the client side, all I'm getting is :
> >> javax.xml.ws.soap.SOAPFaultException: The security token could not
> >> be authenticated or authorized
> >> ...
> >> Caused by: org.apache.cxf.binding.soap.SoapFault: The security token
> >> could
> >> not be authenticated or authorized
> >>
> >> So I can see the logic is all working properly, however, on the client
> >> side,
> >> short of parsing some random text "could not be authenticated" and
> >> hoping it doesn't change, there's no way for me to determine that it
> >> was a failed authentication v.s. any other soap fault.
> >>
> >> i.e. on the client side I want to od (but can't do) "catch
> >> (WSSecurityException e)".
> >>
> >> Does anyone know if there's a configuration or something I can change
> >> so the exception makes it over to the client side so I can properly
> >> determine that it was actually security exception?
> >> --
> >> Ted.
> >>
> >
> >
> >
> > --
> > Colm O hEigeartaigh
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
>
>
> --
> Ted.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: WSSecurityException turns into generic SOAPFaultException on
client side
Posted by Ted <r6...@gmail.com>.
I wouldn't have thought the basic WSSecurityException would have been
that sensitive but I haven't thought it through too much.
As an example if the username/password is wrong, I'd rather tell the
user their user/password is wrong and or their session has timed out
rather than telling the user "an error occurred on the server".
Also, conversely if any other type of exception occurrs on the server
(not sure what other off hand, just making this up) like a
NullPointerException, it might mean there's just bad data on my server
and there's no need to make the client re-login due to invalid
user/password or timed out session etc...
On 1/31/14, Colm O hEigeartaigh <co...@apache.org> wrote:
> There is no way of returning the actual underlying exception to the client,
> as this could leak sensitive information to an attacker. Why do you need to
> differentiate between different exception types on the client end?
>
> Colm.
>
>
> On Thu, Jan 30, 2014 at 7:16 PM, Ted <r6...@gmail.com> wrote:
>
>> Hi I'm on cxf 2.7.4,
>>
>> On the server, in the UsernameTokenValidator.verifyPlaintextPassword(),
>> if the user/password is invalid I'm throwing a
>> new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
>>
>> The problem is on the client side, all I'm getting is :
>> javax.xml.ws.soap.SOAPFaultException: The security token could not
>> be authenticated or authorized
>> ...
>> Caused by: org.apache.cxf.binding.soap.SoapFault: The security token
>> could
>> not be authenticated or authorized
>>
>> So I can see the logic is all working properly, however, on the client
>> side,
>> short of parsing some random text "could not be authenticated" and
>> hoping it doesn't change, there's no way for me to determine that it
>> was a failed authentication v.s. any other soap fault.
>>
>> i.e. on the client side I want to od (but can't do) "catch
>> (WSSecurityException e)".
>>
>> Does anyone know if there's a configuration or something I can change
>> so the exception makes it over to the client side so I can properly
>> determine that it was actually security exception?
>> --
>> Ted.
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Ted.
Re: WSSecurityException turns into generic SOAPFaultException on
client side
Posted by Colm O hEigeartaigh <co...@apache.org>.
There is no way of returning the actual underlying exception to the client,
as this could leak sensitive information to an attacker. Why do you need to
differentiate between different exception types on the client end?
Colm.
On Thu, Jan 30, 2014 at 7:16 PM, Ted <r6...@gmail.com> wrote:
> Hi I'm on cxf 2.7.4,
>
> On the server, in the UsernameTokenValidator.verifyPlaintextPassword(),
> if the user/password is invalid I'm throwing a
> new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
>
> The problem is on the client side, all I'm getting is :
> javax.xml.ws.soap.SOAPFaultException: The security token could not
> be authenticated or authorized
> ...
> Caused by: org.apache.cxf.binding.soap.SoapFault: The security token
> could
> not be authenticated or authorized
>
> So I can see the logic is all working properly, however, on the client
> side,
> short of parsing some random text "could not be authenticated" and
> hoping it doesn't change, there's no way for me to determine that it
> was a failed authentication v.s. any other soap fault.
>
> i.e. on the client side I want to od (but can't do) "catch
> (WSSecurityException e)".
>
> Does anyone know if there's a configuration or something I can change
> so the exception makes it over to the client side so I can properly
> determine that it was actually security exception?
> --
> Ted.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com