Shawn,
its the rigth track IMO.
Perfect if you do the actions:
UsernameTokenSignature Encrypt
and use your setting to encrypt the UsernameToken.
This is the way it usually works. If someone tampers with
the encrypted UsernameToken data the decryption will fail
most probably.
Then let UsernamenTokenSignature sign the SOAP body (the
complete body) or a part thereof. I've never tried to sign
a part - maybe you can look into the interop scenarios. There
could be one scenario that signs a particual element inside
the SOAP body. If you sign the whole body you don't need to
specifiy this in the deployment file - it's the default setting.
BTW, there is no much additional processing overhead if you
sign the whole body or only a part of it.
The element to sign or to encrypt must be inside the
SOAP _envelope_. And the element must exist in the request
(the XML data / DOM representation of the request) before
you try to sign the element. This is usually automatically
true if the WSS4J handler ist the last one in the handler chain
at the client (sender) side. In this case Axis hands over
the complete request built up so far to the WSS4J handler.
Using the Signature you are sure nobody tampered with the
SOAP body or element you defined.
I've no idea if a wrong schema can trigger the Signature
processing/verification to fail - I'm not an expert in
Signature / XML Schema handling.
Regards,
Werner
Shawn McKinney schrieb:
Werner,
Perhaps I'm going about all this wrong. What I really
wanted, was assurance that the message originator is
as claimed and the token was not tampered with.
I thought that signing and encrypting the username
token was a convenient means to to this, but... I was
confused on the sequence and semantics of this
operation.
I should perhaps still use the username token to sign
an element, but sign something other than username
token itself.
Furthermore, this element that I sign should reside in
the SOAP body. ?
This way I still have assurance that the token was not
tampered with, and the originator is as claimed, but I
avoid the consequences of a chicken & egg senario.
Am I starting to track right here? ( finally )
--- Werner Dittmann <[EMAIL PROTECTED]>
wrote:
Shawn,
this is the way (the sequence) the WSS4J handler for
Axis
is performing. Not anything you have to deal with.
The problem is some sort of a chicken and egg
problem
- first we the the UsernameToken to perform
Signature
based on UsernameToekn
- but UsernameToken must be inserted into request
_after_
the Signature processing.
Thus the WSS4J handler creates a half backed
USernameTokne, uses
this to perform Signature, the finishes the
UsernameToken and
insertes it into the request.
If you really need to sign the UsernameToken with
itself we
have to solve this chicken/egg problem in some other
way.
Regards,
Werner
Shawn McKinney schrieb:
Werner, still confused -
- first create the UsernameToken as internal DOM
element with all
Do I do this with my own custom handler? A
handler
that must fire before the DoAllSender?
internal DOM element with all necessary data.
- username
-password
-timestamp
- etc
Then do I configure the DoAllSender like this:
<globalConfiguration >
<requestFlow >
<handler
type="java:my.new.custom.username.token.handler"/>
<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 >
Then, my server-side will work the way I had it
originally configured, because then DoAllReceiver
handler has everything it needs to complete the
signature and encryption processing. ???
Thanks Werner, this is helping a great deal!
