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 doesn’t match I set the password to
current password + “bad” just to make it different causing the message to be
rejected.

 

I don’t like it but I really saw no other choice and don’t understand why
WSS4J didn’t 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.

 

It works and I can store passwords as hashes and be interoperable with the
WS-Trust standard.

 

Brian

 

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?
It’s 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

Reply via email to