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: https://github.com/gmazza/blog-samples/blob/master/metro_usernametoken_profile/service/src/main/resources/DoubleIt.wsdl#L89 , Metro transparently switches to container validation instead -- in my case, the tomcat-users.xml file: http://www.jroller.com/gmazza/entry/ssl_for_web_services#SSL5 . 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: https://github.com/gmazza/blog-samples/blob/master/cxf_usernametoken_profile/war/src/main/webapp/WEB-INF/cxf-servlet.xml#L19. 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: http://cxf.547215.n5.nabble.com/Container-validation-of-UsernameToken-passwords-tp5719516.html Sent from the cxf-dev mailing list archive at Nabble.com.
