According to this site
http://wso2.org/library/3733 I should be able to get the password if the type is #PasswordText. The article mentions exactly what I want to support: In the case of plain text, the behavior changes slightly. Here Rampart Engine passes both identifier and the password to the password callback handler and the callback handler does the actual validation. This is useful if the service store the hash of the passwords of clients and not the real passwords. In this case, as Rampart providing the password in the Username Token to the callback handler, it can do hashing operation on it and check the hashed value with the hashed password associated with the username. For example this is the case if the service uses LDAP to authenticate the clients. However, that is not happening and that is not what the source code seems to indicate. My service xml is as follows: <sp:SupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702";> <wsp:Policy> <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/I ncludeToken/AlwaysToRecipient"> <!-- <wsp:Policy> <sp:HashPassword/> </wsp:Policy> --> </sp:UsernameToken> </wsp:Policy> </sp:SupportingTokens> Is there something missing? There is also USERNAME_TOKEN_UNKNOWN (seems to be deprecated) which also does that. In the same article USERNAME_TOKEN does not give the password. So I am really confused and certainly am unable to obtain the password at this time. Thanks, Brian From: Brian Reinhold [mailto:brianreinh...@lampreynetworks.com] Sent: Wednesday, January 16, 2013 8:50 AM To: java-dev@axis.apache.org Subject: RE: Rampart STS Username service not returning password in callback Well, thats what I am doing for a current work a round. I am performing the hash on the client side and sending as PasswordText. However, I hope that this is supported by the WS-Trust standard so it will not cause interoperability issues. If it is possible to specify that the client use a SHA-1 in a clear text password send via WS-Policy and WS-SecurePolicy, then that will be a solution. I have not checked your blog yet but if I can do that, it will be a good solution. Still I think it would have been nice to support the option for the service to obtain the sent Password. Many simple clients are likely to only a single policy and that tends to be the clear text option. Brian From: George Stanchev [mailto:gstanc...@serena.com] Sent: Wednesday, January 16, 2013 8:38 AM To: java-dev@axis.apache.org Subject: RE: Rampart STS Username service not returning password in callback Hi Brian, Can you send the password as a digest [1] in the message and then provide the hash instead? Admitting, this will not work if youre using a different hashing algorithm than SHA-1 for your stored passwords George [1] http://blog.rampartfaq.com/2009/08/how-to-ask-for-hashed-password-in.html From: Brian Reinhold [mailto:brianreinh...@lampreynetworks.com] Sent: Tuesday, January 15, 2013 3:33 PM To: java-dev@axis.apache.org Subject: RE: Rampart STS Username service not returning password in callback Martin, I looked in the code and it stated that the callback must provide the password. This is not good for a service that does not store the password but only a password digest (for security reasons). That means the service does not know the users password and a hacker cannot obtain it by hacking into the services database. The hacker might be able to obtain a single users password hidden in TLS (unlikely) but that would be only one. The idea would be to get the password, perform the digest and if it matches the stored digest, it is okay. Set the password, otherwise err. Brian From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Tuesday, January 15, 2013 4:26 PM To: java-dev@axis.apache.org Subject: RE: Rampart STS Username service not returning password in callback Hi Brian assuming rampart implements this configuration: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> <soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing";> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri ty-secext-1.0.xsd" soapenv:mustUnderstand="1"> <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit y-utility-1.0.xsd" wsu:Id="Timestamp-12468716"> <wsu:Created>2008-06-23T13:17:13.841Z</wsu:Created> <wsu:Expires>2008-06-23T13:22:13.841Z</wsu:Expires> </wsu:Timestamp> <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit y-utility-1.0.xsd" wsu:Id="UsernameToken-31571602"> <wsse:Username>alice</wsse:Username> <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token -profile-1.0#PasswordText">bobPW</wsse:Password> </wsse:UsernameToken> </wsse:Security> <wsa:To>http://localhost:8081/axis2/services/sample01 <http://localhost:8081/axis2/services/sample01%3c/wsa:To> </wsa:To> <wsa:MessageID>urn:uuid:AEDBA74A8D1FC94B631214227032877</wsa:MessageID> <wsa:Action>urn:echo</wsa:Action> </soapenv:Header> <soapenv:Body> <ns1:echo xmlns:ns1="http://sample01.policy.samples.rampart.apache.org";> <param0>Hello world</param0> </ns1:echo> </soapenv:Body> </soapenv:Envelope> public void handle(Callback[] callbacks) throws IOException,UnsupportedCallbackException { for (int i = 0; i < callbacks.length; i++) { //When the server side need to authenticate the user WSPasswordCallback pwcb = (WSPasswordCallback)callbacks[i]; if (pwcb.getUsage() == WSPasswordCallback.USERNAME_TOKEN_UNKNOWN) { if(pwcb.getIdentifier().equals("bob") && pwcb.getPassword().equals("bobPW")) { http://wso2.org/library/3733 HTH., Martin Gainty ______________________________________________ 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: Rampart STS Username service not returning password in callback > Date: Tue, 15 Jan 2013 15:00:53 -0500 > > Has anyone else had this problem? I have a simple STS Username token request > for a SAML token where the username token is as follows: > > <wsse:UsernameToken wsu:Id="UsernameToken-ID"> > <wsse:Username>myName</wsse:Username> > <wsse:Password > Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token%0b%3 e%20-profile-1.0#PasswordText> > -profile-1.0#PasswordText">myPassword</wsse:Password> > </wsse:UsernameToken> > > > On the receive side there is a callback to verify the username token > > public void handle(Callback[] callbacks) throws IOException, > UnsupportedCallbackException > { > for(Callback callback: callbacks) > { > WSPasswordCallback cb = (WSPasswordCallback)callback; > int callbackType = cb.getUsage(); > switch(callbackType) > { > case WSPasswordCallback.USERNAME_TOKEN: > try > { > if(cb.getType().equals(WSConstants.PASSWORD_TEXT)) > { > String myPassword = cb.getPassword(); > ... > > The returned 'myPassword' is null. Any ideas why? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org > For additional commands, e-mail: java-dev-h...@axis.apache.org > _____ No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2638/6032 - Release Date: 01/14/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2638/6032 - Release Date: 01/14/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: 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: 2638/6037 - Release Date: 01/16/13
