Werner,
Yes I noticed your changes and the new prepare() and build() methods. Nice work !!! I have tried to follow the same pattern in the WSSecDKSignEncrypt by doing the EncryptedKey creation in the prepare() method and in the build() method I created the DKT and the reference list and added them to the doc . This way certainly geives us more control. +1 on refactoring to support the token placement rules (lax, strict, etc ?) as for sec policy stuff. Thanks, ruchith On 2/6/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > 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]
