OK, I just debugged the Metro source code to determine how they can read the Tomcat tomcat-users.xml file in order to do validation of UsernameToken passwords.
Basically, if no sc:ValidatorConfiguration defined in the service-side WSDL: https://github.com/gmazza/blog-samples/blob/master/metro_usernametoken_profile/service/src/main/resources/DoubleIt.wsdl#L89 Then, the conditional at Metro's DefaultSecurityEnvironmentImpl.authenticateUser() line #1167 will not be met: http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.metro/webservices-rt/2.2.1-1/com/sun/xml/wss/impl/misc/DefaultSecurityEnvironmentImpl.java#1167 ...and hence the line at 1173 (to check the Tomcat password file) is done instead, in class DefaultRealmAuthenticationAdapter.authenticate(): http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish.metro/webservices-rt/2.2.1-1/com/sun/xml/wss/impl/misc/DefaultRealmAuthenticationAdapter.java#DefaultRealmAuthenticationAdapter.authenticate%28javax.security.auth.Subject%2Cjava.lang.String%2Cjava.lang.String%29 As you can see from the above class, Metro can do this for Tomcat and GlassFish only, not all servlet containers; furthermore it just relies on system variables to hunt down the location of the tomcat-users.xml and read usernames and passwords from it. (For GlassFish, as shown in that same class, it attempts to load a GlassFish callback handler of some sort, instead of reading a file.) Glen -- View this message in context: http://cxf.547215.n5.nabble.com/Container-validation-of-UsernameToken-passwords-tp5719516p5720335.html Sent from the cxf-dev mailing list archive at Nabble.com.
