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]
