All,
the implememtation of this WSE specific stuuf is based on
some
information that is floating around in the internet. I''ve
not checked
if this is adressed in the WSS 1.1spec.
However, pls have a look at the deployment files of the
interop scenario 2a
in the interop directory. Make sure you look at the
client _and_ the server
deployment because the Usernametoken signature actually is
a "2-step"
action on the client side that generates a Usernametoken
and a Signature.
The server (or receiver) action setting has to take
care about this fact.
WSS4J 1.1 does not support the feature to encrypt the body
with the
key dereived from the Usernametoken. This will (probably)
implemented
with the Policy Language enhanced version if the Policy
Language spec
becomes somewhat more stable (and readable :-)
)
Regards,
Werner
I am a problem similar to Paul. I am using WSS4J (1.1 9/4/05
release) on the client side to generate a signature using a Username Token to
invoke a .NET service (WSE 2.0 SP3). The .NET service rejects WSS4J's requests
with:
SOAP Fault:
faultCode: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}FailedCheck
faultString:
Microsoft.Web.Services2.Security.SecurityFault: The signature or decryption
was invalid
at
Microsoft.Web.Services2.Security.Security.LoadXml(XmlElement
element)
at
Microsoft.Web.Services2.Security.SecurityInputFilter.ProcessMessage(SoapEnvelope
envelope)
at
Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope
envelope)
at
Microsoft.Web.Services2.WebServicesExtension.BeforeDeserializeServer(SoapServerMessage
message)
faultActor: http://goldfish.parasoft.com:8000/utsign/UTVerifySign.asmx
This
is the same kind of error that WSE returns when the signature validation fails
due to a digest mismatch. Signed messages from a similar .NET client succeed,
and WSS4J correctly verifies the UT signature it generates. I did not test
WSS4J verifying a signature from a .NET client, but there seems to be an
interop issue here.
I read a few emails on this subject dated between
5/17/05 and 5/18/05:
Sometime ago we had a similar problem because .NET/WSE
uses a proprietary mechanism to generate a Signature with a
Signature key that is constructed from data in UsernameToken -
we inserted this algo, pls refer to UsernameTokenSignature
(last weekend I updated some inline doc about this topic, pls
chek the CVS mail here in the list). However, no official interop
was done for this, support is weak because of weak documention,
and so on.
Was there anything new since then? Where are
these inline docs that are references here? Did anybody get this scenario to
work with .NET?
Where can I find info on how .NET exactly performs the
UT signing so I look into this issue?
Thanks,
Rami Jaamour
Software Engineer - Service Oriented Architecture Solutions
Parasoft Corporation email: [EMAIL PROTECTED]
101 E. Huntington Ave. voice: (626) 256-3680 ext. 1217
Monrovia, CA. 91016 fax : (626) 256-6884
"We Make Software Work"
Ruchith Fernando wrote:
Hi Paul,
This scenario includes secure conversation and right now you cannot
use WSS4J to do this.
But wss4j + addressing supports the first two actions:
- The ws-addressing elements must be included in the header
- Authentication with UsernameToken, Password Option=SendHashed
(aka – PasswordDigest).
Thanks,
Ruchith
On 2/1/06, Paul Grassi <[EMAIL PROTECTED]> wrote:
I need to call a .NET service using the following semantics.
- The ws-addressing elements must be included in the header
- Authentication with UsernameToken, Password Option=SendHashed
(aka – PasswordDigest).
- 2 DerivedKeyTokens, from ws-secureconversation, be created, based
off of the UsernameToken (using P_SHA1)
- The message signed with DerivedKeyToken #1 (using HMAC-SHA1)
- The message body encrypted using DerivedKeyToken #2 (using
aes128-cbc)
Does wss4j support this? I know the ws-addressing and ws-secureconversation
implementations in Java are in their infancy. I am hoping Apache has
progressed further than Sun.
Paul
Paul Grassi | Iditarod Systems
Voice: 703.637.8825 Fax: 703.637.8830
