Ruchith, thanks.
About the COMMIT and validate() - I had a similar idea. In that case the commit() method in the WSPolicyProcessor shall return the result (true/false) of the validation. Corrently it is a void method. On the other hand, as it is done now is also ok - perform some checks during start() and if it fail return false. Which way to use depends IMHO on the type of validation to perform, both ways are fine. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 25. Januar 2006 12:00 > An: Dittmann, Werner > Cc: [email protected] > Betreff: Re: [Policy] Elaborated example for a Web Services > Security Policy Language parser/processor > > Hi Werner, > > Please see my inline comments. > > On 1/25/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > > Ruchith,, > > > > just browsed ofer your parser - really great. Some ideas and > > thoughts: > > - in PolicyEngineData: the copy() method is really something like > > a newInstance() methond that returns a new complex token. We shall > > think about renming it? > > Certainly +1 > lets rename it to newInstance() > > > > > - pls have a look to the attached patch. > > > > I modified the WSPolicyProcessor to pop a PED element from the stack > > only if it a complex toekn (because only complex tokens are > pushed on > > the stack). This is in the abort() method. > > > > In SymmetricBindingProcessor I modified the action > comparison: do the > > action on START. If the action fails return a false (e.g. while > > cathing an exception). Otherwise it returns true. If the > start method > > returns true the parser works on the other child tokens of a complex > > token, otherwise it aborts the parsing of that complex token. Pls > > keep in mind that if one assertion inside a complex > assertion (token) > > fails then the whole complex assertion fails. This was the > reason why > > I use this transaction mechanism: > > Understood ... When an exception is thrown we should ABORT that > complex assertion. > > In addition to that can we report that to the user as well (You might > have noticed that I had some "// TODO Throw this exception out" in > those places). Therefore rather than throwing an exception in the > doAssertion method at the point of aborting (returning false) we can > insert the error message into the securityProcessorContext where it > can be fetched to be reported to the user. > > > - START: prepare the data, check what can be checked here > > - COMMIT: maybe empty if all could be done in START, or here the > > data parsed by child tokens can be merged with other data, etc. > > At the COMMIT I was thinking of having a validate() method in the PED > so we can validate the complex assertion. > Example: There should not be a when a ProtectionToken is present in a > SymmetricBinding there cannot be an EncryptionToken present and it > must contain a an AlgorithmSuite assertion. > > What do you think? > > > - ABORT: clean up if necessary > > > > Of course we may modify this handling if the parsing structure you > > do not use this mechanisms - in the exmple I just showed this as one > > mechanism that could be used. > > > > Nevertheless, I will shamelessly copy (re-use :-) ) your > code and extend > > it as a base of the "policy engine" that controls the actions of the > > WS Security modules. > > Cool.. Please feel free to copy/change anything :-) > > I'm just trying out a few things with Axis2 security.mar right now > just to see how we can use policy to use some of the existing WSS4J > functionality,but when you complete the changes to WSS4J lets > integrate it into Axis2. > > Thanks, > Ruchith > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
