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]
