It was recently pointed out to me that we have a comment on the OGSI Authorization Requirements document in GridForge (the fact that the WG should be notified of these things has been passed along to GGF). The comment is at: https://forge.gridforum.org/forum/forum.php?thread_id=972&forum_id=560 I include my response below as a convenience to the WG. Further response should be done via GridForge. Von --
By: Guruprasad B Nagaraja Subject: OGSI Authorization Requirements.pdf[ Reply ] Date: 2005-10-13
Apologies for the long delay in responding. These comments are appreciated, but I only recently became aware of their existence. My response are embedded below. - Von
The initiator is attempting to invoke an operation, but the policy has time or other constraints in it, that limit when or how the initiator may invoke the operation - e.g., only between the hours of 8am and 5pm, or only up to a maximum of six times a day. (Pg 5)
[]Geographical location of the user might also be stated as one of the constraints. (When or how or from where).
I don't have any fundamental objection to adding this as an example, but I don't now of any method in OGSA for determining or expressing the physical location of entities.
When we say when or how, I feel there is a feeling that the user will be able access during that time or so many times for a considerably long period of time. But what if the nature of permission is such that its short- lived, say sporadic few-hours in 10 years. This is focused more towards the management of authorizations by the Authorization Service. Support for common OGSI actions: Operation and service data access on Grid Services will be common. It is expected that a large amount of policy for OGSI can be written regarding initiators rights to perform these actions. (Pg 6)
[] I see this also as different types of policies exhibiting different levels of granularity.
I don't disagree with this statement. Do you believe the document needs to be changed in some way?
Supporting Credentials: Queries to authorization services may need to supply assertions about the initiator necessary for the decision-making process. Alternatively, the authorization service may know how to retrieve the supporting credentials itself, in which case the initiator may need to provide no information or simply a pointer to where the information can be obtained. (Pg 6)
[]Should the user authenticate to the Authorization service before submitting "AUTHORIZATION DECISION REQUEST" to the authorization service or should the authentication be a part of the request. We dont want someone requesting on others behalf. I guess this is related to the push mode.
I agree that authorization services should have some notion of policy in regards to whom can request policy decisions. How about added a new bullet to this section (section 5): * Access Control to Authorization Decisions: For reasons of security and privacy, authorization services should be capable of enforcing access control on who can request authorization decisions. In the simplest incarnation, authorization services should be configurable so that they only answer queries from a set of trusted target resources. More complex implementations could allow for finer- grained policy based on the initiator and request. Some implementations may even want to require proof of that an initiator requested an action in order to authorize it.
Please note that these comments have been made with the intension of pariticipating in such discussions and to learn more.
Thank you for your comments.