|
Hi Chamikara and Dan,
We faced this problem earlier as well. In Sandesha1
what we do is allow user to set handlers to the Sender's request and response
path as well. So security handler can be there as a handler for the
Sender.
But for axis2 we can do it as follows.
It is true that we cannot avoid the coupling (at
least in RM and Security)
So in the initialization face of the RM Module we
can check the availability of the security module and change it's
position.
Instead or running it towice we can re arrange the
order of the security handler and configure it for the Sender.
It will be a hard coded thing, IMHO this is
something we need to do to avoid these issues. In any case since the specs are
petty finalized about their logic, we know their respective positions in the
handler chain for a given direction. It is also trivial from the interop
sessions that the order should be RM and then Security. So why not fix this
problem for all the modules at once.
We can even do it in a flexible way by having
some "ignore order" flag in the module.xml of RM Module.
Thanks,
Jaliya
----- Original Message -----
Sent: Saturday, March 04, 2006 1:09
AM
Subject: Re: [Sandesha2] Composing with
WS-Security
Hi Dan,
The reason for going this kind of a model is
persisting the message at the end of the handler chain. If we persisted the
message at the middle of the chain we would have had to vertually persist the
message context completely (most probably properties from other contexts as
well). But by persisting it at the end of the handler chain, we can simply
persist the SOAP envelop which seems to be a much cleaner approach.
But the
problem you mention is there. When security encryption or signing is enabled,
the Sender will not be able to work correctly.
Here is one workaround
I see. It should be possible to mark some phases (or handlers) as
post-persist. Those will be invoked only after persistence, and they will be
called in each retransmission. So the users can mark security handlers as
post-persist. Encryption and signing will happen in every retransmission
(probably SOAP envelopes will have to be cloned before doing this). Also some
security properties set by the client may have to be persisted as well.
So,
yes we do not support thie scenario at the moment. But we will soon
:-)
Thanks,
Chamikara
On 3/2/06, Daniel
Millwood <[EMAIL PROTECTED] >
wrote:
Hi,
In
an earlier post to the list, Ruchith stated that in his opinion,
the
security handler should be the last to run when sending a
message. This
would enable the WSRM Sequence Header
(SequenceId and SequenceNumber) to be
added to the message and signed so
it couldnt be tampered with.
If Ive understood the client side code
correctly, messages run through all
the handlers once, and are assigned
to the Sandesha2 Sender thread, which
then directly invokes the messages
TransportSender to send each outbound
message 1 or more times. While the
messages are assigned to the Sender
thread, they could be updated with a
real sequence id, but this will happen
after the security handler has
run, so the WSRM Sequence Headers cannot be
signed.
Is my
understanding
correct?
Thanks, Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
commands, e-mail: [EMAIL PROTECTED]
|
