perfsonar development work

[Loukik Kudarimoti <>]

Hi,

This email is a result of one of the action points arising out of the 
recent phone conferences on AA implementation planning. I promised to 
send out a proposal for phased development of AA features. The 
explanation below is what I meant. Let me know what you think.

When it comes to AA, any perfSONAR service can protect its resources 
using any of the four options below. The complexity of AA implementation 
within the service increases as you traverse down this list.

1) Don't care about AA - resources open to all or make use of firewalls 
(network or OS)
The simplest solution but not applicable to all services - definitely 
not the ones which can make measurements. This is the current solution

2) The user is authorized to access the resource because the user has 
been authenticated (i.e. known user or a user in possession of a token)
The user has a *valid* authentication token (SAML assertion or X.509 
certificate). The resource may either simply check for the presence of 
such a token or even get the authenticity of the token verified. As I 
understand, this verification process will require the resource to talk 
to a (usually pre-configured) Authentication Service. The assertion or 
the certificate is passed to the AS. (AS is implemented by perfSONAR)

3) The user's authorization is verified further with the help of the AS. 
This verification is to find out whether the *particular user* can be 
allowed to make use of the resource in question.
The user will have to possess a valid authentication token and the 
resource will need to pass on some information about the resource in 
question. (for example, sensitive data from routers or making a bwctl 
measurement for example). The AS will

4) The user's authorization and his request is verified to a very great 
degree. This verification is to find out whether the *particular user* 
can make use of a the *particular resource* and *in the manner requested*.
As in (3) above but along with information about the resource in 
question, more information about the request itself and also about the 
resource as well. The information about the resource could include some 
specific details about what exactly the resource is or it could also 
include the current state of the resource (in case preemption check 
needs to be done)


My thoughts and suggestions:

* In the short to middle term, we should start with phases (1) and (2) 
above. Phases (3) and (4) will include a great deal of complexity - both 
for the pS service as well as the AS. We must also bear in mind that the 
service will need to communicate with the AS in order to do phases (2) 
and above.

* In order to make sure that the performance hit because of AS is kept 
to as little as possible, we have to reduce the number of interactions 
between the resource and the AS - ideally just one interaction per 
request. We should also investigate if bulk requests for AA can be used 
i.e., requests from various users coming at the same time are sent in 
the same batch. This is where threading and scheduling might become 
extremely important for our resources.

*  In order to achieve the above point (i.e. least number of 
interactions between the AS and the resource), we have to start thinking 
about all phases (1 through 4) from now itself even though we will 
probably implement (1) & (2) in the near future. To give you a bit more 
implementation detail, to do (3) and (4), the request would probably 
need to gone until the Resource Protector component inside the perfSONAR 
service. By doing the check at this stage and not earlier we can try to 
ensure that the AS will not need to be contacted again. However, how to 
deal with DOS attacks on the service needs to be discussed.

Thoughts?

Regards,
Loukik.