perfsonar development work

["Jeff W. Boote" <>]

Cándido Rodríguez Montes wrote:
> Hi,
> as most of you know, I've started to implement the authorization service 
> (AS) in perfSONAR and it's not only to develop that service but it 
> provides to perfSONAR services some classes for sending AS authorization 
> requests.
> Well, the AA team have decided some weeks ago to use Web Service 
> Security (WS-SEC) standards for authorization purposes. At this time, 
> the communication between perfSONAR clients and resources is through XML 
> messages which are encapsulated by SOAP. But SOAP is composed by two 
> main elements: SOAP headers and SOAP bodies. And those XML messages are 
> included in a SOAP body.
> But using WS-SEC, clients send to resources (and the same when resources 
> send an authN request to the AS) include the security token, which is 
> the information needed by the receiver to check the identity of the 
> sender, in a SOAP header. And this implies some modifications in the 
> perfSONAR architecture:
> - In the svn branch 'branches/as', I've modified the class 
> 'org.perfsonar.service.web.RequestHandler <http://web.RequestHandler>' 
> so it can access all SOAP message. So in this way, we can check if 
> clients have sent security token or not.
> - But resources need to get the security token in case it has been sent. 
> In the perfSONAR architecture, XML messages sent by clients are mapped 
> to the class 'org.ggf.ns.nmwg.base.v2_0.Message' and then it passed to a 
> message handler. Finally, the service receives the message when it's 
> called the function 'takeAction(String actionType, Message request)'. In 
> this scenary, it's not possible that services get the security token or 
> check the SOAP header which contains the security token. So, I think 
> that there are two possible solutions:
> + We can change the 'Message' class so it includes the security token if 
> it's sent in the request.
> + We can change this presented workflow and change the function 
> 'takeAction' to 'takeAction(String actionType, Message request, 
> SecurityToken token)'.
> + Any other ideas?
>
> What's your feeling about this?

I would prefer the method for takeAction stay the same if at all possible. What 
I would like to see is the following:

* The security token should not be seen by the main handler
* We should install a request-handler in the 'global' layer of axis that knows 
how to decode this soap header. (It should be in the chain before our current 
'pivot' handler.)
* We should make an API available to the current service level code for 
authorization questions. Ideally without changing the current API. Services that 
don't care about AA should not be forced to see it.

Now, the AuthZ API will actually need to have some 'handle' back to the 
processed auth token. I would prefer this not be one of the parameters to the 
method, and I really don't want it part of the Message object. (The Message 
object is the representation of the XML Message object - and this auth token is 
from the SOAP header, it is not part of the Message object.) Therefore, what I 
would like to see is something closer to the component properties API we are 
currently using. Is there some way for an AXIS handler to set properties for the 
current request that later handlers can get? (Similar to the r->notes portion of 
a request rec in apache request modules...)

jeff