Hi Sanka, Werner, Sorry about jumping in late...
But ... is there any specific reason that is stopping us from using the assertions as for the WS-SecPolicy spec to configure the WSS4J handlers. IMHO if we try to come up with our own assertions we are going to loose interoperability ... especially if we are to extract the policy from the service's WSDL and configure the security handlers based on the assertions. What do u guys think? Thanks, Ruchith On 12/12/05, Sanka Samaranayake <[EMAIL PROTECTED]> wrote: > Hi werner, all > > 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. > > IMO WSSecurity Policy Assertion language is yet to reach its fullest > maturity. Mean while, Is it possible to define our own few WSS4J > specific WSSecurity Policy Assertions which complements the WSSecurity > Policy Assertion language to fill-in any missing information and use > them ? In that way all WSS4J configurations can be expressed in a much > more uniform manner and we can replace them with more appropriate > WSSecurity Policy Assertions as they become available > > > > > 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]
