Hi Fran You must configure the processing of WS-Security headers in the RST in the jaxws:endpoint as a jaxws property called "ws-security.ut.validator".
<jaxws:endpoint id="transportSTS1" endpointName="ns1:TransportUT_Port" serviceName="ns1:SecurityTokenService" xmlns:ns1="http://docs.oasis-open.org/ws-sx/ws-trust/200512/"; wsdlLocation="/WEB-INF/wsdl/ws-trust-1.4-service.wsdl" address="/STSService" implementor="#transportSTSProviderBean"> <jaxws:properties> <entry value-ref="upCallBackHandler" key="ws-security.callback-handler"/> <entry value="com.MyUsernameTokenValidator" key="ws-security.ut.validator"/> </jaxws:properties> </jaxws:endpoint> Colm describes this also here: http://coheigea.blogspot.com/2011/06/custom-token-validation-in-apache-cxf.html Thanks Oli ------ Oliver Wulff http://owulff.blogspot.com Solution Architect Talend Application Integration Division http://www.talend.com ________________________________________ Von: Francisco Serrano [[email protected]] Gesendet: Donnerstag, 2. Februar 2012 17:49 Bis: [email protected] Betreff: Re: STS Support for digested passwords / (MD5/SHA) check. Hi Colm, We tried to extend this org.apache.cxf.sts.token.validator.UsernameTokenValidator defined in the cxf-transport.xml of Fediz IDP-STS with our custom one and replaced the bean definition ("transportUsernameTokenValidator"). Unfortunately this bean is never instantiated. Instead, the validation is always done by "org.apache.ws.security.validate.UsernameTokenValidator" which is registered by default in the WSSConfig. What is the correct way to register our own UsernameTokenValidator? Thanks in advance, Regards, Fran. El 02/02/2012, a las 15:38, Colm O hEigeartaigh escribió: > Hi, > > The CallbackHandler is only responsible for retrieving the (plaintext) > password corresponding to the username that was received. It doesn't > do any validation, that's done in the UsernameTokenValidator. > > So for the use-case where you don't have access to the plaintext > password, but instead know the hashed password to compare directly > against the received hashed password, you could implement your own > UsernameTokenValidator, and configure the CXF security runtime to use > this validator for UsernameTokens. In this case, the CallbackHandler > wouldn't retrieve any password, as it doesn't know how to access the > plaintext password. > > Colm. > > On Thu, Feb 2, 2012 at 10:03 AM, Francisco Serrano > <[email protected]> wrote: >> Hi list, >> >> We are trying to integrate the STS into our solution for SSO but we >> encountered an issue that is hard to solve. >> >> For the moment, the token validator uses a callback to be able to >> verify the correct username and password to deliver the token. >> >> The problem appears when you need to store hashed passwords and >> check. There would be needed some mechanism no to set the current password >> to the WSPasswordCallback to be verified directly against the string value >> of the password but to check it agains a hashed value. >> >> The following code is coming from the PasswordCallbackHandler: >> >> ----------------------------------------------------------------------------------------------------------------------------- >> >> public void handle(Callback[] callbacks) throws IOException, >> UnsupportedCallbackException { >> >> if (getPasswords() == null || getPasswords().size() == 0) >> return; >> >> for (int i = 0; i < callbacks.length; i++) { >> if (callbacks[i] instanceof WSPasswordCallback) { // CXF >> WSPasswordCallback pc = (WSPasswordCallback) callbacks[i]; >> >> String pw = getPasswords().get(pc.getIdentifier()); >> pc.setPassword(pw); >> } >> } >> } >> >> ----------------------------------------------------------------------------------------------------------------------------- >> >> The correct/original password and the one provided is evaluated at >> the UsernameTokenValidator >> (org.apache.ws.security.validate.UsernameTokenValidator). Method: >> verifyDigestPassword (called from the "verifyPlaintextPassword" method). >> >> ----------------------------------------------------------------------------------------------------------------------------- >> >> if (!origPassword.equals(password)) { >> throw new >> WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION); >> } >> >> ----------------------------------------------------------------------------------------------------------------------------- >> >> >> I could imagine that it could be set a flag to indicate that the >> password should be checked instead of compared and also the algorithm to be >> used for the digest check. >> >> Any suggestion about how this could/should be done? Any other idea? >> >> Thanks in advance. >> >> Fran. >> > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com >
