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