axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian De Pradine <>
Subject Re: [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations
Date Thu, 11 Oct 2007 12:30:06 GMT
Hello David,

Please see my comments below.


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" <> 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 
> AddressingRemainderInHandler
>   -- Extracts remaining WS-A headers and sets them on the MessageContext
>   -- Amalgem of AddressingFinalInHandler and 
>     -- 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:
> For additional commands, e-mail:

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

View raw message