You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by David Illsley <da...@gmail.com> on 2007/10/09 15:04:37 UTC
[Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations
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
Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations
Posted by David Illsley <da...@gmail.com>.
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 <ru...@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 <da...@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
Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations
Posted by Ruchith Fernando <ru...@gmail.com>.
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 <da...@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
Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations
Posted by David Illsley <da...@gmail.com>.
Brian,
No, I'd intend that the wsa:Action and wsa:RelatesTo be extracted just
once in the AddressingDispatchExtractor and set the values on the
MessageContext.
David
On 11/10/2007, Brian De Pradine <PR...@uk.ibm.com> wrote:
>
> Hello David,
>
> Please see my comments below.
>
> Cheers
>
> Brian DePradine
> Web Services Development
> IBM Hursley
> External +44 (0) 1962 816319 Internal 246319
>
> If you can't find the time to do it right the first time, where will you
> find the time to do it again?
>
>
> "David Illsley" <da...@gmail.com> wrote on 09/10/2007 14:04:37:
>
>
> > 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
>
> Are you saying that the AddressingRemainderInHandler will no longer set the
> wsa:Action and wsa:RelatesTo values on the message context? I am trying to
> understand what you mean by "Remainder". Isn't this just the current
> AddressingInHandler with the function of the AddressingFinalInHandler and
> AddressingSubmissionInHandler pushed down into it?
>
> >
> > 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
> >
>
>
>
> ________________________________
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
>
>
--
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
Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account
of Security Considerations
Posted by Brian De Pradine <PR...@uk.ibm.com>.
Hello David,
Please see my comments below.
Cheers
Brian DePradine
Web Services Development
IBM Hursley
External +44 (0) 1962 816319 Internal 246319
If you can't find the time to do it right the first time, where will you
find the time to do it again?
"David Illsley" <da...@gmail.com> wrote on 09/10/2007 14:04:37:
> 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
Are you saying that the AddressingRemainderInHandler will no longer set
the wsa:Action and wsa:RelatesTo values on the message context? I am
trying to understand what you mean by "Remainder". Isn't this just the
current AddressingInHandler with the function of the
AddressingFinalInHandler and AddressingSubmissionInHandler pushed down
into it?
>
> 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
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU