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]
