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
