[OGSA-AUTHZ] Comments on ogsi authz requirement document

[Von Welch]

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.