I am fine with removing the UserCredential, this can be an extension that someone can put in if they please. BUT I still think we need a User Element with UserName (uid) and Group (gid) in it. These are common in all types of Jobs not just POSIX Application runs. Additionally they can and should be used in the data staging area. Darren -----Original Message----- From: Ali Anjomshoaa [mailto:ali@epcc.ed.ac.uk] Sent: Thursday, March 31, 2005 2:59 AM To: Christopher Smith Cc: Darren Pulsipher; 'Donal K. Fellows'; jsdl-wg@gridforum.org Subject: Re: [jsdl-wg] my view on execution user and group Hi Chris,
I think that retaining the user name and group is useful, as I have customer use cases where the template of a job is permanently attached to a particular user identity for execution, so I think I'd like to see these stay.
Will a POSIX user ID in the Application section satisfy your use-case? If not, can you please suggest a more concrete definition for a user element that would satisfy your use-case? There is currently no definition for the UserCredential element in the Spec, but, there is one for UserGroup - anyone able to explain this? The UserGroup element's definition says that it contains the credentials necessary to run the job in a Grid!
The management and establishment of credentials, on the other hand, is generally very dependent on the protocol being used and the specific
context
of the job submission itself, that it doesn't make sense to put this in a job description. Having just finished a project Kerberizing one of our
products, I'm feeling this first hand.
-- Chris
On 30/3/05 05:38, "Darren Pulsipher" <darren@pulsipher.org> wrote:
Ok my turn to say something about the User section.
The User Section is attached to the Job definition and the Data Staging areas for stage in and stage out.
I believe that we need to have Name, Group and some passthru for credentials (or an extension for such) not only for POSIX applications but for all different types of jobs. Web services typically have these concepts, sql would have it, AFS with security uses it etc...
If it is not put into the JobDefinition or the DataStaging areas then
I agree with Chris here. It doesn't make sense to have credentials in the JSDL. We decided in Berlin that security and credentials were out of JSDL's scope. We shouldn't let them creep back in! Cheers, Ali people
will add it in through extensions all over the place. As most jobs require some kind of identification of the user that will be running jobs and moving data.
Putting this in the POSIX Application area is too limiting and does not allow for referencing the User in other sections easily. For example in a complex workflow where the user identity will change depending on the job that is run it would be beneficial to reference the Users that are defined potentially outside of the JobDefinition several times.
Any questions?
Darren
-----Original Message----- From: owner-jsdl-wg@ggf.org [mailto:owner-jsdl-wg@ggf.org] On Behalf Of Donal K. Fellows Sent: Wednesday, March 30, 2005 5:14 AM To: Ali Anjomshoaa Cc: jsdl-wg@gridforum.org Subject: Re: [jsdl-wg] my view on execution user and group
Ali Anjomshoaa wrote:
...again, any other thoughts on this?
I think Karl's got the interpretation of the ExecutionUser and ExecutionGroup elements right. I'd just add that I would expect most JSDL instances to not specify these elements, with the identity to execute the job as being either implicit within the submission security context or present explicitly through SAML/XACML elements. Our experience with UNICORE is that this functionality is only rarely useful (but invaluable in those situations, of course, so the elements are worth retaining).
Donal.
-- ---------------------------------------------------- |epcc| - Ali Anjomshoaa EPCC, University of Edinburgh James Clerk Maxwell Building Mayfield Road E-mail: ali@epcc.ed.ac.uk Edinburgh EH9 3JZ Phone: + 44 (0) 131 651 3388 United Kingdom Fax: + 44 (0) 131 650 6555 -------------------------------------------------------------