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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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.
