RE: Calling Secure .NET services with WSS4J - Signing with UsernameToken

Thu, 02 Feb 2006 08:11:22 -0800

WSE 2.0+ allows message level security to be accomplished using WS-Security + WS-SecureConversation.  This is accomplished by using UsernameToken (WS-S) + DerivedKeyToken (WS-SC) to sign and encrypt.

 

In the sandbox packages of the WSS4J 1.1 source there is a “conversation” package that seems to address signing and encrypting with a DerivedKeyToken created from a UsernameToken.  Is this code unusable (clearly not totally stable since in sandbox, but it looks like an attempt to address WS-SecureConversation).

 

Which deployment files are you referring to?  I have seen something on the OASIS website, are these them?

 

Either way,.NET service implementation are ahead of any ratified specification, and thus support on the Java side is limited.

 

Hopefully I can make headway with these sandbox packages.

 

 

 

Paul Grassi | Iditarod Systems    

Voice: 703.637.8825 Fax: 703.637.8830

From: Dittmann, Werner [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 02, 2006 2:41 AM
To: Rami Jaamour; [email protected]
Subject: AW: Calling Secure .NET services with WSS4J - Signing with UsernameToken

 

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

 

Von: Rami Jaamour [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 1. Februar 2006 22:29
An: [email protected]
Betreff: Re: Calling Secure .NET services with WSS4J - Signing with UsernameToken

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
 
 
   

Reply via email to