Ron,
at the receiver the order of elements during parsing and
processing is not important.
According to the exception thrown it seems that you
don't have a Signature crypto file specified in the
WSDD (or otherwise) (parameter "signaturePropFile") or
the properties inside the sig-prop file are invalid.
Regards,
Werner
Nachricht
Von: Ron Reynolds [mailto:Ron (AT) RonReynolds (DOT) com]
Gesendet: Donnerstag, 1. Dezember 2005 23:17
An: wss4j-dev (AT) ws (DOT) apache.org
Betreff: No crypto protery file supplied to verify signature
i am so close to getting my C# (WSE 3.0) client to connect to
my Axis 1.2.1 +
WSS4J server. i finally (i think) got all the C# issues
worked out and now
i'm back on the Java side with this -
1201:14:02:43 DEBUG
:Verify XML Signature
1201:14:02:43 DEBUG
seRSA :Created
SignatureDSA using SHA1withRSA
1201:14:02:43 DEBUG
:Token reference
uri: #
1201:14:02:43 DEBUG org.apache.axis.EXCEPTINS :AxisFault:
WSDoAllReceiver: security processing failed; nested exception is:
General
security error
(WSSecurityEngine: No crypto protery file supplied to verify
signature)
at
(WSDoAllRece
iver.java:160)
i looked up what has Id "SecurityToken-7b111" - it's a
very long 1-line
element
<wsse:BinarySecurityToken
ValueType="
-wss-x509-token-profile-1.0#X509v3"
EncodingType="
#Base64Binary"
xmlns:wsu="
"
wsu:Id="">MI
IBjzAz/lA==</wsse:BinarySecurityToken>
that appears between the <wsse:UsernameTokenand the
<Signatureelements.
i remember there was a discussion recently about the order of security
elements being very important to WSS4J - is this related to that?
i'll start adding debug elements to my wss4j source, but just
in case someone
already knows this one i thought i'd ask.
any help will be greatly appreciated.
ron.
To unsubscribe, e-mail: wss4j-dev-unsubscribe (AT) ws (DOT) apache.org
For additional commands, e-mail: wss4j-dev-help (AT) ws (DOT) apache.org
To unsubscribe, e-mail: wss4j-dev-unsubscribe (AT) ws (DOT) apache.org
For additional commands, e-mail: wss4j-dev-help (AT) ws (DOT) apache.org

it appears that the sigCrypto wasn't being set up properly because of a
mismatch with the doAction bits - i had 2 <handler type="WSDoAllReceiver">
elements in my server-config.wsdd (because i had different actors for
UsernameToken and Signature), but when i removed the actors from my
UsernameToken and Signature elements (because (a) they added no value that i
know of and (b) i was having a hell of a time trying to add an actor attribute
to the elements in the C# client) i forgot to consolidate my <handler>
elements into 1 element with actions "UsernameToken Timestamp Signature".

so now get "security processing failed (actions mismatch)" which sounds
familiar after adding a little logging i see:

action-id result-action-id
UT (1) SIG
TS (32) UT
SIG(2) TS

so the results of processing are in a different order than the actions entries
themselves? the actions entry order is dictated by the order that appears in
the server-config.wsdd - changing it fixed the C# client, but, you guessed it,
broke the Java one. :-/

now that previous email makes sense - WSDoAllReceiver.invoke() is too big - if
it were broken up by processing action we could sub-class it and change just
the bit that needs fixing and not have to worry as much about upgrades. was
there ever a non-invasive fix to this sequencing issue found? is the order
really that important? i don't think i can reorder the actions on my Java
client side to match the C# order, can i?

ron.

Ron,

at the receiver the order of elements during parsing and
processing is not important.

According to the exception thrown it seems that you
don't have a Signature crypto file specified in the
WSDD (or otherwise) (parameter "signaturePropFile") or
the properties inside the sig-prop file are invalid.

Regards,
Werner

To unsubscribe, e-mail: wss4j-dev-unsubscribe (AT) ws (DOT) apache.org
For additional commands, e-mail: wss4j-dev-help (AT) ws (DOT) apache.org

Rin,

which WSS4J version do you use? In the SVN Head we already broke up
some parts of the handler. In WSDoAllReceiver of the latest SVN version
there is one call to ceckReceiverResults(). You may just copy/paste
the whole invoke() (its about 300 lines) in you new subclass and comment
this call.

The check of "order of actions" is a left over from the very beginnings
of WSSS4J when we implemented one of the first WSS specs (back in 2003).

Currently we are thinking about to introduce a better way to specify
the security stuff, using WS-Poliy / WS-SecurityPolicy. But this will
take some time.

Regards,
Werner

Ron Reynolds wrote:
it appears that the sigCrypto wasn't being set up properly because of a
mismatch with the doAction bits - i had 2 <handler type="WSDoAllReceiver">
elements in my server-config.wsdd (because i had different actors for
UsernameToken and Signature), but when i removed the actors from my
UsernameToken and Signature elements (because (a) they added no value that i
know of and (b) i was having a hell of a time trying to add an actor attribute
to the elements in the C# client) i forgot to consolidate my <handler>
elements into 1 element with actions "UsernameToken Timestamp Signature".

so now get "security processing failed (actions mismatch)" which sounds
familiar after adding a little logging i see:

action-id result-action-id
UT (1) SIG
TS (32) UT
SIG(2) TS

so the results of processing are in a different order than the actions entries
themselves? the actions entry order is dictated by the order that appears in
the server-config.wsdd - changing it fixed the C# client, but, you guessed it,
broke the Java one. :-/

now that previous email makes sense - WSDoAllReceiver.invoke() is too big - if
it were broken up by processing action we could sub-class it and change just
the bit that needs fixing and not have to worry as much about upgrades. was
there ever a non-invasive fix to this sequencing issue found? is the order
really that important? i don't think i can reorder the actions on my Java
client side to match the C# order, can i?

ron.


>>Ron,
>>
>>at the receiver the order of elements during parsing and
>>processing is not important.
>>
>>According to the exception thrown it seems that you
>>don't have a Signature crypto file specified in the
>>WSDD (or otherwise) (parameter "signaturePropFile") or
>>the properties inside the sig-prop file are invalid.
>>
>>Regards,
>>Werner
>>

To unsubscribe, e-mail: wss4j-dev-unsubscribe (AT) ws (DOT) apache.org
For additional commands, e-mail: wss4j-dev-help (AT) ws (DOT) apache.org

To unsubscribe, e-mail: wss4j-dev-unsubscribe (AT) ws (DOT) apache.org
For additional commands, e-mail: wss4j-dev-help (AT) ws (DOT) apache.org