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?
- 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: - 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. - 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. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 24. Januar 2006 12:50 > An: Dittmann, Werner > Cc: [email protected] > Betreff: Re: [Policy] Elaborated example for a Web Services > Security Policy Language parser/processor > > Oops missed the Refs: > > [1] http://people.apache.org/~ruchithf/sec_pol.png > This is the UML diagram of the SecurityPolicyModel. > > Thanks Ajith for generating this :-) > > Thanks, > Ruchith > > On 1/24/06, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > > Hi Werner, > > > > I developed a model to hold the security policy information based on > > your security policy parser. IMHO this is the data structure that we > > need which holds all the required information. > > I checked this in along with the parser into Axis2 SVN - security > > module - org.apache.ws.security.policy.* > > The SecurityPolicy model contains elements that extends > PolicyEngineData [1]. > > > > When a policy is parsed using the parser it will generate a > > org.apache.ws.security.policy.model.* element(s) for that policy. > > For example if the given merged policy contains a SymmetricBinding, > > Wss11 complex assertions, then once parsed the pedStack in the > > SecurityProcessorContext will contain a RootPolicyEngineData element > > with a collection of top level policy engine data elements > which will > > contain instances of > > org.apache.ws.security.policy.model.SymmetricBinding, > > org.apache.ws.security.policy.model.Wss11. These instances hold the > > policy properties as defined by the WS-SecurityPolicy spec and the > > default values will be overridden during parsing. > > Due to the use of this model I had to modify the behaviour of the > > pedStack, added a QName name parameter to the > PolicyEngineData.copy() > > method and added a readPreviousPolicyEngineData() mehod to > > SecurityProcessorContext. > > > > Now we can use this highlevel PolicyEngineData instances to > derive the > > configuration for Axis1/Axis2 handlers. I'm trying to use this to > > populate the > org.apache.axis2.security.handler.config.InflowConfiguration > > and org.apache.axis2.security.handler.config.OutflowConfiguration to > > work with the current Axis2 security module. In Axis2 the > policy for a > > service is given in the services.xml file of the service > and when the > > module is engaged for that service the policy will be made available > > to the module class (implementation of > > org.apache.axis2.modules.Module.engageNotify()) where we can do the > > policy processing to get the configuration properties of the module. > > > > Please have a look at the test case > > org.apache.ws.security.policy.parser.WSSPolicyProcessorTest where I > > have used the model to extract the properties. > > > > Thoughts & comments... :-) > > > > Thanks, > > Ruchith > > > > > > On 1/19/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote: > > > Ruchith, > > > > > > the idea you stated in your last paragraph was exactly what > > > I had in mind - the doTokenMethod() have to populate the > > > parameters/properties somehow. > > > > > > After digging into the SecurityPolicy (SP) stuff I > > > saw that this will not be sufficient to handle SP flexibility. > > > > > > Therefore I have the following idea: > > > 1 use the mechanism as of today (use of properties) to inform > > > the WSS4J Axis2 handler which policy files to use. > > > 2 The WSS4J handler takes the files, hands them over to the > > > SP parser which populates a data structure that eventually > > > contains all required informations given by the policy files. > > > This data structure ist not yet defined, but will be optimized > > > for this purpose. > > > 3 The WSS4J handler then uses these information to control > > > the setup of the request. > > > > > > Because SP does not hold every information we need we also have > > > to stick to the properties to define missing information like > > > username, password handlers, etc. However, a large number of > > > security properties will go into the SP files, thus reducing > > > the complexity of handler parameters. > > > > > > A similar processing needs to be done at the server side to > > > implement a sort of policy enforcment. > > > > > > To reduce overhead I'm also looking for a place to store the > > > result of the parsing step (2) in an "application context" > > > of Axis 2. Thus the WSS4J handler would look if a policy > > > file (or a combination of policy files) is already parsed and > > > reuse the available data. But this is a optimization step after > > > the overall processing works. > > > > > > IMHO the mechanisms currently provided by Axis 1 and Axis 2 are > > > sufficient to support SP handling. The WSS4J handler itself needs > > > to be more flexible - but this does not require modifications of > > > Axis{1,2}. > > > > > > Regards, > > > Werner > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > > > > Gesendet: Donnerstag, 19. Januar 2006 06:48 > > > > An: Dittmann, Werner > > > > Cc: [email protected] > > > > Betreff: Re: [Policy] Elaborated example for a Web Services > > > > Security Policy Language parser/processor > > > > > > > > Hi Werner, > > > > > > > > I have a few questions about security policy > integration into WSS4J > > > > with respect to Axis2. > > > > > > > > Right now Axis2 security module can be configured using two > > > > mechanisms. > > > > > > > > 1.) services.xml (service) file and axis2.xml (client) file > > > > 2.) using > org.apache.axis2.security.handler.config.InflowConfiguration > > > > and > org.apache.axis2.security.handler.config.OutflowConfiguration > > > > classes. > > > > > > > > Axis2 security handlers right now expect a > > > > org.apache.axis2.description.Parameter object > containing an OMElement > > > > (XML containing the config) with the security configuration. > > > > org.apache.axis2.security.util.HandlerParameterDecoder will be > > > > processing this OMElement to extract the properties and > will set them > > > > in the message context appropriately so that > > > > org.apache.axis2.security.* handlers and > > > > org.apache.ws.security.handler.WSHandler can pickup the > params from > > > > the message context. > > > > > > > > Are we planing to stick to the usual way of configuring > the handlers > > > > where we expect the params to be available via the > message context (or > > > > in the case of Axis1 as handler options)? Then our > SecurityPolicy > > > > processer should set the config params in the message > context when it > > > > processed the policy. And we should be able to directly use > > > > SecurityPolicy syntax to represent the config for those > params that > > > > can be expressed via sec-policy. And the rest of the > config params > > > > (e.g. passwordCallbackClass) can be set the usual way. > > > > > > > > I had a look at the examples.secParser.* stuff in > ws-commons/policy. > > > > Is it correct to state that we will have to construct > the params to be > > > > set in the message context in the doTokenName() methods in > > > > examples.secParser.processors.* and maybe store them in the > > > > examples.secParser.SecurityProcessorContext? > > > > > > > > Thanks, > > > > Ruchith > > > > > > > > On 1/12/06, Dittmann, Werner > <[EMAIL PROTECTED]> wrote: > > > > > All, > > > > > > > > > > to whom in may concern :-) : > > > > > > > > > > In ws-commons/policy I've checked in a more elaborated example > > > > > to show how one could parse and/or process Web > Services Security > > > > > Policy files. It is meant as an example and ist not > (yet :-) ) a > > > > > full blown processor. I'll take this as a base to implement > > > > > a policy processor for the next verision of WSS4J / Axis2. > > > > > > > > > > See the package description (after running javadoc) to get > > > > > some more lines of documentation. > > > > > > > > > > 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]
