axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Illsley" <>
Subject [Axis2][Strawman] Re-organise AddressingInHandler Code to take account of Security Considerations
Date Tue, 09 Oct 2007 13:04:37 GMT
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.

  -- 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

  -- Configured based on the AxisOperation extracted by the
  -- Validates the WS-A headers with the selected namespace (if appropriate)

  -- 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

  --  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?

David Illsley - IBM Web Services Development

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message