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]
