Ruchith, yes, I was thinking about the derived key stuff as defined in the WSS 1.1 specs.
Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 3. Februar 2006 12:50 > An: Dittmann, Werner > Cc: Rami Jaamour; [email protected] > Betreff: Re: AW: Calling Secure .NET services with WSS4J - > Signing with UsernameToken > > 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-wssec > urity-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.ProcessMe > ssage(SoapEnvelope > > envelope) > > at > > Microsoft.Web.Services2.Pipeline.ProcessInputMessage(SoapEnvelope > > envelope) > > at > > > Microsoft.Web.Services2.WebServicesExtension.BeforeDeserialize > Server(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 > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
