cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: Container validation of UsernameToken passwords?
Date Tue, 04 Dec 2012 12:14:29 GMT
Will configuring WSS4JInInterceptor to skip validating the token 
("ws-security.validate.token" property set to false) and using 
JAASLoginInterceptor do it ?

This path might work for UT only I guess

Cheers, Sergey

On 04/12/12 12:06, Colm O hEigeartaigh wrote:
> I don't think there is a way to handle this at the moment. You could plug
> in a custom Validator for (WS-Security) UsernameTokens and do some
> container-specific validation I guess.
> Colm.
> On Fri, Nov 30, 2012 at 4:51 PM, Glen Mazza<>  wrote:
>> Hi folks, I just confirmed by testing Metro w/UsernameToken over SSL
>> transport (haven't tried UT via their symmetric binding yet), that if I
>> *don't* configure a server-side password callback handler like here:
>> , Metro transparently switches to container validation instead -- in my
>> case, the tomcat-users.xml file:
>> .  The
>> validation appears to be the same validation done with SSL with basic
>> authentication, i.e., checking that the username and password exists within
>> the roles defined in the web.xml in the WAR hosting the web service.
>>   Having
>> not yet debugged the Metro source code, I'm not sure whether Metro is
>> hardcoded to be able to handle only GlassFish and Tomcat or can generically
>> do container validation with any servlet container (I would suspect the
>> latter), or what it would do for OSGi environments for that matter.
>> Is there a way to do this right now with CXF?  CXF raises "General security
>> error (WSSecurityEngine: No password callback supplied)" if I don't provide
>> a server-side password callback handler as here:
>> .
>> If not, I'm not sure if it's worth implementing--I guess it's a question of
>> how much additional benefit it would provide, the amount of effort it would
>> take to do so in a generic fashion, and risk of security vulnerabilities.
>> Regards,
>> Glen
>> --
>> View this message in context:
>> Sent from the cxf-dev mailing list archive at

View raw message