You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Daniel Millwood <MI...@uk.ibm.com> on 2006/03/02 15:51:13 UTC

[Sandesha2] Composing with WS-Security




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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org

Re: [Sandesha2] Composing with WS-Security

Posted by Jaliya Ekanayake <jn...@gmail.com>.
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 ----- 
  From: Chamikara Jayalath 
  To: MILLWOOD@uk.ibm.com 
  Cc: sandesha-dev@ws.apache.org 
  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 <MILLWOOD@uk.ibm.com > 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: sandesha-dev-unsubscribe@ws.apache.org
    For additional commands, e-mail: sandesha-dev-help@ws.apache.org

Re: [Sandesha2] Composing with WS-Security

Posted by Jaliya Ekanayake <jn...@gmail.com>.
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 ----- 
  From: Chamikara Jayalath 
  To: MILLWOOD@uk.ibm.com 
  Cc: sandesha-dev@ws.apache.org 
  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 <MILLWOOD@uk.ibm.com > 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: sandesha-dev-unsubscribe@ws.apache.org
    For additional commands, e-mail: sandesha-dev-help@ws.apache.org

Re: [Sandesha2] Composing with WS-Security

Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <MI...@uk.ibm.com> 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: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>

Re: [Sandesha2] Composing with WS-Security

Posted by Chamikara Jayalath <ch...@gmail.com>.
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 <MI...@uk.ibm.com> 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: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>