Ruchith, great stuff - I already had a peek into the code.
You may have noticed that I refactored the old Signature/Encryption classes to provide much mor flexibility during the process of signing and encryption. WS Policy requires that an element, e.g. an encrypted Key, is set up to encrypt some data, e.g. the Body, without having the Eencrypted KEy element already placed in the security header. This is why I splitted the "big build" method into several smaller methods that handle each step separatly. For example the encrypted key: - prepare() sets up the complete encrypted key strcuture. After calling prepare() you can encrypt data elements that are inside the SOAP envlope. - using the prepend*() methods you can add the encrypted key element to the security header any time after prepare() thus enables precise control about the placement of the elements in the security header. This control is required by WS Policy. Whan you are ready with your DK stuff we shall look and try to have it in the same way. Usually this only requires some reshuffling of code elements in own methods. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 6. Februar 2006 09:58 > An: [email protected] > Betreff: DerivedKey Encryption and Signature > > Hi Werner, > > I checked in the initial work on DerivedKey stuff (revision-375103). > > We should be able to support signature and encryption _both_ using > keys derived from the same session key (which is stored in the msg as > an encrypted key) . Therefore I introduced > org.apache.ws.security.message.WSSecDKSignEncrypt which is expected to > do both or either of them (sig/encr) as and when required. (Borrowed a > lot of code from other builders as well :-) ). > > Encryption using a derived key is implemented in revision-375103. > > Now when processing the security header we have to process the > DerivedKeyToken (DKT) and derive the key from the DKT. I added the > org.apache.ws.security.processor.DerivedKeyTokenProcessor to do this. > It should be noted that when the key length ("wsc:Length" element in > the DKT) is not available in the DKT we do not generate the key. But > when we are processing the references we use the symmEncrAlgo > information at the > org.apache.ws.security.processor.ReferenceListProcessor to get the key > length and use the DerivedKeyTokenProcessor.getKeyBytes(int length) > method to get the derived key. > > Please have a look at the test case when you are integrating this with > the new message creation stuff based on policy, it is very much > similar to the way other builders are used. > > I had a peek at some of the sample messages from the first MSFT indigo > interop plugfest and noticed that they use the #EncryptedKeySHA1 key > identifier valueType attr ([1]-line 49,65) in the response message. > Therefore I guess we should _also_ implement the situation where we > ues the same session key for both request and response, where the > requester creates the session key. IMHO we can still use the DKTs with > the response with a fresh session key as well and we can give an > option to switch to use the same session key for the response. What do > you think? > > I'll start work on DKT sign stuff now and will update > WSSecDKSignEncrypt, etc. accordingly. > > Thanks, > Ruchith > > [1] http://rafb.net/paste/results/XIedAA17.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
