[DRMAA-WG] Public poll about authorization approach

[Daniel Gruber]

Hi Peter,

I'll vote for A.

Additional complexity for option B comes from the fact that in some systems 
you can also *exclude* yourself to use the advance reservation (when you 
specify your ACL, you must additionally add your *own username* in order 
to user your AR; this is not so when just requesting an AR without a user list).

If the vote is for B this behavior must be specified. That means it either must be
allowed to exclude the submitting user from AR (by not including it in the 
ACL), or the submitting user is always added. The the last case it must be 
possible within the DRMA implementation to get somehow the correct username.

IMHO C is totally out of scope because we long before decided not to reflect 
security and access control. 

Cheers,

Daniel

Am 20.05.2011 um 08:44 schrieb Peter Tröger:

> Dear list,
> 
> after long discussions during this week's phone conference, I decided to make a public poll about a basic decision in the DRMAA2 design.
> 
> So far, DRMAA1 + DRMAA2 assume that all API activities are performed by one application using the library. The authorization for using the DRM through DRMAA is derived from credentials of the user running the application. Therefore, DRMAA did not need an understanding of authorization in the API so far.
> 
> With the introduction of advance reservation (AR) as part of the API, some people reported that ARs are typically created by 'dedicated' managing users, and consumed (in terms of job submission) by other users. This breaks our old principle, since some DRMAA application instances now prepare DRM resources for other 'users'. You can easily extend this to a maybe necessary relation of 'resources' (machine, queue, AR), and users allowed to operate with them.
> 
> We would like to know from you if the upcoming DRMAA2 should
> 
> A) continue to treat authorization as implicit. This would not allow to create ARs for other users.
> B) allow to create ARs for other users, but keep the implicit user assumption for all other activities.
> C) should generally consider that there are user-related rights for resources and activities in the DRM.
> 
> Option A is currently implemented, option B would be inconsistent but easy to solve by adding one attribute (ReservationTemplate::usersACL), option C demands another major restructuring of the new API.
> 
> Please state your choice on the list - we need a quick decision here.
> 
> Thanks,
> Peter.
> --
>  drmaa-wg mailing list
>  drmaa-wg at ogf.org
>  http://www.ogf.org/mailman/listinfo/drmaa-wg