axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Davis <...@us.ibm.com>
Subject Re: Please revert this - and a proposal
Date Wed, 15 Feb 2006 12:40:18 GMT
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" <jnekanayake@gmail.com> 
02/14/2006 10:41 PM
Please respond to
"Jaliya Ekanayake"


To
"Jaliya Ekanayake" <jaliya@apache.org>, Doug Davis/Raleigh/IBM@IBMUS
cc
<axis-dev@ws.apache.org>
Subject
Re: Please revert this - and a proposal






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: axis-dev@ws.apache.org 
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" <jnekanayake@gmail.com> 
02/13/2006 03:21 PM 

Please respond to
"Jaliya Ekanayake"



To
Doug Davis/Raleigh/IBM@IBMUS 
cc
<axis-dev@ws.apache.org> 
Subject
Re: Please revert this - and a proposal








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: axis-dev@ws.apache.org 
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 

Mime
View raw message