Jaliya,
Your question about the ordering is a good one. I'm not a security expert but based on some things I've seen I think the ordering is ok. If you take a look at the RAMP Profile (ftp://www6.software.ibm.com/software/developer/library/ws-ramp.pdf) it talks about how the WSA headers are signed but not encrypted - and that document was written with some security experts so I think that's a good sign :-) But even aside from that I think it makes sense that the WSA headers are not encrypted from a processing perspective. Even before the message is decrypted a processor may need to examine the WSA headers to do proper routing - and if those headers were encrypted (and if that node doesn't have access to the security info to decrypt the message) then it can not route the message properly. So, a gateway type of machine could not route the message to the proper destination node. But also if an error occurs before the message is decrypted the soap node may need to look at the faultTo or replyTo headers to know where to send the fault to - so again, if those were encrypted then it could not do the proper routing. I think the ordering should fit the interop requirements - at least it has so far for me ;-)
As for the time constraints - I'm in the same position. :-( That's one of the many reasons its taken so long for me to just make the plug-points available. I'm a bit swamped this week but let's see what we can do, in the not too distant future, to make some progress on it.
thanks
-Doug
| "Jaliya Ekanayake"
<[EMAIL PROTECTED]>
02/14/2006 10:41 PM
|
|
Hi Doug,
I went through the code and for me, these changes makes the life of RM and Security implementers much simple. Wish we had this before.:)
One thing I noticed is the order of WSA, WSRM and Security.
According to the code first we check WSA and then perform the Security. Can we fix this order? I mean can there be situation where the entire message is encrypted even the addressing headers?
However if this order fits to all the interop requirement I think this should be the way how it should be and it will not add any ambiguity to the user so that they need not worry about the order of these QoSs.
I wish I can give it a try to fit Sandesha code to this, but it will take some time with my time limits, but I am willing to give it a hand if some one can takeover the task.
Thanks,
Jaliya
----- Original Message -----
From: Doug Davis
To: Jaliya Ekanayake
Cc: [email protected]
Sent: Tuesday, February 14, 2006 8:30 AM
Subject: Re: Please revert this - and a proposal
Hi Jaliya,
The code is under: https://svn.apache.org/repos/asf/webservices/axis/trunk/proposals/dug
If you look in AxisClient.java and AxisServer.java you'll see the spots where "rmImpl" is called,
these are the plug points. There are three interfaces that an implementation needs to support:
void addRMHeaders(msgContext)
boolean sendMessage(msgContext)
boolean processRMHeaders(msgContext)
I'm hoping to add documentation today to these methods but let me say a few things now:
addRMHeaders - is called for each outgoing message right before the transport chain is
called. This method is called to add any piggy-backed Acks - note that this can
happen regardless of whether RM is used to send this particular message. This method
should not be used for anything other than Acks - the normal RM headers (seq) are added
someplace else. Note, this is also called in AxisServer for outgoing (response) messages.
sendMessage - this is the main entry point into the RM code for sending messages. It is
expected to do whatever it takes to create a sequence and send a message. In the most
trivial case it should send the CreateSeq, get the CreateSeqResponse, add the Seq header
to the outgoing message and then call AxisClient.invokeTransport() to actually send it. Basically,
RM is now in total control over when the transport is run - which makes sense since it may need
to retry. The return value from sendMessage() is a boolean indicating whether or not the RM code
actually took control - 'true' means 'yes' so the AxisClient code should not attempt to run the
transport itself.
processRMHeaders - this is the server side equivalent of sendMessage(). Its job is to
accept the incoming message, and if RM was used, it should then take control over when the
rest of the engine is invoked - this is because due to persisting of messages or InOrder
processing it may need to wait quite a while before the service is actually run. Note that even
when the incoming message was not sent using RM (ie, no Seq header) it may still contain
Acks so those will need to be looked for and processed no matter what. The return value of
this method is a boolean that indicated whether or not the normal engine flow should be used
to process the message. 'true' means that processRMHeaders detected it was an RM message
so it took control (and will call engine.invokeService() itself), 'false' means that RM was not used
to send this message so the normal flow can just continue.
I'll write more later today to explain how the security plug points can be used with this. Those are
important for RM since its possible that the security context will need to be established before the
RM CreateSeq but it also needs to be used within the RM CreateSeq element.
thanks,
-Doug
| "Jaliya Ekanayake"
<[EMAIL PROTECTED]>
02/13/2006 03:21 PM
|
|
Hi Doug,
Could you please send me the svn link for the branch where you have the plug points for RM.
If possible please point me to the new additions as well.
I would like to see how Sandesha can make use of these plug points.
Thanks,
Jaliya
----- Original Message -----
From: Doug Davis
To: [email protected]
Sent: Monday, February 13, 2006 10:16 AM
Subject: Re: Please revert this - and a proposal
Done - apologies for not explaining this a bit more in the svn commit... the changes that Dims
is referring to are the couple of lines in the AxisEngines that make calls out to RM code
and Security code. These do not assume any particulat implementation choice - they
are totally pluggable. In principle I agree that doing these things as handlers would be
the way to go, however, in working with these specs I've found that when you start to
look at their requirements it shows that the handlers can't really meet their needs.
To elaborate a bit on the requirements that makes using handlers more than a little
difficult, they include things like:
- clearly being able to rerun the transport chain for each RM retry is required
- being able to rerun it w/o having to run the other chains is key in scenarios where we
have a DB persistence and the client is restarted
- need to be able to piggy-back RM headers on outgoing messages even on messages
that are not sent using RM
- need to be able to add new RM headers on each retry since the list of Acks may have
changed since the last retry
- security needs to be run after the RM headers have been added - in all of the above cases
- the service and global chains should only be invoked once per message - while I guess
this could be a design choice I haven't seen anything to make me think that anything other
than the transport chain should be rerun on RM retries - this means that things like adding
RM headers or running security can not be on the service or global chains since they are
only run once and not on each retry. And of course putting them on the transport chains is
a bad idea since they're transport independent.
- all of these types of things apply to both the client and server since they're symmetrical.
As mentioned above, these changes are only a couple of lines of code and, this is key,
they are optional. If people would like to use an implementation that does not leverage these
new plug-points they are free to do so. This means existing add-ons will not be influenced by
these changes - I've tried to ensure that during this work no one's existing code stops working.
I'd be interested in working with someone from the other ws projects to see if they want to, or
could, leverage them - I think they would benefit from it.
To that end I've revert all of the changes of that commit, even thought most of them were unrelated
to the new plug-points, and I'd like to propose this... I'll create a new branch in which to add
these new plug-points so people can see them in their full context and to get a better sense of
how they might work. Then we can see if it make sense to move them into the trunk. Comments?
In the meantime, I'd like to complete the WSA changes I started - I did figure out the issue I was
having earlier with the server-side changes and have a fix for that (was part of this commit). Is
there any objection to me completing the server-side WSA changes?
thanks,
-Doug
