HI werner > Support of WSS Spec 1.1 will be build into the upcoming version of > WSS4J - if some kind sould has some space cycles I appreciate some help, > e.g. an implememtation of the WSS 1.1 key generation algo. >
Can you please point me to the key generation algorithm that you mentioned above. Are you taking about the "DerivedKey" stuff? I should be able to spend some time on it. Thanks, Ruchith On 2/3/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > > Rami, > > the deployment descriptors are thos contained in the > interop/org/apache/ws/axis/oasis directory for the client > deployment > descriptor. The server depleyment descriptor is in the subdirectory > ping. > > The implemented usernametoken signining is _not_ according to the > WSS 1.1 spec as WSS4J 1.1 does support WSS spec 1.0 only. The > implementation of this specifc code was due to some requests on the mailing > list > and the description of the algorithm was derived from a description from > some internet forum (I need to dig into the mail archives to get the link > again). We tested this code using some recored request/response pair > of some WSE version. I didn't got any information about successfull > interoparability tests. > > Support of WSS Spec 1.1 will be build into the upcoming version of > WSS4J - if some kind sould has some space cycles I appreciate some help, > e.g. an implememtation of the WSS 1.1 key generation algo. > > Regards, > Werner > > > ________________________________ > Von: Rami Jaamour [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 3. Februar 2006 03:24 > An: Dittmann, Werner > Cc: [email protected] > Betreff: Re: AW: Calling Secure .NET services with WSS4J - Signing with > UsernameToken > > > 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 > > > ________________________________ > 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 > > > >
