I'm not sure what deployment descriptors you are referring at. The WSS
1.1 spec specifies how to derive a key from a UsernameToken
http://www.oasis-open.org/committees/download.php/15252/oasis-wss-username-token-profile-1.1.pdf
But it is based on wsse11:Salt and wss11:Iteration elements, something
that WSE 2.0SP3 and WSS4J 1.1 does not use.
I found the code that generates the secret key in WSS4J
(org.apache.ws.security.message.token.UsernameToken), but what is this
code based on? I could not find anything on the Internet on how WSE
implements username signing. Please confirm that this code has not been
tested successfully with WSE 2.0SP3. Thanks.
Dittmann, Werner wrote:
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
|
begin:vcard
fn:Rami Jaamour
n:Jaamour;Rami
org:Parasoft;Professional Services
adr:;;101 E. Huntington Dr.;Monrovia;CA;91016;USA
email;internet:[EMAIL PROTECTED]
title:Solution Engineer
tel;work:626-256-3680 Ext. 1217
x-mozilla-html:TRUE
url:http://www.parasoft.com/
version:2.1
end:vcard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
