Ruchith, I havent't looked into the source yet (no Axis2 SVN code on my system) but I had a similar idea - only the way to structure the data inside of PolicyEngineData is different. The PolicyEngineData was just a skeleton, I fleshed this out to hold the parsed properties and other information like token info. Then I use these data to control the WSS4J modules.
As you may have noticed I started to refactor WSS4J modules to support the flexibility required by security policy language. I'll do the next steps during the next days. If all goes well I'll have the refactored modules and an adapted handler in about 2 weeks or so. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 24. Januar 2006 12:44 > An: Dittmann, Werner > Cc: [email protected] > Betreff: Re: [Policy] Elaborated example for a Web Services > Security Policy Language parser/processor > > 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]
