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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > ________________________________ > > > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
