I'm copying/pasting this from a blog posting where I first reported this issue. You can find the original problem description and interaction with the blogger here:
http://coheigea.blogspot.com/2011/11/apache-cxf-sts-documentation-part-viii_10.html?showComment=1365017694507#c377579003061518755 Here is the problem statement: <begin quote> Is there a way to configure the CXF/Talend STS to use a custom UsernameTokenValidator? The reason I ask is that I would like to call an external identity store to validate the username/password. The identity store has an interface which accepts a username and password and returns true of false depending on whether the password is correct or not. So far the only way I know to affect the behavior of the UsernameTokenValidtor is to specify a callback handler. Unfortunately, the default UsernameTokenValidator does not explicitly pass the password received from the username token to the callback handler and the identity store I am trying to work with will not return the password associated with the id (it only validates a username/password pair). While I can create a solution using the username callback handler, it is not very pretty. The solution takes advantage of the fact that while the default UsernameTokenValidator does not explicitly pass the password in the username token, it does pass the entire contents of the soap message as part of the "data" property. From that data, I can extract the SOAP message, then the WSSecurity header, then the username token, and finally the password. What I don't like about this solution is that the process of extracting the username and password is already performed by the code that invokes the callback handler. I'm doing it a second time in the callback handler, which seems wasteful. Thus, I'm wondering if I can create my own UsernameTokenValidtor and overrride the one that the CXF STS uses by default? <end quote> The original response from Colm: <begin quote> Yes, you can inject your custom WSS4J Validator implementation into the STS's UsernameTokenValidator via the "setValidator" method. See here: http://svn.apache.org/viewvc/cxf/trunk/services/sts/sts-core/src/main/java/org/apache/cxf/sts/token/validator/UsernameTokenValidator.java?view=markup <end quote> The response seemed like a plausible solution. However, while trying to implement a solution along those lines I discovered the following: <begin quote> In fact, in the debugger it looks like the only validator ever called when submitting an RST with a username token is org.apache.ws.security.validate.UsernameTokenValidtor. This despite the fact that I am using the CXF DefaultSecurityTokenProvider class. <end quote> So to summarize it would seem that the while the DefaultSecurityTokenProvider registers a validator of type org.apache.cxf.sts.token.validator.UsernameTokenValidator this never gets used. Instead, org.apache.ws.security.validate.UsernameTokenValidtor is used. This seems strange to me. Is it expected behavior? My configuration is Talend v5.2.2. Specifically, I am hosting the STS in a bundle on Karaf version 2.2.9, I am using CXF version 2.7.3, Camel 2.10.2, and Jetty version 7.6.7v20120910 -- View this message in context: http://cxf.547215.n5.nabble.com/DefaultSecurityTokenServiceProvider-does-not-use-CXF-UsernameTokenValidator-tp5725849.html Sent from the cxf-user mailing list archive at Nabble.com.