axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Illsley" <davidills...@gmail.com>
Subject Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations
Date Mon, 22 Oct 2007 08:17:22 GMT
Hi Ruchith,
Yes, I think tha handler should be in the addressing module, and so
yes, I think we should use a property to allow the AxisOperation to be
verified (and easily extracted by the security handlers).

David

On 19/10/2007, Ruchith Fernando <ruchith.fernando@gmail.com> wrote:
> Hi David,
>
> I agree with the proposal!
>
> Just one clarification though :
> Are we going to include the SecuredAddressingDispatchValidator in the
> addressing module? If so should we a property in the message context
> to point to the AxisOperation used for security configuration?
>
> Thanks,
> Ruchith
>
> On 10/9/07, David Illsley <davidillsley@gmail.com> wrote:
> > As discussed a couple of months back, the current one-shot
> > WS-Addressing header extraction isn't suited for use with security.
> > This is because either:
> > 1. Addressing runs before security and populates fields such as
> > ReplyTo/FaultTo which, if later found to be invalid would not be
> > un(de?)populated (which is a security risk).
> > 2. Addressing runs after security, hence interoperable Operation-Level
> > security is not possible as it relies on the WS-A Action/WS-A
> > RelatesTo for operation identification.
> >
> > I've thought about this problem a fair bit and I'm of the opinion that
> > security is important enough that we should break the WS-A headers
> > apart and change the model slightly.
> >
> > The following proposal is very much open to change, but I do believe
> > is in the right general direction.
> >
> > AddressingDispatchExtractor
> >   -- Extracts wsa:Action and/or wsa:RelatesTo value
> >   -- Determines the correct AxisOperation/OperationContext for security
> >     -- Does not set them in normal place on message context in case
> > they are invalid
> >     -- Places them on message context as properties
> >   -- Sets WS-A namespace on message context to allow security + later
> > WS-A handers to proces the correct headers
> >
> > SecurityHandler(s)
> >   -- Configured based on the AxisOperation extracted by the
> > AddressingDispatchExtractor
> >   -- Validates the WS-A headers with the selected namespace (if appropriate)
> >
> > AddressingRemainderInHandler
> >   -- Extracts remaining WS-A headers and sets them on the MessageContext
> >   -- Amalgem of AddressingFinalInHandler and AddressingSubmissionInHandler
> >     -- Namespace has already been selected so makes sense to combine
> >
> > General Dispatchers
> >
> > SecuredAddressingDispatchValidator
> >   --  Verfies that the AxisOperation to be invoked matches the
> > AxisOperation used for security configuration
> >   -- Only required if security is engaged
> >
> > Backwards Compatibility
> >   -- For users who haven't modified the WS-A Module  - no backwards copat issues
> >   -- For users who have, need to modify their custom module.xml to use
> > the new handlers
> >
> > Anyone have any thoughts on this?
> > Cheers,
> > David
> >
> > --
> > David Illsley - IBM Web Services Development
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-dev-help@ws.apache.org
> >
> >
>
>
> --
> www.ruchith.org
> www.wso2.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
David Illsley - IBM Web Services Development

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message