perfsonar development work

[Cándido Rodríguez Montes <>]

Hi Jeff,

El 21/03/2007, a las 16:03, Jeff W. Boote escribió:

- 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.

Ok, I've found a way to get the SOAP header without any change:

MessageContext mc=MessageContext.getCurrentContext();

try {

SOAPHeader sh=(SOAPHeader)mc.getCurrentMessage().getSOAPHeader();

String temp=org.apache.axis.utils.XMLUtils.DocumentToString(sh.getAsDocument());

logger.debug("====");

logger.debug(temp);

logger.debug("====");

} catch (Exception e) {

logger.debug("ERROR: "+e.getMessage());

}

So, in this way, the AuthZ API can check if any security token has been sent in the SOAP header :-)

Regards

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

--

Cándido Rodríguez Montes E-mail: 

Red.ES/RedIRIS Tel:+34 955 05 66 13

Edificio CICA

Avenida Reina Mercedes, s/n

41012 Sevilla

SPAIN