Hi Nandana, do you know if current implementation of Rampart supports this behavior?
Best regards, Dobri On Nov 16, 2007 10:05 PM, Nandana Mihindukulasooriya <[EMAIL PROTECTED]> wrote: > Hi Dobri, > > my question is why in case of Symmetric binding there is need of the > > following parameter: > > > > <ramp:encryptionUser>client</ramp:encryptionUser> > > > I think when using the Symmetric binding, in the client side configuration > we > actually need to have only the <ramp:encryptionUser/> property. This alias > is > used to find the certificate to encrypt symmetric key in the encrypted > key. > And in the server side we only need to have the <ramp:user/> or > <ramp:userCertAlias/> property and this alias is used to find the cert to > decrypt > the encrypted key. > But this is true only if we don't have any supporting tokens. If we have > supporting > tokens we always have to have <ramp:user/> property in the client side > configuration. > > Regards, > Nandana > > > > > > Regards, Dobri > > > > On Nov 16, 2007 10:27 AM, Dobri Kitipov <[EMAIL PROTECTED]> > > wrote: > > > > > Hi everybody, > > > there is a nice article called "Secure Message Exchanges with Multiple > > > Users" at http://wso2.org/library/255. > > > In this article we can read: > > > > > > " > > > <encryptionUser>useReqSigCert</encryptionUser> > > > > > > This instructs Rampart/WSS4J to use the certificate that was used to > > sign > > > the request. One can specify the encrypted parts to encrypt different > > parts > > > of the message to be encrypted. > > > " > > > > > > My question is is it possible to use this with Symmetric binding? I > > could > > > be wrong but my understanding is that if this is supposed to work it > > will > > > mean that we want the derived key to be based on the lient's > > (initiator's) > > > security token (not the recipient's one), defined in the either > > encryption > > > token assertion or protection token assertion. > > > I know this make much more sense with the Asymmetric binding, but I am > > > curious about that. > > > > > > Thank you. > > > > > > Best regards, Dobri > > > > > > > > >