Werner, thanks for the reply.  

My intent was for client to send username token that
has been both signed and encypted:

I have included segements of the client and
server-side .wsdd files that I use to configure Axis
and WSS4J.  

Please let me know if I need to include more info.

Here is my client-side.wsdd:


<deployment xmlns="http://xml.apache.org/axis/wsdd/";
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java";>
 <transport name="http"
pivot="java:org.apache.axis.transport.http.HTTPSender"/>
  <globalConfiguration >
   <requestFlow >
    <handler
type="java:org.apache.ws.axis.security.WSDoAllSender"
>
          <parameter name="action"
value="UsernameTokenSignature Encrypt"/>
      <parameter name="passwordCallbackClass"
value="com.fnf.xes.framework.axis.security.client.PWClientCallback"/>
      <parameter name="passwordType"
value="PasswordText" />          
      <parameter name="addUTElements" value="Nonce
Created" />
      <parameter name="encryptionPropFile"
value="crypto.client.properties" />
      <parameter name="encryptionKeyIdentifier"
value="X509KeyIdentifier" />            
      <parameter name="encryptionUser"
value="xespublickey" />
      <parameter name="encryptionParts" 
       
value="{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken";
/>                      
    </handler>
     <requestFlow> 
       <handler type="soapmonitor"/> 
     </requestFlow> 
     <responseFlow> 
       <handler type="soapmonitor"/> 
     </responseFlow> 
   </requestFlow >
  </globalConfiguration >
</deployment>


Here is the corresponding server-side.wsdd config:

   ...
 <service name="IFXService2" provider="java:MSG"
style="message" use="literal"> 
  <requestFlow name="XESSecurity">
   <handler
type="java:org.apache.ws.axis.security.WSDoAllReceiver">
    <parameter name="passwordCallbackClass"
value="com.fnf.xes.framework.axis.security.server.PWServerCallback"/>
        <parameter name="action"
value="UsernameTokenSignature UsernameToken Encrypt"/>

    <parameter name="decryptionPropFile"
value="crypto.server.properties"/>
   </handler>
  </requestFlow>
    ...



--- "Dittmann, Werner" <[EMAIL PROTECTED]>
wrote:

> Shawn,
> 
> because you mention the WSDoAllReceiver I assume you
> 
> are talking from a server's perpective.
> 
> What is encrypted and/or signed depends on the
> setting
> of the client and how the client creates the
> request. 
> 
> Thus to answer the question and give you some help
> we would need how the request is created, in which
> order, what are the parameters the control the
> signature / encryption.
> 
> Regards,
> Werner
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Shawn McKinney [mailto:[EMAIL PROTECTED]
> 
> > Gesendet: Donnerstag, 21. Juli 2005 20:41
> > An: [email protected]
> > Betreff: WSDoAllReceiver Question
> > 
> > 
> > 
> > Greetings,
> > 
> > We're running Soap transactions through Axis w/
> WSS4J
> > WSDoAllReceiver handler enabled.  With action
> defined
> > as below:
> > 
> > <parameter name="action" 
> > value="UsernameTokenSignature UsernameToken
> Encrypt"/>
> > 
> > I've had success running very simple message-style
> > transactions through with user creds passed via
> > username token.  Furthermore the username token is
> > signed and encrypted. (obviously)
> > 
> > My problem comes when I vary the Soap payload,
> passing
> > an IFX-style instead of simple xml.  In this case,
> the
> > signature validation fails on the receiving end.
> >   
> > However, when I vary the payload back to a simple
> > "hello-world" style of message, the  signature
> > validation succeeds.  ( same client, same service
> )
> > 
> > My question - Is the action as defined above,
> > digitally signing the username token only, or the
> > entire Soap payload?
> > 
> > If it is validating the username token only, why
> would
> > the signature fail when I pass bigger, more
> complex
> > xml documents through?
> > 
> > With the IFX Soap payload senario, when I change
> > action to:
> > <parameter name="action" value="UsernameToken
> > Encrypt"/>
> > 
> > Then transaction runs successfully.  So it seems
> that
> > this problem is limited in scope to the digital
> sig
> > processing. 
> > 
> > Thanks,
> > 
> > Shawn
> > 
> 

Reply via email to