Thanks for this Darren, can you define more concretely what your suggested UserName (uid) and Group (gid) are if they are more general than just for POSIX applications? I had a chat with a few of the database guys around here and, for databases for example, each database has its own definition of a "user". So if we had a generic <User> element that one could use for mapping to databases, it would be differently interpreted and used by different systems. I think the same is true for file permissions depending on the file system type. So a generic User element would inhibit interoperability and may even be dangerous, say if all the job requirements were satisfied, but, the "wrong" user type was sent to an undesired database. You could find yourself having access to someone elses data! Well, that's a wild example, but. These issues could be answered by having the matching to the concrete user on the end-system be done through the security context. OGSA-DAI use security certificates and the credentials are mapped to local users of various databases in a manner specific to each database type - a more secure user mapping I think. You could imagine that for accounting also, the <User> element could be taken out of the security context. Accounting was one of my use-cases for having a <User> element. I imagine that in the Web Service world also, different protocols or architectures will define user in different ways. So perhaps this user thing does belong in the security context outside JSDL? Just a question? Cheers, Ali On Thu, 31 Mar 2005, Darren Pulsipher wrote:
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
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
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 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 -------------------------------------------------------------
-- ---------------------------------------------------- |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 -------------------------------------------------------------