[DRMAA-WG] Public poll about authorization approach

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

[Mariusz Mamoński]

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

+1

Post by Peter Tröger
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

[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

Post by 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

[Daniel S. Katz]

I think B makes sense unless there is a documented need for C. Perhaps there should be a note somewhere in DRMAA2 mentioning C as a potential future DRMMA3 activity.

Dan

Post by 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

--
Daniel S. Katz
University of Chicago
[phone] (voice)
[phone] (fax)
d.katz at ieee.org or dsk at ci.uchicago.edu
http://www.ci.uchicago.edu/~dsk/




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/drmaa-wg/attachments/20110520/5f9c06cc/attachment-0001.html