Martin,
Im not sure I follow what you are saying. Are you suggesting there is a means to accomplish the same thing (get actual sent password in the callback) without changing the code AND is compliant with WS-Trust clients? In any case, I think its an oversight by WSS4J that they require that the service must KNOW the password. In the code I see no way to avoid the issue. In all cases when the users (my) callback routine is signaled, the callback passed to the user always has the password set to null and the users callback routine is expected to provide the actual password. The latter part is okay as a means to validate the password is okay, but what WSS4J needs to do then is to provide a second routine, getSentPassword() which is the value of the sent password, clear or digested. This would allow the service to respond as it sees fit. In my case that would be storing a password digest so my service (and a successful hacker) would never be able to know the real passwords. I would do that except the callback created implements Callback which is not part of WSS4J. Changing that interface looks like it would have FAR reaching consequences. Brian From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Saturday, January 19, 2013 7:40 PM To: java-dev@axis.apache.org Subject: RE: Rampart STS Username service not returning password in callback _____ From: brianreinh...@lampreynetworks.com To: java-dev@axis.apache.org Subject: RE: Rampart STS Username service not returning password in callback Date: Sat, 19 Jan 2013 08:58:15 -0500 Hi Martin, I did something different. The problem is in WSS4J. In the UsernameTokenValidation file I simply passed the password to the callback constructor which was previously null. Now I have to change the approach a little bit. In my handler I read the password, do my hash, and if it matches my stored hash I do nothing since the password is already set. This will cause WSS4J to accept the message. If it doesnt match I set the password to current password + bad just to make it different causing the message to be rejected. I dont like it but I really saw no other choice and dont understand why WSS4J didnt give the choice. They could have added another variable rawPassword and a getter for it. This would allow the service to use the raw password for whatever purpose it needs. The user would still set password as expected by WSS4J. MG>take a look at the org.apache.ws.security.dom.message.WSSecUsernameToken getSecretKey MG>/** * getSecretKey * * After the <code>prepare()</code> method was called use this method * to compute a derived secret key. If "useDerivedKey" is set, then the returned secret * key is derived as per the UsernameToken 1.1 specification. Otherwise, the generation * of this secret key is according to the WS-Trust specifications. * * @return Return the derived secret key of this token or null if <code>prepare()</code> * was not called before. */ MG>boolean useDerivedKey is set to false initially so the secretKey coming back from WSS4J is a WS-Trust compliant secretKey MG>setting plain text Password can be accomplished with MG>setPasswordType(WSConstants#PASSWORD_TEXT) MG>setPasswordsAreEncoded(false) MG>the prepare method sets the password into the UsernameToken object (in the prepare method) MG>ut.setPassword(password); It works and I can store passwords as hashes and be interoperable with the WS-Trust standard. MG>you have a solution..and thats all that matters MG>congrats on acquiring a WS-Trust solution!..i hope the journey was pleasant and as informative for you as it was for me Brian MG>Martin From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Friday, January 18, 2013 11:24 PM To: java-dev@axis.apache.org Subject: RE: Rampart STS Username service not returning password in callback Hi Brian assume your CallbackHandler looks something like like public class PWCBHandler implements javax.security.auth.callback.CallbackHandler { public void handle(javax.security.auth.callback.Callback[] callbacks) throws IOException, javax.security.auth.callback.UnsupportedCallbackException { for (int i = 0; i < callbacks.length; i++) { org.apache.ws.security.WSPasswordCallback pwcb = (org.apache.ws.security.WSPasswordCallback)callbacks[i]; put the CallbackHandler into the Options class for the serviceClient to pickup e.g. Options options = client.getOptions(); options.put(WSHandlerConstants.PW_CALLBACK_REF, new PasswordCallbackHandler()); serviceClient.setOptions(options); try { //Blocking invocation serviceClient.sendReceive(getOMElement()); fail("Service Should throw an error.."); } catch (AxisFault axisFault) { assertEquals("Testing negative scenarios with Apache Rampart. Intentional Exception", axisFault.getMessage()); } http://wso2.org/library/3733 HTH, Martin ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. _____ From: brianreinh...@lampreynetworks.com To: java-dev@axis.apache.org Subject: RE: Rampart STS Username service not returning password in callback Date: Fri, 18 Jan 2013 12:01:19 -0500 Martin, Can you tell me where the password callback in my service gets called from? Its the password callback configured by the following line in the STS service.xml <ramp:passwordCallbackClass>com.lni.exchange.wan.receive.binding.axis2.Passw ordCallback</ramp:passwordCallbackClass> Brian From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Wednesday, January 16, 2013 5:14 PM To: java-dev@axis.apache.org Subject: RE: Rampart STS Username service not returning password in callback http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1. 0.xsd i think I found an element we can use (where both noonce and Password would be child elements of wsc:DerivedKeyToken) so here is the TestCase org.apache.rampart.handler.config.OutflowConfiguration ofc = new org.apache.rampart.handler.config.OutflowConfiguration(); ofc.setActionItems("UsernameToken Encrypt"); ofc.setUser("Mohammed"); ofc.setAddUTElements("Nonce Created"); //Noonce ofc.setEncryptionParts("{Element}{" + WSSE_NS + "}UsernameToken"); ofc.setEncryptionUser("osama"); ofc.setEncryptionPropFile("interop.properties"); ofc.setPasswordCallbackClass("org.apache.axis2.security.PWCallback"); ofc.setEncryptionSymAlgorithm(WSConstants.TRIPLE_DES); //change this to MD5 or SHA-1 ofc.setPasswordType(WSConstants.PW_TEXT); ofc.setEncryptionKeyIdentifier(WSSHandlerConstants.SKI_KEY_IDENTIFIER); //so here is the new OutFlowConfiguration Element ofc.setPassword("YadaYadaYada"); return ofc; //org.apache.rampart.handler.config.OutflowConfiguration change public void setPassword(String passwordType) { this.actionList[this.currentAction].put( WSHandlerConstants.PASSWORD, password); } //org.apache.ws.security.dom.handler.WSHandlerConstants add this element public static final String PASSWORD = "password" //correct ...why touch WSS4J for one minor update to a constant ..(maybe using constant "password" is better) //org.apache.rampart.handler.config.OutflowConfiguration change with constant public void setPassword(String passwordType) { this.actionList[this.currentAction].put( "password", password); } reference http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1. 0.xsd WDYT? Martin ></xsd: _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2638/6037 - Release Date: 01/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2638/6037 - Release Date: 01/16/13 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2639/6041 - Release Date: 01/18/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2639/6041 - Release Date: 01/18/13 _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2639/6045 - Release Date: 01/20/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2639/6045 - Release Date: 01/20/13
