Ruchith, as I haven't yet read all the doc you mentioned but having only *one* key pair for reqeustor and *one* for receiver is IMHO only for demo purposes. During the last weeks or so we had some questions on th WS4J mailing list how to handle several clients that have own key pairs, etc.
Well, WSS4J implements a clever method :-) (use signature request to do encryption) to minimize the number of key pairs (certificates) a receiver has to store. Nevertheless, a restriction to just one key pair per requestor and receiver will IMHO not work in the long run. On the other hand, defining a user name (alias) and/or the password support classes (however they are implemented) in a policy that defines the way to use security seems also wrong to me. Such a Policy may work for a number of applications of a "client" (client may be a company or similar organisation) that use some service of another organisation. Therefore we need IMHO a way that a specific application can use to define its "alias" and "password" and this should be separate from the policy. Am I wrong here and does an "alias" and other info to get the cert belong to the policy? Thoughts? Ideas? Regards, Werner Ruchith Fernando wrote: > Hi Werner, > > Oops ... I missed your points you have made in this original mail, > (which answered my earlier mail:-) ) I noticed we cannot get the cert > info from the policy. > > I had a look at the indigo-plugfest's [1] inteorp doc [2] from MSFT > where they did use WS-SecPolicy. > > Here they are separately mentioning the key aliases in the introp doc [2]. > > Is this because the requester (client) is assumed to use only *one* > key pair by default and the receiver (service) is also expected to > have only *one* key pair? This way they (client and service) really > have only one fixed option when it comes to keys, hence there's no > need of expressing them in policy. > > Is this practical? Or will this only serve a very simple scenario? > > Thanks, > Ruchith > > [1] http://131.107.72.15/ilab/wcfinteroplab.htm > [2] http://131.107.72.15/ilab/WSSecurity/WCFInteropPlugFest_Security.doc > [3] http://131.107.72.15/wssecurity/svc/WsSecurity10.svc?wsdl > On 12/11/05, Werner Dittmann <[EMAIL PROTECTED]> wrote: > >>Sanka, all >> >>Sanka, the detection of the wsp:Optional attribute inside a >>PrimitiveAssertion did not work as expected, I fixed it (see >>latest checkins). >> >>Unfortunatly this did not fix the wrong behavior of "Optional" handling. >>There is no second alternative generated during normalize. After putting >>in some trace it seems that PrimitiveAssertion.normalize() is never >>called thus is flag is never evaluated - Sanka, can you pls have a >>look into that. >> >>A new example shows how to merge two policies. I took the policies >>directly from Appendix C.3 of the WS SecurityPolicy specification. >>The first policy is a "binding" policy. This binding describes the >>overal security behaviour, which flags to set, security token types to >>use etc. The second policy, the message policy, describes to which >>parts of an actual message need signed, encrypted, etc. Both policies >>together form the real security policy. Attached is a pretty-printed >>result of this merge. Everybody is invited to have a look and to check >>if it is correct (by reading and applying the WS-SecurityPolicy >>specification :-) ). >> >>IMHO this separation into "binding" and "message" policy shall be >>reflected in the planned implementation for WSS4J. It is also clear that >>the security policies do not contain enough information to set-up the >>complete security handler: for example the user name(s) to identify the >>security tokens (certificates) is missing, maybe some other info >>as well. >> >>Regards, >>Werner >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > > -- > Ruchith > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
